你的燈亮著嗎?

怎麼說呢.那麼多表單要填,我就覺得好象公司請我們來世填表單的,當然這是為了採集數據,可是我現在覺得我們寫代碼用了一個特徵的20%的時間,測試用了40%的時間(歸功於我們公司沒有測試框架),溝通用了20%的時間.還有20%的時間就填表單
我總覺得如果我說的工時要由CODER來做.那就相當于在我引用weinberg的寓言中關燈的事是駕駛員的事,如果他們因為美麗的風景而忘記關燈,最終致使汽車無法發動,那都是他們活該,誰讓他們只知道開燈,而不知道關燈呢.
OOD寫的規格,規格中詳細的描述著"特徵"(離FDD中的F還有距離),並說明了這個特徵要實現審麼功能,應該是相當清楚的.再加上OOD基本上都寫過代碼,應該可以很輕鬆的預估出工時,但是CODER就不同了,預估工時不會顯得象OOD那麼輕鬆,因為預估工時發生在OOD委託規格給OOP的時候就要發生.也就是在CODING之前.預估工時是對規格預估,規格中可能存在很多個特徵.CODER拿到規格就開始估工時,能行嗎,準確性會有OOD估出來的高嗎.
所以我還是覺得CODER可以監督工時的預估.能通過與OOD反復的"交鋒"當中,給出一個越來越準確的完成某種類型特徵的工時

必须让工作的人给自己的工作下计划，而不是别的人。
coder完成他们自己的工作，最有发言权的就是他们自己。分析员虽然技术可能更好些，但是他们无权替别人作主，更无权让别人必须在一个什么时刻做什么事情。
汽车司机的工作是开车而不是看风景，如果他们车开不好，就不要开车，把车停下来专心的看风景。
自己给自己制定计划是一种尊重，也是一种责任。

CODER是对OOD写出来的“详细”的规格来預估工時对吧？CODER当然不应该“拿到规格就开始估”，而是要再理解、吃透了OOD写的规格之后才来估，在这个理解、掌握的过程中就应该是OOD多次交锋了。等他吃透后，估计出来的工时应该是比OOD更准的，因为实际实现一个特征的人是他。比如，一个特征里要用到一些tcp/ip的知识，写这个规格的OOD可能很熟悉tcp/ip，但是实际去实现这个特征的CODER却不熟悉，那么他的预估当然要加上学习tcp/ip相关api的时间。

他们在预估工时的时候是不会想到自己会停下来看风景的，除非看风景本身就是他们计划的一部分^-^
但如果乐不思蜀，耽误了工作，当然是他们活该了，由他们自己负责便是

另外，如果可能的话，你最好把背景讲清楚，比如你现在做得是什么职务？究竟是什么事情困扰了你。

我是一個CODER,困擾我的問題是覺得實現規格的工時的責任不應該是CODER的,應該屬于寫規格的人,但是CODER應該監督並反馈.
還有我們的那個例子就假設看風景也是計畫的一部分好了,XP中強調計畫是跟不上變化的,如果我們把這美麗的風景當成是變化又如何呢.關鍵在於出隧道後要讓駕駛員關燈.而解決這個問題首先就要知道問題應該屬於誰?屬於駕駛員還是工程師或者是隧道管理處?

下面的話基本上摘自:<特徵驅動開發方法--原理與實踐>
我們被要求去估計自己所從事任務需要多久時間能夠完成.我們只能猜測,因為我們根本無法知道,或者說根本上知道這项任務工作量(規格)的實際工作量和複雜性.如果一定要我們來估,我們只能給出一個這樣的時間--明顯推遲任務完成的時間.
我知道作為pm來講,一定會說我們只懂寫代碼而不知道事前去進行充分的考慮.
在fdd中由於引進了里程碑的概念.所以基本上不需要向開發人員要完成率.只是里程碑要求足夠的清晰才能確保開發人員不會說謊,這點也是fdd在進度管控方面的根本和關鍵所在.fdd中還引入了一個主程序員的概念,我覺得他的存在會使開發人員輕鬆許多,至少可以更加全心全意投入到編碼當中去.



附:我原來的用戶名是yang_jh(密碼忘了),有向06z大俠請教過fdd方面的問題.由於入行不深,上次無法繼續請教,就是現在我還是沒有這個能力.<color book>看的一頭霧水,不過總覺得那4個原型能給我帶來某種啟發.

看得出你是个有思想的人，那是好事！不过有些时候太过于注重细节，也就是把OOD/OOP严格的区分开的确没有必要，关于工期，我觉得还是得OOP自己估计好，因为只有他自己清楚自己能在多少时间内完成，而OOD只能是调整。

猜测是一切学术的基础。猜测是一项最基本的素质。
如果你不能猜测，或者不敢猜测，你就只能不作任何事情。对于工时的问题，不管是coder还是设计者都是评经验进行猜测的结果。难道你喜欢让别人依据他们的经验来给你的工作做判断，而不是依靠最近的经验来判断最近的工作？

只有具备可操作性的东西，才能谈的上Conjectures and Refutations。
软件开发具有可操作性么？

Dennis:

CODER之于公司,我覺得挺象大部分的人民之于政府.我只是想多多的關心軟件開發中人的因素而已,當然尤其是CODER.不過也許等我成了管理者以後我也會把一些能讓CODER做的事就交給CODER做,哪怕這CODER沒有責任做這件事.

贊同Trustno1的話
關于工時,我覺得對OOD是可操作的,對CODER而言可操作性遠沒OOD來的強.FDD主張特徵的概念.主要還是讓它具有小粒度的特性,使其具有可操作性.CODER只是負責實現特徵.主程序員會規劃特徵.對特徵負責.當然這裡我假設了特徵的工時是可估的.工時可以讓CODER來估,如果從管理者而言,這還有助于CODER提高自身的value呢.但這屬于公司的決策問題.

好吧，我现在是OOD，你是OOP，对于一个程序我认为你应该在30个工时完成，如果你没有完成责任在谁呢？