專案實踐－進度遊戲(2):90% Done

I was a fortunate young developer. In my first three months at work, I ran into the 90% done schedule game. I did it to myself.I estimated a particular task was going to take 6 weeks. Of course, being an arrogant and naive developer, it never occurred to me to break the task down into inch-pebbles. (That would have told me whether I even knew what to do for the task.)

At the end of the first week, I was 20% done. At the end of the second week, I was 40% done. At the end of the third week I was 60% done. At the end of the fourth week, I was 80% done. Right on time, at the end of the fifth week, I was 90% done. At the end of the sixth week, I was 92% done. Seventh week, 93% done. Time and I both marched onward. At the end of the 10th week, I was 97% done. But this time, I actually believed I was within a week of being done -- I only had three one-day tasks left to complete. It took me two more weeks. A total of 12 weeks for a 6 week task.

(一個大粒度的任務到達個人後，對於個人一定要認為這個大粒度的任務就是一個完整的專案，要有計劃，有WBS分解，有相應的里程碑和檢查點。不要太狂妄自大和天真，不要太相信自我的經驗和直覺，特別是對於複雜的問題，週期跨度較長的專案我們的經驗和直覺往往會失效。在這裡我們會再次強調掙值的0-100法則，對於一件事情及時你反饋完成99%，但是隻要沒有100%完成，沒有通過最後的驗收你仍然得不到一絲的報酬。90%完成也是一種進度欺騙，可能是你欺騙 了你的領導，也可能是你欺騙了自己，你自己的經驗和你開了一個玩笑。看上面作者的例子可以看到，一個估算為6周的工作，完成90%的時候花費了6周，而完成最後的10%又花費了6周。)

During the time I was 92%, 93%, 94% done, I wrote status reports to my manager, explaining I'd run into unanticipated problems and that I hadn't estimated all the things I needed to do. He was lovely about it, and kept saying, "Ok, let me know your updated estimate."(不知道大家有沒有做一件事情或任務，做到後面越做越複雜的體會。出現這種問題的原因不僅僅是估算不足或者是風險管理沒有做好。這是一個涉及到個人計劃和任務管理的一個複雜的系統問題。)

At the end of this task, when I was finally done, he was all set to move on. I told him I would be estimating differently from now on, with much more detail, and several deliverables each week. If I couldn't give him a date to be done, was that ok with him. We talked and I agreed to supply a date with a risk factor with each estimate.

I wish I could tell you I became a perfect estimator then. I didn't. I'm still learning to estimate. But I now know that when I think I'm 90% done, I'm probably only 50% done.

(根據經驗你任務90%的任務完成而實際情況往往只是完成了50%的工作任務。90%的任務完成改進的焦點在估算方法和風險管理兩個方面，而估算方法的改進首先則是要有一個完善的WBS工作任務分解。)

I'm not the only one. The 90% done schedule game can occur under any conditions: reasonable or unreasonable schedule, low or high risk technology. 90% done is about our ability to predict the future, to perform accurate estimation, and to understand -- in advance -- if we will be interrupted. Not a trivial problem.

The 90% done schedule game is the reason I like feedback during project work, in the form of inch pebble estimation, one-on-one meetings with managers, visible project status, and project-wide rolling wave planning.

(如何解決90%任務完成的問題，作者在文章開始就已經指出了具體的方法，即break the task down into inch-pebbles。即要把一個大的工作任務分解為一個個的細粒度的子任務，在分解為子任務的過程中有兩個核心要素是需要強調的，第一個是每個子任務都需要有明確的產出物進行驗收；第二個是我們強調的是迭代而不是增量，因此任務切分的方式是橫向的而不是縱向的。舉例來說如果一個軟體開發有10個較為獨立的功能點要做，則我們需要的分解是每各個功能點什麼時候能夠全部完成需求，開發和測試。如果你的分解方式是10個功能點都完成需求，都完成設計等，這種子任務的分解方式對我們來說仍然是屬於進度不明朗。計劃和任務管理和我們平時做事情的思維模式是一樣的，所有任務都去做一點還不如一件事情一件事情的做完做好。)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-429693/，如需轉載，請註明出處，否則將追究法律責任。