你的燈亮著嗎?

Weinberg:

我想看過這本書的同行都知道了最後的解決方法.

在我們公司,管理層要求項目(比較"小",可我覺得有的時候還是無法確定度)的進度要由OOP來確定,我覺得這就相當于要讓駕駛員來解決忘關燈的問題,明擺著駕駛員鐵定會忘記關燈.其實我希望這個估工時的動作應該是屬於OOD的(我們公司OOA,OOD,OOP分的很清).問題的擁有者是OOD,不是OOP,當然OOP可能也能解決這個問題,但是沒有OOD來得輕鬆.不過我還是"爭不過"我的頭.
各位高手認為呢?

支持你们公司管理层。在你们公司OOA/OOD/OOP分得很清的情况下，OOD是不实际programming的，那么一个功能实际要开发多长时间，理当由实际负责开发该功能的OOP来预估，OOD只能给予参考意见
打个比方来说，OOD指出了通向目的地的正确道路，然后叫OOP朝着那边跑，OOD怎么能知道以OOP的脚程要跑多久才能到呢？

我们公司这方面分得不是很细，所以估计起来更加困难。而且连OOD自己都不知道需要多长时间能够完成。

参考FDD，那里有很好的解决方式，正好是解决你们的问题。

OOD開出的規格里是可以看到粒度的.想OOD需要OOP完成一個類,我想OOD開出類的規格時,就確定了裡面會有多少個特徵.在某種意義上來說OOD肯定是工時的真正責任人,而OOP只能是工時的監督者.當然管理層是可以讓OOP來完成工時的確認的.但這本不應該屬于OOP.

呵呵，中国优秀的成功的PM似乎都是上下沟通，左右沟通，内接技术之高强，外联人际之城府——全才

在FDD里我感覺這個問題是由OOA/D來確定的.OOP只管實現類,是否逾期早就規劃好了的.
不過在此我們沒有Together工具.很多數據的採集只能同過手工來做,現在呢就是OOD不想做,我覺得這是他們不想多做一件事,哪怕這件事對他們來說如此的輕鬆.
我就是覺得工時問題不應屬於OOP.這個問題已經常會困擾我們.想想OOP每次去實現OOD的一分規格就會填很多分表單,為了採集數據.那是多麼痛苦的事.我想管理層的決定也就擺了,我們做就是.但是給我們的說法不要是這樣的:工時數據的採集就是我們的責任!

在开始的时候估算开发周期，并且按照估算制定开发计划。这个估算应该是在最开始，也就是还没有进行任何其他工作的时候（包括OOA/D）就开始了，并且在开发过程中不断的估算，以及调整开发计划。
而真正的周期的参数则只能依靠OOP来确认，也就是只能在编码级别才可以被确认。由于FDD的FEATURE所代表需求所消耗资源的粒度是比较统一的，你就可以依赖最开始的那些FEATURE所带来的资料，确定你的开发进度。而更加让我们感到高兴的是FDD支持在开发过程中添加人手，而提高开发的效率。
最后我想说OOA/D/P不是可以那么简单的分割的，而最不应该发生的就是OOA和别的部分的分割。

這當然了,一個特徵OOP已經做完,再問他花了多久時間做完當然沒有問題.
可能是我說的不夠清楚.我想表達是在CODING之前,它就要OOP來預估工時.這個預估工時應該不是OOP的吧.
我們公司的OOA是負責建立概念模型的(根據客戶提供的資訊).OOD是負責寫規格的(根據OOA提供的關于業務流程的概念模型),OOP是負責CODING的(實現OOD的規格).

让干工作的人估算他们的工作量有什么问题吗？当然应该是OOP来估算了，是他们具体负责完成特征的，自然只有他们才最有发言权啊。不