敏捷開發實踐(1)-故事工作量估算導致的問題 .

背景

自從我們使用scrum進行項目開發後，出現了這樣那樣的問題，有些是因爲我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的經驗。

我說的不一定正確，只是描述問題，然後說說我對問題的看法，採取的解決方案，希望使用敏捷開發的大牛提供寶貴意見。


故事工作量估算導致的問題

我們在對backlog中的story進行估算的時候，我們採用了一些前人總結出的敏捷開發的最佳實踐，其中一條直接導致了我們這次迭代提前結束：

1、共同估算：在估算前不應該指定誰將開發這個故事，而是以接收故事的小組爲單 位集體估算，每個人提出自己的看法，大家綜合。這樣才能以集體智慧完成任務。

共同估算沒有錯，用集體智慧和知識對“做什麼，怎麼做，需要多少工作量”達成共識，共同估算也是爲了提高團隊成員主人翁的意識，大家會關心自己曾參與討論的事情；共同估算意味着共同討論，能提高團隊成員對需求的理解程度，有助於開發出滿足需求的功能，而且如果開發期間領了任務的人有事脫離崗位，另一個曾經參與討論的人更容易接手些。

但，注意紅色的部分，”在估算前不應該指定誰將開發這個故事“，這個最佳實踐確使我們吃了虧。

我們項目組一個5個人，迭代週期爲2周，一共6個story，在開發進行了1周後，三個人閒置了，因爲他們已經完成了各自的story，而他們又沒辦法插手別人的story，因爲別人進行了一半，而這個story的任務是有連續性的，閒置下來的人根本無法領這些未完成story下的任務，也就是出現了”任務對人的依賴性“。

不知道我描述清楚了沒，我們的第一次迭代就這麼提前結束了，因爲我不可能讓三個人閒着沒事幹，等着另外兩個人。

經過總結會，我們決定在對story的工作量進行估算的時候，我們把誰做這個story規定好，這樣每個人在本次迭代的任務量都是飽和的，除非劃分不合理，不然不會出現上述情況，這時候問題又來了，在對每個人的story進行工作量估算的時候，各自都想爭取到更多的時間，也就是都認爲自己的story工作量巨大，如果不滿足他的要求，很可能會引發牴觸情緒。


在估算前，到底應不應該指定誰將開發這個故事？ 我們不能一棒子打死，簡單答案絕不止是"應該"或”不應該“。要根據story的性質來決定，一般情況下：

1、對於功能性的Story，如開發一個用戶管理模塊，這種story，不應該指定由誰開發。分解後的任務粒度，應該儘可能地小，最好是1人日能完成，儘可能做到任務之間不要有依賴關係（儘可能，雖然很難）。
2、對於非功能性的Story，如解決某個架構上的難題，應該指定由誰開發，應該指定高水平的開發人員解決，對於大型項目，如果能有單獨的一小部分人專門解決架構上的問題，環境上的問題，或者其他疑難問題，採用傳統命令式的方式進行管理，我倒覺得更合適些。

最後針對迭代計劃，進行一個宏觀地評估，主要是爲了避免出現任務粒度過大，依賴性強導致的"任務對人的依賴性"。


這篇就談的這裏，下篇談談敏捷開發實踐中，關於文檔的話題。