在「敏捷中國」的郵件組中，有乙個話題是「scrum sprint plan中規模估算的做法調查」，大家的討論很熱烈。我們現在是用imd的方式評估工作量，即每乙個故事的大小，分解任務時將任務的粒度控制在2～8小時之內。
我們的想法：
1. sprint planning中分解任務部分要達到的目標，不僅僅是看到了乙個計畫，更重要的是如何完成計畫。將任務分解為小時為單位，是為了使團隊考慮如何實現功能時考慮的更加細緻，更容易在團隊內部討論，及早發現問題，更加靠譜。
2. 瀑布和rup的開發方式和敏捷開發進行任務拆分，如果我們認為乙個版本的功能要拆為100份工作會分析的比較透徹，那麼打個比方，1000元分為100份，每份10元；50元分為100份，每份0.5元；瀑布開發的週期較長，整體工作量大，任務拆分的評估單位為天就不錯了，而敏捷開發周期短，每個週期的功能工作量小，如果仍然以天為單位，例如3天，團隊成員無法了解3天的細節，本來敏捷開發就沒有特別完善的文件，那麼如果在3天裡出現了意外，團隊無法進行有效的幫助。
我們是這樣做的：
1. 每乙個故事對任務的拆分，至少包含：編碼、測試、文件；如果任務超過8個小時，則再拆分。
2. 在sprint中往往有上乙個sprint的known issues，修改並不會花費很多的時間，很多小的issue只會花費20分鐘，這樣我們會彙總相似的，表明工作量為2～3個小時
3. 當某乙個story確實無法完成時，團隊可以根據任務，和po討論拆分story。我們有過這樣乙個例子：乙個story要求
使用者可以查詢手機號碼以獲得聯絡歷史
，我們分解的任務是：查詢介面、精確查詢、帶*、？、關聯姓名等查詢、查詢結果介面，其中帶*、？、關聯姓名等查詢耗時較多，最後將story拆分為：使用者可以精確查詢手機號碼以獲得聯絡歷史、使用者可以模糊、關聯查詢手機號碼以獲得聯絡歷史。
舉例：
我們有乙個story：使用者可以傳送定時簡訊，以便在方便的時間編寫簡訊，在不方便的時間傳送簡訊。
分解的任務為：
1. 從資料庫中查詢滿足定時傳送的簡訊 （2h）
2. 利用第三方的傳送埠傳送（15h）
2.1 編寫呼叫第三方傳送api的介面（5h）
2.2 編寫api介面的測試用例（3h）
2.3 準備api介面的測試資料（2h）
2.4 測試api介面（5h）
3. 顯示傳送狀態（2h）
4. 進行介面功能的單元測試（8h）
5. 更新需求文件（1h）
6. 更新設計文件（1h）
7. 更新部署手冊（1h）
紅色部分為評估的時間
一點體會：
實踐中團隊成員開始並不願意以小時為單位進行拆分任務，一方面是不習慣如此細分，很瑣碎，覺得是對自己的不信任，另一方面每個人都會或多或少評估工作量時給自己留一些buffer，以天為單位留buffer容易一些，以小時為單位則任務拆分的更細，buffer的空間就小了。
1. 計畫本身比最後的計畫重要
2. 計畫很容易調整
3. 如果需要，在專案過程中不斷調整計畫
實踐敏捷估算（1） 不不過估不准的問題
摘要 說起估算問題，我們第一反應往往是 估不准 估得準又怎樣呢？假設估算結果是須要5個月才幹完畢，但合同要求3個月交貨，你怎樣辦？所以事實上我們另乙個 估得多 的問題，而在 估不准 和 估得多 這兩個問題之前，還有 不敢估 的問題。估算問題非常複雜，我們首先要做的是拆解這個問題，這樣才幹更好地找到合...
敏捷開發實踐 1 故事工作量估算導致的問題
背景 自從我們使用scrum進行專案開發後，出現了這樣那樣的問題，有些是因為我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的經驗。我說的不一定正確，只是描述問題，然後說...
敏捷宣言12條原則的一次小實踐
近日，領導給安排了指導某專案的需求分析工作，該專案面臨時間緊 任務重 人員少的窘境。需求分析只有4人，幾個複雜模組都壓在1個經驗豐富的老手身上，其他3人經驗不足。目前最嚴峻問題是，團隊產能不足 效率低下，專案需求分析很可能要延期的風險。考慮到有2個重點複雜模組的需求分析仍未開始，今天組織了次小組會議...