當User Story 無法在規定時間內完成時, 許多人的第一反應便是: User Story 估算的方法不對, 所以, 需找一個可 “準確” 估算人天的方法◦

1) 首先,我想任何解決問題的方法,  都沒有對錯, 只有因果◦

當 User Story 無法在規定時間內完成時, 我們可以花更多的時間去做 User Story 工作量的評估◦ 這絕對是個 “對” 的方法, 而這個 “對” 的方法, 最終所帶來的最大且唯一的價值便是: 證明我們大家都能如期交付 User Story; 證明大家都沒有做錯事◦

但真正的重點是: 證明我們大家都能如期交付 User Story; 證明大家都沒有做錯事

 2) 回到估算人天這件事◦

軟體開發目前還是個純手工打造的工作◦

       天底下的任何事只要是牽扯到有人類行為的介入, 就只能以 “概率”; “高斯曲線” 來預估, 預測人類行為的模式或發展◦

所以, 估算人天較為合理的作法應該是: 同樣的一個需求項 (專題或 User Story) 在不同的估算人天數下, 會達到的 “概率” 是多少?

      也就是說, 某一個需求項 (專題或 User Story), 預估可在 20 人天完成的概率是 10%, 預估可在

      唯有經由如此合理但頗為費勁的作法, 才能建立起團隊開發效率的高斯曲線, 客觀的 “預估” 出, 團隊成員的開發人天完成的 “概率”; 而非所謂 “準確” 的完成天數◦

所以, 敏捷開發期望一切化繁為簡, 一切以 “人” 為本; 以人的主動性來代替耗時且依舊無法提升效率的估算人天模式, 以人的主動性來決定 User Story 該完成的天數◦ 正因為如此, 敏捷開發中所估算的人天, 其中的主要目的, 是要排定迭代內 User Stories 的優先順序, 而非告訴開發人員, 你有多少人天可以做開發

3) 我們大家需要深度思考的另一個問題是: 我們今天是以問題的表象做決策? 還是以問題的根因做決策?

當 User Story 無法在規定的時間內完成時, “人天預估不準確” 是問題的表象? 還是問題的根因?