敏捷估計與規劃

目標與問題

規劃的目的

做規劃的原因

• 減少風險
• 減低不確定性
• 提供更好的決策支援
• 建立信任
• 傳遞資訊

優秀計劃的組成部分

優秀的計劃就是專案利益相關者認為足夠可靠, 可以作為決策基礎的計劃.

敏捷規劃過程的特點

• 更關注規劃而不是計劃
• 鼓勵修改
• 產生易與修改的計劃
• 延續到整個專案過程

小結

估計和規劃是重要的, 但也是困難和容易出錯的. 我們不能僅僅由於他們很困難就不去做這些事. 專案早起給出的估計沒有專案晚期給出的估計準確. 不確定性錐形顯示了這一逐漸細化的過程.

規劃的目的是招到一個最佳答案, 用於回答’要構建什麼’這一產品開發的總問題. 這一答案綜合了功能, 資源和進度. 一個可以減少風險, 降低不確定性, 為可靠的決策提供支援, 建立信任和傳遞資訊的規劃過程為解答這個問題提供了支援.

規劃失敗的原因

基於活動而不是功能進行規劃

• 活動不會提前完成
• 延誤隨進度表傳遞
• 活動不是獨立的

多工處理導致更多的延遲

當一個人同時處理3個及以上的任務時, 用於增值的工作時間會迅速減少.

不按優先順序開發功能

忽視了不確定性

應對不確定性的最佳方式是迭代.

把估計當承諾

小結

基於活動的規劃分散了我們對功能的注意力, 而功能才是衡量客戶價值的單元. 採用基於活動的計劃所得到的進度表時, 許多問題都可能導致延期交付. 專案的參與者本來是滿懷好意地把多工處理當做一個可能解決延遲的辦法, 但由於多工處理背後隱藏的代價, 實際上會導致更長的延誤. 當進度表上剩餘時間不夠的時候, 不可能避免地要放棄一些功能. 由於是按照開發人員認為最有效的順序來對功能進行開發, 因此被放棄的功能對使用者來說不一定是價值最低的.

忽視使用者最終需要什麼的不確定性, 會導致雖然按時完成了專案, 缺沒有包含在制定計劃以後發現那些重要功能. 而忽視關於如何開發產品的不確定性, 則會導致在專案計劃中漏掉一些活動, 反過來增大了專案唄延遲, 最後放棄部分功能, 或者不適當地降低質量的可能性.

很多公司混淆了估計和承諾. 在哪裡只要開發小組做出一個估計, 他們就必須對它做出承諾.

敏捷方法

專案的敏捷開發方法

• 作為一個整體工作
• 按短迭代週期工作
• 每次迭代交付一些成果
• 關注業務優先順序
• 檢查與調整

敏捷規劃方法

• 規劃的不同層次(戰略, 資產, 產品, 釋出, 迭代, 每日)
• 滿意條件

小結

敏捷開發小組作為一個整體一起工作, 但包含了由特定人員擔任的不同角色. 首先是產品所有者, 負責確定產品前景和小組將要實現功能的優先順序. 然後是客戶, 就是為專案提供資金或在軟體完成後購買他的人. 敏捷開發專案中的其他角色海包括使用者, 開發人員和專案經理.

敏捷開發小組按照短的, 時間限制的迭代週期進行工作, 在每次迭代結束的時候交付一個可用的產品. 在這些迭代中開發的功能是根據它們對產品的業務重要性選擇出來的. 這保證了最重要的功能將首先開發. 使用者故事是敏捷開發小組表示使用者需要的一種常見方式. 敏捷開發小組認識到一個計劃可能很快就會過時. 因此, 他們會更具需要調整計劃.

專案應該被看做是迅速, 可靠地產生有用的新功能和新知識的流程, 而不是隻是對一系列步驟的執行. 專案會產生兩類新知識: 關於產品的知識和關於專案本身的知識. 每類知識在使計劃更精細, 從而為機構獲取更多價值上都是有益的.

敏捷開發小組使用3個層次上的規劃: 釋出規劃, 迭代規劃和每日規劃. 釋出規劃展望一次釋出的整個時間範圍, 通常是3~6個月. 迭代計劃只考慮當前一次迭代的持續範圍, 通常是2~4周. 每日計劃則由小組成員在每日例會上向其他人做出的承諾組成.

理解產品所有者的滿意條件對釋出規劃和迭代規劃都至關重要. 在釋出規劃中, 整個開發小組會確定一個方法滿足本次釋出在範圍, 進度和資源方面的滿意條件. 為此, 產品所有者可能需要放寬一個或幾個滿意條件. 進行迭代規劃時也會經歷類似的過程, 只是此時的滿意條件是將要實現新的功能和用於演示這些功能唄正確實現的高階測試用例.

規模估計

使用故事點估計規模

所需要知道的僅是某個特定的使用者故事或者功能是比其他使用者故事和功能大一些還是小一些.

故事點是相對的

故事點是用於表達使用者故事, 功能或者其他工作的總體規模的度量單位.

速度

需要的功能 –> 對規模進行估計 –> 推算持續時間 –> 進度表

• 速度修正估計誤差

小結

故事點是對使用者故事規模的相對度量. 具有10個故事點的使用者故事的規模, 複雜度或者風險應該估計為具有5個故事點的使用者故事的兩倍. 具有10個故事點的使用者故事的規模, 複雜度或者風險同樣應該為一個20點的使用者故事一半. 有意義的只是分配給不同使用者故事的點值的相對大小.

速度是對開發小組每次迭代的進度率的度量. 在每次迭代結束的時候, 開發小組可以看看他們完成了哪些使用者故事, 通過計算完成的使用者故事的故事點估計值之和來得到小組的速度.

故事點只是對要進行的工作的規模估計. 與其說一個專案的持續時間是估計出來的. 不如說是通過求取專案的總故事點數, 再除以小組的速度而推算出來的.

使用理想日進行估計

理想時間(ideal time)是某件事在剔除了所有外圍活動之後所需要的時間. 耗用時間(elapsed time)是時鐘上顯示流逝掉的時間. 用理想時間而不是用耗用時間來預測某件事的持續時間總是更準確, 而且要容易得多.

理想時間和軟體開發

以理想日作為對規模的度量

給出一個而不是多個估計值

小結

理想時間和耗用時間是不同的. 一場美式橄欖球的理想時間是60分鐘. 但是, 在一場60分鐘的比賽結束前, 時鐘上通常可能已經過了3個小時或以上. 當然, 導致這一差異的原因是比賽過程中可能出現的各種干擾.

使用理想日而不是耗用日, 更容易估計開發一個故事所需要的時間量. 按照耗用時間進行估計要求我們考慮在處理這個使用者故事時所有可能出現的干擾. 而如果我們以理想日進行估計, 就只需要考慮這個使用者故事所需要的時間. 這時, 理想日是對規模的估計, 雖然他的以及沒有故事點那麼嚴格.

採用理想日進行估計的時候, 最好只為每個使用者故事分配單一的估計值. 應該把所有需要的時間加在一起, 說某個使用者故事需要9個理想日, 而不是說它需要4個程式設計師日, 2個測試人員日和三個產品所有者日.

估計方法

回報漸減法則(回報的增長幅度隨著投入的增加而減小).

共同估計

估計的尺度

• 0, 1, 2, 3, 5, 8, 13, 20, 40, 100

• 13 * 0 ≠ 0

• 使用者故事, 史詩和主題

得到估計值的方法

• 專家意見
• 類比
• 裂解

規劃撲克

• 更小的會議
• 何時打規劃撲克(專案正式啟動前/第一次迭代中)

為什麼規劃撲克會有效

• 規劃撲克在做估計的時候把許多專家意見放到了一起
• 在規劃撲克期間會進行活躍的對話, 規劃者會被同事要求證明自己的估計正確性.
• 研究顯示, 對個人估計的平均可以引向更好的結果, 對估計進行團體討論也可以得到同樣的效果.

小結

花更多的時間和精力來得到一個估計值, 並不一定會提高它的準確性. 應該根據估計的目的來決定在估計中投入多少工作量. 雖然眾所周知將要做某項工作的人才能給出最好的估計, 但在一個敏捷開發小組中. 我們無法提前知道誰將負責這項工作. 因此, 估計應該是小組合力完成的一項活動.

估計應該基於一個預先定義的尺度. 將在最近處理的功能以及需要非常可靠估計的功能應該足夠小, 從而可以使用一個1~10之間的非線性尺度, 例如1, 2, 3, 5和8來進行估計. 不太可能在最近的幾次迭代中實現的大功能可以不分解, 用大的單位, 如13, 20, 40, 100來估計. 有些小組選擇在估計尺度中包含0.

要得到一個估計值, 我們可以依賴專家意見, 類比和裂解. 規劃撲克是一個有趣而且有效方法. 他結合了上述3種辦法. 在規劃撲克中, 每個估計者有一疊寫有有效估計值的卡片. 每討論一個功能, 每個估計者就選擇一張代表他的估計值的卡片. 所有的卡片都同時展示出來. 小組對估計值進行討論, 重複這個過程直到達成一致的估計.

重估

故事點是對規模的估計, 當一個使用者故事的相對大小發生了變化的時候, 才需要重新估計.

不進行重估的情況

規模不發生變化的時候, 不需要重新估計. 用速度來重新修正迭代估計.

需要重估的情況

重估的目的

把重估當做為估計將來的使用者故事而進行的學習體驗.

小結

記住故事點和理想日是對功能規模的估計, 可以幫助您知道何時應該進行重估. 只有在您對一個或多個故事的相對規模的看法發生變化時, 才應該進行重構. 不要只因為進度沒有您預期那麼快而進行重估. 讓速度這個很好的均衡器來解決大多數估計中的不確定性.

我不建議在一次迭代結束的時候給出部分完成的使用者故事的部分點數. 我的傾向是讓小組在速度計算中要麼得到所有的估計點數(如果他們完整地結束了一個功能, 而且該功能被產品所有者接受), 要麼就什麼也得不到. 但是, 小組也可能會選擇對部分完成的使用者故事進行重估. 通常, 這意味著對一個代表這次迭代中已完成工作的使用者故事和一個或多個說明剩餘工作的使用者故事進行估計. 這些使用者故事估計值的和並不需要等於最初的估計值.

在故事點和理想日之間進行選擇

有利於故事點的考慮因素

• 故事點有助於驅動跨功能的行為
• 故事點估計不會過期
• 故事點是純粹對規模的度量
• 故事點估計通常更快
• 我的理想日不等於你的理想日

有利於理想日的考慮因素

• 理想日在小組以外更容易解釋
• 理想日估計更容易開始

小結

開發小組可以選擇使用故事點或理想日進行估計. 兩者都是具有一定有點的可行方法.

故事點的優勢是可以幫助促進小組的跨功能行為. 此外, 由於故事點是更為純粹的對規模的估計, 因此即使小組在技術上或是領域知識上取得了進步, 也並不需要重估它們. 用故事點進行估計往往比用理想日估計要快. 最後, 與理想日不同, 可以在小組成員之間對故事點進行比較, 如果一個小組成員認為某件事需要他4個理想日, 而另外一個成員認為她只需要1個理想日, 也許他們都是對的, 但他們缺乏討論的共同基礎, 無法建立一個單一的估計,

理想日的優勢在於更容易向開發小組之外的人進行解釋, 以及更容易開始.

我的傾向是使用故事點. 使用故事點進行估計的優點更具有說服力. 如果小組對單純的規模進行估計存在困難, 我會讓他們用理想日開始估計, 然後再然讓他們轉化到故事點上. 我會更多地問’這個功能的規模與我們剛才估計的那個相比怎樣?’, 而不是’它會需要多少個理想日?’. 大部分小組幾乎不會注意到這種逐漸的轉變, 而當他們意識到的時候, 他們已經是在用故事點, 而不是理想日進行思考了.

為價值做規劃

確定主題的優先順序

確定優先順序時的因素

• 獲得這些功能帶來的經濟價值
• 開發(可能包含支援)新功能所需的成本
• 開發新功能所產生的學習和知識的量及重要性
• 開發這些功能所減少的風險

綜合4個因素

小結

由於會很少有足夠的時間來完成所有的事, 因此需要通過優先順序來確定首先處理哪些工作. 確定優先順序時需要考慮4個主要因素.

• 價值
• 成本
• 新知識
• 風險

綜合考慮這些因素, 首先是主題的價值和成本. 這樣做可以給主題安排出初始的順序. 然後可以根據其他因素前後移動主題的順序.

確定經濟優先順序

經濟指標:

• 淨現值
• 內部收益率
• 回收期
• 貼現回收期

收入的來源

• 新收入
• 增量收入
• 留存收入
• 操作效率

經濟指標

• 金錢的時間價值
• 淨現值
• 內部收益率
• 回收期

對利潤的比較

小結

因為大多數公司的底線是賺到或者節省的金錢數目, 所以對主題的經濟分析可以幫助確定主題的優先順序. 通常, 預測未來兩年中的收入和操作效率就已經足夠. 不過, 如果需要的話, 您也可以看得更遠一些.

對主題的收益進行建模的一個好方法是考慮它可以產生的收入, 主要來自從新客戶處, 從現有客戶購買更多的許可或額外的服務處, 從沒有這些功能就可能轉向競爭產品的客戶處, 以及從它所能帶來的操作效率提升上.

今天賺到或者花費的錢比將來賺到或者花費的錢更有價值. 將要一個當前的金額和一個將來的金額做比較, 需要對將來的金額貼現得到當前的金額. 當前金額就是可以被存入銀行, 或者進行其他相對安全投資, 然後在將來那個時候漲到那個將來金額的金錢數目.

有4個可以用於對現金流進行評估的好方法, 它們分別是淨現值, 內部收益率(投資收益率), 回收期和貼現回收期. 通過對每個主題計算這些指標, 產品所有者和開發小組可以對主題的優先順序做出明智的決策.

確定合意性優先順序

客戶滿意度的Kano模型

功能的型別:

• 作為閾值的功能, 或者必需的功能
• 線性功能(越多越好)
• 興奮點和驚喜點

相對權重: 另一種方法

小結

我們暫時停下, 回憶一下我們為什麼在進行這些討論. 在前面的章節中, 我們學習了確定功能優先順序時有4個因素需要考慮.

• 開發這個功能所產生的學習和新知識的量與重要性.
• 開發這個功能所消除的風險量.
• 具有這個功能所帶來的經濟價值.
• 開發(可能還有支援)新功能的成本.

第10章’確定經濟優先順序’說明了確定功能的總體優先順序時考慮學習和降低風險因素的重要性. 這一章介紹了兩種方法: Kano分析和相對權重, 來根據功能的合意性確定優先順序.

在Kano分析中, 功能被分成必須的功能, 線性的功能和興奮點. 這一工作是通過向潛在的使用者問後面兩個問題來完成的: 如果有這個功能他們會覺得如何以及如果沒有這個功能他們又會覺得如何.

相對權重方法提供了一種使用一個價值對實現一個功能所帶來的收益, 不實現它所帶來的懲罰和實現它的成本進行評估的方法, 這個值就代表了這個功能的優先順序.

分割使用者故事

何時分割使用者故事

• 使用者故事太大, 不能放進單次迭代
• 使用者故事小, 但是正在規劃的迭代中剩下的時間不夠.

按照資料邊界分割

按照使用者故事所支援資料的邊界來分割大型使用者故事.

按照操作邊界分割

把大型故事分割成獨立的建立, 讀取, 更新和刪除操作.

去除橫切考慮

考慮去除橫切考慮(例如安全日誌, 日誌記錄, 錯誤處理等), 為使用者故事建立兩個版本: 一個具備對橫切考慮的支援, 另一個不具備這種支援.

不用滿足效能限制

考慮把功能性和非功能性需求隔離到不同使用者的故事, 從而分割大型使用者故事.

分割具有混合優先順序的使用者故事

如果大型使用者故事中的曉故事具有不同的優先順序, 則可以對它們進行分割.

不要把故事分割成任務

不要把大型使用者故事分割成任務, 而是尋找一個方法來交付一項功能的所有層.

避免相關變化的誘惑

避免在具有適當規模的功能中增加相關變化而把事情弄糟, 除非這些變化具有相同的優先順序.

組合使用者故事

小結

無論是一個使用者故事相對迭代週期太大還是一次迭代的時間對它不夠, 分割這個使用者故事都是有益的. 如果您需要提供對比單個大故事更準確的估計, 分割大型使用者故事也是有益的.

可以按照使用者故事所支援的資料型別來分割它, 也可以根據故事中固有的操作來進行分割. 按照常用的CRUD操作來進行分割是很常見的. 把橫切考慮, 例如安全處理, 日誌處理和錯誤處理等, 隔離出去也可以使使用者故事更小. 還可以在實現使用者故事功能的迭代中忽略效能要求來是它變小, 效能要求可以形成獨立的使用者故事並在以後的迭代中得到滿足. 很多使用者故事描述了兩個以上的要求, 如果這些要求具有不同的優先順序, 就可以根據它們進行切割.

要避免把使用者故事分割成實現該功能時所必須完成的開發任務. 我們都有把工作分割成它的必須任務的習慣, 所以很容易按照這種方式來分割使用者故事. 還要避免在一個大型使用者故事中增加對交付該故事並非必須的相關變動的誘惑, 因為這樣會讓它變得更大.

最後, 記住有些時候組合使用者故事也是恰當的. 尤其是在修復故障時, 它們中的每一個本身可能都太小.

進度安排

釋出規劃基礎

釋出規劃是建立很高層次的, 覆蓋超過一次迭代週期長度的計劃過程

• 幫助產品所有者和整個開發小組判斷他們在獲得一個可以釋出的產品之前, 必須花多長時間開發多少東西.
• 傳遞了對於在多長時間內可以能開發什麼內容的期望.
• 可以作為專案小組的前進路標(如果沒有釋出的概念, 就是無盡的迭代).

釋出計劃

• 確定滿意條件
• 估計使用者故事的規模
• 選擇迭代週期長度
• 估計速度
• 確定使用者故事優先順序
• 選擇使用者故事和釋出日期

更新發布計劃

小結

釋出計劃是覆蓋了比一次迭代更長時間範圍的高層次計劃. 對大多數開發小組來說, 每3~6個月會進行一次釋出, 但是根據開發的軟體型別不同, 更頻繁或者更少的釋出也不少見. 最簡單的情況下, 釋出規劃可以說是微不足道的: 用預期的速度乘以計劃的迭代次數, 然後選擇使用者故事, 讓它們的規模估計值的總和充滿這次釋出.

釋出計劃並不需要精確說明在每次迭代中需要完成哪些工作. 實際上, 很少會需要這一水平的細節. 對大多數專案而言, 指出第一次迭代中要處理的使用者故事就足夠了, 可以把剩下的使用者故事留到以後再按優先順序分配到其他的迭代中.

釋出規劃是一個迭代的過程, 首先要確定產品所有者對這個專案的滿意條件. 這些條件通常包括了在進度, 範圍和資源方面的目標. 如果無法規劃一個專案來滿足最初的滿意條件集, 就需要要重複規劃過程, 看是否能滿足一個縮小了的滿意條件; 不然的話, 也許可以晚一些交付某些要求的功能, 或者採用一個更大的開發小組.

一旦建立了釋出計劃, 不要把它掛在牆上發黴. 通常要在每次迭代開始時更新它.

迭代規劃

迭代規劃時不分配任務

• 個人在一開始不會簽訂任務, 在迭代開始之後才逐步地每次簽訂一兩項相關的任務.
• 在完成已經選擇的任務之前不會開始新的任務

迭代規劃和釋出規劃的區別

\	釋出計劃	迭代計劃
規劃時間範圍	3~9個月	1~4周
計劃物件	使用者故事	任務
估計的單位	故事點或理想日	理想小時

建立迭代計劃的過程會引導開發小組對產品設計和軟體設計都開展討論. 產品設計討論的主題可能是關於諸如為了優化價值而對使用者故事進行最佳的組合, 對向客戶展示可用軟體後獲得的反饋進行解釋理解, 或者需要的是功能應實現到何種程度. 軟體設計的討論則可能是關於採用適當的體系層來實現新功能, 應該採用哪種技術, 是否可以重用已有的程式碼. 通過這些討論, 開發小組可以更好地理解應該將要構建什麼東西.

速度驅動的迭代規劃

速度驅動的迭代規劃的步驟:

• 調整優先順序, 確定目標速度
• 確定迭代目標
• 選擇使用者故事
• 把使用者故事分解成任務
• 對任務進行估計

承諾驅動的迭代規劃

要求開發小組把使用者故事逐個新增到迭代中, 直到他們無法承諾完成更多的故事.

關鍵在於讓小組中的每個人都有責任做出他們力所能及的貢獻, 二不管這是不是他們的專長.

任務估計和故事點的聯絡

小結

與釋出計劃不同, 迭代計劃更仔細地審視單次迭代中的特定工作. 迭代計劃所看到的範圍不會超過一次迭代, 而不是像典型的釋出計劃那樣達到3~9個月. 在釋出計劃中相當大的使用者故事在迭代計劃中被分解成任務. 對每項任務, 都要按照完成該任務所需要的理想小時數進行估計.

概括起來有兩種進行迭代規劃的方法: 速度驅動的方法和承諾驅動的方法. 兩種方法有很多相同的步驟, 而且常常會建立起一樣的迭代計劃.

選擇迭代長度

2~4周

選擇迭代長度時考慮的因素

• 正在處理的釋出的時間長度
• 不確定性的多少
• 獲得反饋的難易度
• 優先順序可以保持多久不變
• 不用外部反饋自行工作的意願的強弱
• 迭代的系統開銷
• 緊迫感的產生有多快

做出決策

招到一個可以鼓勵每個人都在迭代中按照穩定的步幅工作的迭代長度.

• 1周 非常忙亂和緊迫, 風險高(團隊成員生病), 除非自動化測試否則不推薦
• 4周 適合研究和追尋更加有創造性的解決方案. 有閩西的開端, 中間和結尾.\
• 2周 長度最理想

一直2周的迭代會使得開發小組過度緊張. 建議採用 6*2 + 1的大迴圈, 在1的時候由開發小組自由選擇優先順序, 他們可以在這裡清理技術負債.

小結

大多數敏捷開發小組採用2周或者4周的迭代長度. 沒有適用於所有小組的絕對正確的迭代長度. 每個小組都應該考慮自己所處的獨特環境, 選擇對自己合適的迭代長度. 進行這一決策時需要考慮的因素包括:

• 正在處理的釋出的時間長度
• 不確定性的多少
• 獲得反饋的難易度
• 優先順序可以保持多久不變
• 不用外部反饋自行工作的意願的強弱
• 迭代的系統開銷
• 緊迫感的產生有多快

估計速度

不確定性和進度估計

產品階段	低端乘數	高階乘數
初始產品定義	0.6	1.6
認可的產品定義	0.8	1.25
需求說明	0.85	1.15
產品設計說明	<0.9	1.1
詳細設計說明	0.9	<1.1
被接受的軟體	1	1

使用歷史值

進行一次迭代

1~3次

完成迭代次數	低端乘數	高階乘數
1	0.6	1.6
2	0.8	1.25
3	0.85	1.15
4次以上	0.9	1.1

做出預測

• 估計每個人每天可以在專案上的工作小時數(6小時)
• 確定在迭代中可以用在專案中的總小時數
• 任意的, 在某種程度上隨機的選擇使用者故事, 把它們的擴充套件成組成它們的任務. 重複這個步驟直到確定了足夠的任務來填滿迭代中的小時數
• 把上述步驟確定出的速度轉換成一個範圍(0.6~1.6)

選擇合適的方法

進行迭代 > 使用歷史值 > 做出預測

小結

有3種估計速度的方法. 首先, 如果您有歷史平均值的話, 可以使用他們. 不過在使用之前, 您應該考慮小組, 專案的本質和採用的技術等方面還有沒有顯著的變化. 其次, 您可以推遲對速度的估計直到您進行了幾次迭代. 這通常是最好的選擇. 第三, 您可以通過把一些使用者故事分解成任務, 看看多少任務可以充滿一次迭代, 來對速度進行預測. 這一過程與迭代規則很相似.

無論您採用那種方法, 都應該以一個範圍來給出對速度的估計值, 這個範圍反應了估計值中所蘊含的不確定性. 不確定性雛形為要使用的範圍大小提供了建議.

為不確定性緩衝計劃

功能緩衝區

承諾提供所有的這堆功能, 可能還會提供另外一堆功能中的一部分.

進度緩衝區

• 在估計值中反映不確定性
• 調整專案緩衝區大小(平方和的平方根)
• 更簡單的緩衝區計算方法(直接加一起 * 0.5)
• 緩衝區準則(10個故事以上才安排, 至少20%的時間)

結合多個緩衝區

進度緩衝區不是填料

一些警告

小結

大多數專案都包含大量的不確定性. 專案小組簡歷的進度表和最後期限中往往沒有完全反映這種不確定性. 有些時候, 如果這種不確定性非常大或者非常顯著, 就需要在估計專案持續時間的時候採取一些額外的步驟. 這些情況可能包括: 提前很多進行專案規劃, 專案必須絕對滿足最後期限, 同事交付一組相當嚴格的功能集, 專案是外包的, 需求仍然處於非常表面的層次, 或者在日期出錯時會產生嚴重的影響(經濟或其他方面)等.

功能緩衝區和進度緩衝區是兩類最常見的緩衝區. 當確定了專案中所有需求的優先順序, 然後發現可能不能交付所有功能的時候, 就要建立一個功能緩衝區. 例如, 敏捷開發過程DSDM建議把一個專案中30%的工作看做是可選的, 從而為專案建立功能緩衝區. 如果時間不夠用, 仍然可以通過放棄功能緩衝區中的事項來達到進度表的時間要求.

另一方面, 可以在進度表中包含一定量的時間來建立進度緩衝區, 這個時間的量反映了蘊含在專案規模中的不確定性. 可以通過同時估計每個使用者故事具有50%可能的規模和具有90%可能的規模來構造進度緩衝區. 通過對每對50%和90%估計值採用平方和的平方根公式, 可以估計出合適的進度緩衝區.

專案應該用功能緩衝區來預防功能不確定性, 用進度緩衝區來預防進度不確定性. 可以把功能緩衝區和進度緩衝區結合起來. 實際上, 這常常是個好辦法, 因為它可以讓每個緩衝區的規模都更小.

規劃多小組的專案

為估計建立共同的基準

更早給使用者故事新增細節

前瞻規劃

在計劃中加入饋送緩衝區

• 緩衝的物件
• 確定緩衝區的大小(不超過半次迭代)

工作流會很大

小結

敏捷開發專案傾向於在開發大型專案的時候避免使用很大的開發小組, 而是使用多個小組. 當有多個小組工作與一個專案時, 他們就需要互相協調工作. 本章說明了4種在幫助多個小組共同處理一個專案時很有效的方法.

首先, 小組應該為他們的估計建立一個共同的基礎. 所有小組都應該同意按照相同的單位進行估計: 要麼故事點, 要麼理想日. 他們海應該通過對對一小組故事形成一致的估計值來對使用的單位的含義達成一致.

其次, 當多個小組需要一起工作的時候, 儘早給他們的使用者故事增加細節常常很有幫助. 進行這一工作的最佳辦法是確認產品所有者對使用者故事的滿意條件. 這些滿意條件就是一旦完全實現了這個故事, 就可以顯示為真的那些事.

第三, 在釋出規劃過程中結合一個滾動前瞻計劃, 可以讓多個小組受益. 滾動前瞻計劃簡單地向前看幾次迭代(2~3), 通過共享在不久的將來每個小組分別會處理哪些工作的資訊, 讓小組之間可以協調工作.

第四, 在具有很多小組間依賴性的高度複雜專案中, 把饋送緩衝區結合到計劃中是有益的. 估計緩衝區是在計劃中的一段時間, 可以避免一個小組推遲交付導致另一個小組推遲啟動.

一般可以按照說明這些方法的順序把它們納入到專案中. 不過, 也可以按照您所希望的任何順序來使用它們.

跟著與交流

監督釋出計劃的執行

對釋出進行跟蹤

釋出耗散圖

停車場圖

小結

速度度量的是小組在每次迭代中完成的工作量. 應該採用或全無的規則來計算速度. 如果完成了一個故事, 小組就可以在計算速度的時候得到它所有的估計值. 如果在迭代中只是部分完成了一個故事, 確定速度時就完全不要考慮它.

釋出耗散圖顯示出每次迭代開始時專案中剩餘的功能點或理想日數目. 小組的耗散過程從來都不會是完全平滑的. 例如, 不準確的估計, 估計值的變化和範圍的變化等都會導致它的起伏. 耗散圖甚至可能在一次迭代中顯示出待完成的工作量的增加. 這意味著雖然小組可能完成了一些工作, 但他們要麼認識到剩下的工作被低估了, 要麼就是增加了專案的範圍. 解釋釋出耗散圖的一個關鍵在於理解它顯示的是小組恩淨進度(他們的進度減去所有被增加到專案中的工作).

釋出耗散條形圖提供了一種某些時候會有用的對標準釋出耗散圖的變形. 它把小組相對規劃的工作的進度和對釋出範圍的改變給分隔開, 通過把條形的底部降到水平軸以下來顯示範圍的變化. 這類圖比標準耗散圖更有表達力, 但必須小心使用, 因為它在一些公司中可能導致關於某個變化影響的到底是圖中條形的頂部還是底部的爭論.

停車場圖提供了一個有用的高層次檢視, 體現了小組在實現專案中所規劃的不同主題時的進度.

監督迭代計劃的執行

任務板

• 給開發小組提供了組織工作的方便機制
• 還剩多少工作一目瞭然

迭代耗散圖

跟蹤已完成的工作量

個人速度

小結

任務板, 常常是一張白板, 軟木板或者只是牆上特定的一片區域, 可以幫助開發小組組織他們的工作, 並把他們視覺化. 任務板的縱覽都帶有標題, 小組成員根據工作進展把任務卡片在各欄間移動.

迭代耗散圖類似於釋出耗散圖, 但只是用來跟蹤當前迭代中的工作. 它的縱軸是剩餘工作的小時數, 而橫軸是迭代中的天數.

小組要做出更好的估計, 就應該反對跟蹤花在任務上的實際小時數. 這樣所付出的工作量和帶來的風險通常超過了它帶來的好處.

小組不應該計算或跟蹤個人速度.

與計劃有關的溝通

就計劃進行溝通

就進度進行交流

迭代結束小結

1. 背景

日期
迭代的起止日期
工作天數

人員
名字, 計劃天數, 實際天數

2. 度量

每晚構建結果
日期, 狀態(如果測試通過則報告成功的數目; 如果失敗則報告失敗的數目)

迭代耗散圖

3. 內容和評估

使用者故事, 結果, 計劃的點數, 獲得的點數

迭代回顧
行動事項, 責任人

小結

我們希望就估計和計劃進行的溝通是頻繁的, 誠實的和雙向的. 甘特圖可以用作對計劃進行溝通的有益的工具. 不過不應該讓它進入到低於功能分解的層次, 而且圖中功能應該顯示為在整個迭代持續期內都在進行處理.

耗散圖是對進行溝通的主要手段, 但它們常常需要同時有一個圖顯示開發小組再每次迭代中的速度. 把速度考慮成一個取值範圍而不是單個值是有益的. 有一個好方法可以達到這一目的, 就是同時使用最近一次迭代的速度, 前8次迭代的平均速度和前8次迭代中最差的3次迭代的平均速度. 這3個值很好地描繪出剛傳送的情況, 長期平均的情況和最壞條件下可能發生的情況.

迭代結束小組在某些專案中可能是有用的, 它既可以傳遞當前的資訊, 也可以作為供將來使用的歷史文件.

敏捷規劃有效的原因

敏捷規劃有效的原因

經常進行重規劃

把開發小組的關注點從建立完美的計劃, 移動到簡歷目前有用的計劃.

對規模和持續時間的估計是獨立的

在不同層次上制定計劃

不同計劃是使用者不同目的的事實. 幫助小組從不同的角度來看這個專案.

基於功能而不是基於任務制定計劃

迫使小組在功能上來考慮產品.

小組故事保持工作流暢

每次迭代都要消除處理中的工作

在小組層次跟蹤

承認不確定性併為之做計劃

敏捷估計和規劃的12條指導原則

• 讓整個小組參與
• 在不同層次上進行規劃
• 使用不同度量單位, 讓對規模和持續時間的估計保持獨立
• 用功能或者日誌來體現不確定性
• 經常重規劃
• 跟蹤進度並溝通
• 承認學習的重要性
• 規劃具有適當規模的功能
• 確定功能優先順序
• 把估計和計劃建立在事實上
• 保留一些鬆弛度
• 通過前瞻規劃協調多個小組

小結

敏捷規劃的目的是以迭代的方式發現總體產品開發問題的自家解決方案, 這個問題就是在哪段時間內使用哪些資源來得到哪些功能.敏捷估計和規劃方法可以成功找到這樣的解決方案的原因包括: 計劃是在不同層次上做出的, 並且重規劃頻繁地發生; 計劃是根據功能而不是根據任務做出的; 首先估計規模, 然後根據規模的估計值推算出持續時間; 小故事保持工作的流動, 而且每次迭代結束時會消除處理中的工作; 是在小組層次而不是個人層次對進行進度度量; 承認不確定性併為之做計劃.