敏捷開發實踐(1)-故事工作量估算導致的問題
阿新 • • 發佈：2018-12-24
背景
自從我們使用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，如解決某個架構上的難題，應該指定由誰開發，應該指定高水平的開發人員解決，對於大型專案，如果能有單獨的一小部分人專門解決架構上的問題，環境上的問題，或者其他疑難問題，採用傳統命令式的方式進行管理，我倒覺得更合適些。
最後針對迭代計劃，進行一個巨集觀地評估，主要是為了避免出現任務粒度過大，依賴性強導致的"任務對人的依賴性"。
這篇就談的這裡，下篇談談敏捷開發實踐中，關於文件的話題。
自從我們使用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，如解決某個架構上的難題，應該指定由誰開發，應該指定高水平的開發人員解決，對於大型專案，如果能有單獨的一小部分人專門解決架構上的問題，環境上的問題，或者其他疑難問題，採用傳統命令式的方式進行管理，我倒覺得更合適些。
最後針對迭代計劃，進行一個巨集觀地評估，主要是為了避免出現任務粒度過大，依賴性強導致的"任務對人的依賴性"。
這篇就談的這裡，下篇談談敏捷開發實踐中，關於文件的話題。