最近讀完了《敏捷估計和規劃》，這本書對於實現敏捷開發具有很強的實戰意義，
提供了很多實際的操作方式和工具集，下面就是這本書的核心「敏捷估計和規劃的12條指導原則」
1.讓整個小組參與。(打撲克牌)
特定活動的主要職責可能會落在某個人或者某個分組身上，例如確定需求的優先順序主要是產品所有者的職責。但是，在最求可能具有**值的專案時，要讓整個小組參與進來並做出承諾。例如，我們可以在一條建議中看到這一點，這條建議就是雖然可能很明顯只有1~2個特定的小組成員會處理正在估計的故事或任務，但整個小組做出的估計才是最好的。小組成員分擔的職責越多，小組可以共享的成功也就越多。
2.在不同層次上進行規劃。(產品backlog->spring backlog->任務->每日計畫)
不要錯誤地認為發布計畫會讓迭代計畫沒有用，反過來也一樣。發布計畫、迭代計畫和每日計畫分別以不同的精度覆蓋了不同的時間範圍，而且各有其特定的用途。
3.使用不同度量單位，讓對規模和持續時間的估計保持獨立。(規模和工作量的關係，故事點)
讓對規模和持續時間的估計保持清晰區別的最佳方法是使用不會造成混淆的獨立度量單位。使用故事點來估計規模，再使用速度把規模轉換到持續時間是完成這一工作的好辦法。
4.用功能或者日期來體現不確定性。(給予日期範圍，估計不是承諾)
沒有哪個計畫是必然發生的。要確定您制定的任何發布計畫中都包含對不確定性的體現。如果新功能的量是固定的，就把不確定性表示為乙個日期範圍（「我們會在第三季度完成」或者「我們會在7~10次迭代中完成」）。如果日期是固定的，就需要表示在要交付的確切功能上的不確定性（「我們將在12月31日完成，產品至少會包含這些新功能，最多可能只會再包含那些新功能」）。不確定性較大的時候，就使用較大的單位（例如迭代、月，季後是季度）。
5.經常重規劃。(滾動計畫)
利用每次新迭代開始的時候評估當前發布的關聯度。如果發布計畫是根據過時的資訊或現在被證實為錯誤的假設制定，就更新它。使用重規劃的機會來保證專案總是瞄準著向公司交付最大的價值。
6.跟蹤進度並溝通。(相互監督，督促)
有許多利益相關者會對專案的進度很敢興趣。通過經常發布有關小組進展的簡單而易於理解的指示器來讓他們了解進度。耗散圖和其它讓人一眼就能看明白的專案進度指示器是最好的。
7.承認學習的重要性。
由於專案既是向產品增加新能力，也是產生新的知識，所以必須更新計畫來包含這些新知識。隨著我們更多地了解客戶的需要，會把新功能增加到專案中。隨著我們更多地了解我們使用的技術或我們合作的情況，會調整對進度率的期望和希望採用的方法。
8.規劃具有適當規模的功能。(故事點的粒度問題，短週期迭代)
在不久的 將來（接下來幾次迭代中）就要增加的功能應該分解成相對較小的使用者故事–通常就是需要1~2天，最多不超過10天的事項。我們最善於估計規模處於乙個數量級內的工作。讓使用者故事都處於這一範圍內，可以讓我們在估計和規劃中付出的工作量和得到的準確度達到最佳的組合。它還可以提供足夠小的使用者故事，讓大多數小組合一在一次迭代中完成。當然，在較長時間的專案中，使用小使用者故事會很費事。為了平衡這個影響，如果您要建立的發布計畫覆蓋的時間範圍超過了未來的2~3個月，也許可以編寫一些更大型的故事（稱為史詩）或者使用主題，來對時間更遙遠的工作進行估計，從而避免過於提前把大故事分解成小故事。
9.確定功能優先順序。(計畫安排之基本，規模和優先順序)
按照讓專案總價值最高的順序來處理功能。確定優先順序時除了考慮功能的價值和成本，還要考慮它能帶來的學習效果以及開發它能夠減少的風險。可以在早期消除乙個顯著的風險的可能性，往往就足以保證先開發某個功能的合理性。與之相似，如果開發特定的功能可以讓小組獲得大量有關產品或他們開發它的工作的知識，也應該考慮盡早開發這個功能。
10.把估計和計畫建立在事實上(根據實際做計畫，估計)
只要有可能，就把您的估計和計畫建立在現實的基礎上。確實，有些時候在某些公司中會需要在沒有什麼事實根據的情況下對類似速度之類的事做出估計。但是，只要有可能，就應該根據事實的測量值建立估計和計畫。這同樣適於乙個功能完成了多少的問題。很容易知道乙個功能完成了0%的時候（我們還沒有開始處理它），也相當容易知道我們已經完成了100%的時候（產品所有者的所有滿意條件測試都通過了）。在這兩者之間就很難度量了–這項任務完成了50%還是60%？由於這個問題太困難，最好還是堅持您所知道的：0%或100%。
11.保留一些鬆弛度。(專案進度和人員緩衝)
尤其是在規劃一次迭代的時候，不要規劃用掉所有小組成員100%。就像公路達到100%容量的時候完全停滯一樣，如果將所有人的時間都規劃成滿負荷工作，開發小組的進度也會減慢。
12.通過前瞻規劃協調做個小組。
在涉及多個開發小組測專案中，應該通過滾動前瞻規劃來協調他們的工作。通過前瞻和把特定功能分配到即將來到的特定迭代，可以規劃和調節小組間的依賴。
敏捷開發讀書筆記
1 開始時需求要明確 2 盡早發布可執行的demo，持續進行整合 3 功能粒度要足夠低 4 架構可以隨時進行調整 5 測試驅動開發 6 持續整理 及架構重構 7 持續的速度，任務分解需要細緻 粒度要小，各個模組的任務完成要及時 有效 軟體之美在於它的功能，在於它的內部結構，還在於團隊建立它的過程。對...
01 敏捷估計與規劃 前言筆記
00.您的專案進行的怎樣？遇到了令人詛喪的變化？不確定性？還是產品錯過了標誌點和最終期限？mike cohn清晰明了地展示了如何有效地開發具有高商業價值的軟體。通過敏捷估計與規劃，即使環境發生了變化，您仍可以將經理專注於真正需要的地方。01.規劃對任何敏捷開發專案都是不可缺少的組成部分。02.敏捷開...
《精益和敏捷開發》讀書筆記
對精益不了解,敏捷開發則是乙個到處都在談論的話題,我只是跳著看了一些在敏捷方面的做法和觀點,而且主要是scrum相關的,當然本書的敏捷開發基本上可以等同於scrum.算是增加了一層對scrum新的認識.書不敢說是一本好書,只能各取所需吧.我是讀書筆記的分割線 如果在同乙個辦公區域,你記不清所有人的名...