背景
自從我們使用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，如解決某個架構上的難題，應該指定由誰開發，應該指定高水平的開發人員解決，對於大型專案，如果能有單獨的一小部分人專門解決架構上的問題，環境上的問題，或者其他疑難問題，採用傳統命令式的方式進行管理，我倒覺得更合適些。
最後針對迭代計畫，進行乙個巨集觀地評估，主要是為了避免出現任務粒度過大，依賴性強導致的"任務對人的依賴性"。
這篇就談的這裡，下篇談談敏捷開發實踐中，關於文件的話題。
工作量估算
我們的方法還是比較實用的 舉個具體的例子 我們做任何乙個工作,都先做sample,比如寫詳細設計,leader必須先寫,定sample,然後看leader做需要多少時間,然後按一定比例,比如pert方法就可以,然後按畫面去分,畫面數 預期每日完成數,測試也一樣,先做sample再算預期case數,再...
估算速達5000開發工作量
採購系統 採購申請管理 根據訂貨申請採購 根據缺料申請採購 銷售系統 倉庫系統 pos系統pos機銷售管理 pos機銷售款管理 pos機銷售彙總 pos銷售彙總管理 班次資料管理 會員卡資料管理 其他系統 從上述模組中按照ei eo eq ilf eif幾個方面找出各自的fp數，然後可以採用簡單的工...
如何估算測試工作量（一）常規的估算測試工作量的方法
如何估算測試工作量 一 常規的估算測試工作量的方法 作為乙個管理者，你是否被詢問到某個專案要花多少時間，多少人力測試 或是作為乙個普通的測試員，你是否被詢問到要花多少時間來完成某個任務或是一次回歸測試？我想大多數在軟體行業的人或多或少都會碰到這樣的關於工作量估計的詢問。那麼你是怎麼回答的呢？你對你自...