敏捷計劃的目的是以迭代的方式為產(chǎn)品開發(fā)的綜合問題足丢，在那段時間內(nèi)使用那些資源來得到哪些功能，去尋找到最佳解決方案。敏捷估算和計劃方法可以成功找到這樣的解決方案的原因包括：計劃是在不同層次上作出的卷中，并且頻繁的重新計劃盾似；計劃是根據(jù)特性而不是根據(jù)任務作出的唬格；首先估算大小，然后根據(jù)大小的估算值推算出持續(xù)時間颜说；小故事保持工作的流動购岗，而且每次迭代結束時會消除未完成的工作；在團隊層次而不是個人層次對進度進行度量门粪；承認不確定性并為之做計劃喊积。
敏捷估算和計劃價值分析：
無論軟件開發(fā)項目的規(guī)模如何，估算和計劃對于項目的成功都是至關重要的玄妈。估算與計劃并不僅僅是決定一個恰當?shù)淖罱K期限和進度表乾吻，而是對價值的探求.
1.減少風險
2.降低不確定性
3.提供更好的決策支持
4.建立客戶信任
5.傳遞信息
計劃失敗原因分析：
1.基于活動而不是基于特性進行計劃：基于活動的計劃常導致項目實際開發(fā)超出計劃表，有些團隊會試圖通過不恰當?shù)亟档唾|(zhì)量來節(jié)省時間拟蜻，有些團隊會制定變更控制策略來限制產(chǎn)品變更绎签。主要因素包含：活動不會提前完成；延誤隨進度表傳遞酝锅；活動不是互相獨立的诡必。
2.多任務處理導致更多的延遲：同時處理多個任務，多任務會對生產(chǎn)效率產(chǎn)生可怕的影響搔扁。當項目中開始有些活動被延期的時候爸舒，多任務處理往往變成了問題。
3.不按優(yōu)先級開發(fā)特性：不按照特性的優(yōu)先級順序進行開發(fā)稿蹲，因此某些被放棄的特性可能反而比所交付的特性更具有價值扭勉。
4.忽視了不確定性：忽視了與產(chǎn)品相關的不確定性，比如我們不能指望一開始就確定項目進程中需要的所有活動苛聘，但我們制定的計劃中往往無法意識到這一點涂炎。應對不確定性的最佳方法是迭代忠聚。
5.把估算當作承諾：如果項目團隊或者利益干系人把估算當作了承諾，傳統(tǒng)的計劃方法就會出現(xiàn)問題唱捣。在做出這樣的承諾之前两蟀，團隊需要對大量的商業(yè)因素和風險進行評估，并且不要把所有的估算都當成是隱性的承諾爷光。
如何估算大械婢骸：
兩種度量大小的方法：故事點和理想時間。
故事點：故事點是對用戶故事大小的相對度量蛀序，將要進行的工作大小進行估算欢瞪，項目的持續(xù)時間通過求取項目的總故事點數(shù)，再除以小組的速度而推算出來的.
理想時間：理想時間不是耗用時間徐裸，使用理想人天估算遣鼓，就只需考慮完成這個用戶故事所需要的時間，最好只為每個用戶故事分配單一的估算值重贺。應該把所有需要的時間加在一起骑祟，說某個用戶故事需要九個理想人天，而不是說他需要四個程序員人天气笙、兩個測試人員人天和三個產(chǎn)品負責者人天次企。
在故事點和理想人天之間進行選擇：
故事點的優(yōu)勢是可以幫助促進團隊的跨功能行為。此外潜圃，由于故事點是更為純粹的對大小的估算缸棵，因此即使團隊在技術上或是領域知識上取得了進步，也并不需要重估他們谭期。如果一個團隊成員認為某件事情需要4個理想人天堵第，而另一個成員認為只需要1個理想人天，也許他們都是對的隧出，但是他們?nèi)狈τ懻摰墓餐A踏志，無法建立一個單一的估算值。
理想人天的優(yōu)勢在于更容易向團隊之外的人進行解釋胀瞪，以及更容易開始针余。
我的傾向是使用故事點。使用故事點進行估算的優(yōu)點更有說服力赏廓。如果團隊對單純的大小進行估算存在困難涵紊，可以讓他們用一下人天開始估算，然后再讓他們轉(zhuǎn)化到故事點上幔摸。更多的問“這個功能的大小與我們剛才估算的那個相比怎么樣？”而不是去問“它會需要多少個零小人天颤练？”大部分團隊幾乎不會注意到這種漸進式的轉(zhuǎn)變既忆，而當他們意識到的時候，他們已經(jīng)是在用故事點而不是理想人天進行思考了。
估算方法：
四種最常用的估算方法是：
專家意見：如果你想知道一件事需要多長時間患雇，去問問專家跃脊。在基于專家意見的估算方法中，專家根據(jù)他自己的直覺給出估算苛吱。根據(jù)專家意見進行評估的一個好處在于他通常不需要太長時間酪术。根據(jù)專家意見進行評估的一個好處在于他通常不需要太長時間。
類比：當用這種方式估算時翠储，你不必把所有用戶故事都按一個基線或是通用的參照物進行比較绘雁，而是把每個新的用戶故事與那些已經(jīng)估算過的用戶故事進行比較。這稱為三角測量援所。
分解：分解是指將一個用戶故事或者特性分解為更小庐舟、更容易估算的部分。不過當分解太過時住拭，不僅忘記某項任務的可能性會增加挪略，而且對于大量小任務都估算值求和也會出現(xiàn)問題。
計劃撲克：要得到一個估算值滔岳，我們除了可以依賴專家意見杠娱、類比和分解，還可以依賴計劃撲克谱煤。計劃撲克是一個有趣而有效的方法摊求，它結合了上述三種方法。在計劃撲克中趴俘，每個估算者有一疊寫著有效估算值的卡片睹簇。每討論一個功能，每個估算者就選擇一張代表他的估算值的卡片寥闪。所有的卡片都會同時展示出來太惠。團隊對估算值進行討論，重復這個過程直到團隊的估算達成一致疲憋。
不確定因素如何處理：
大多數(shù)項目都包含大量的不確定性凿渊。項目團隊建立的進度表和最后期限中往往沒有完全反映這種不確定性。有些時候缚柳，如果這種不確定性非常大或者非常顯著埃脏，就需要在估算項目持續(xù)時間的時候采取一些額外的步驟。這些情況可能包括：提前很早就進行項目計劃秋忙、項目必須絕對滿足最后期限（同時交付一組相當嚴格的功能集）彩掐、項目是外包的、需求人員處于非常表面的層次灰追、或者在日期出錯時會產(chǎn)生嚴重的影響（經(jīng)濟或其他方面）等堵幽。
特性緩沖區(qū)和進度緩沖區(qū)是兩類最常見的緩沖區(qū)狗超。當團隊確定了項目中所有需求的優(yōu)先級，而且發(fā)現(xiàn)可能無法交付所有功能的時候朴下，就需要建立一個特性緩沖區(qū)努咐。另一方面，團隊可以在進度表中包含一定量的時間來建立進度緩沖區(qū)殴胧，這個時間的量反映了蘊含在項目規(guī)模中的不確定性渗稍。團隊可以通過同時估算每個用戶故事具有50%的概率的大小和具有90%的概率的大小來構造進度緩沖區(qū)。通過對每隊50%和90%估算值采用平方和和平方根的公式团滥，可以估算出合適的進度緩沖區(qū)大小竿屹。
項目應該用特性緩沖區(qū)來預防特性不確定性，用進度緩沖區(qū)來預防進度不確定性惫撰「嵘常可以把特性緩沖區(qū)和進度緩沖區(qū)結合起來。實際上厨钻，這常常是個好方法扼雏，因為它可以讓每個緩沖區(qū)的規(guī)模都更小。
計劃多團隊項目：
敏捷開發(fā)項目傾向于在開發(fā)大型項目時避免使用大型開發(fā)團隊夯膀，而是使用多個團隊诗充。當有多個團隊工作與一個項目時，他們就需要相互協(xié)調(diào)诱建。
首先蝴蜓，團隊應該為他們的估算建立一個共同的基準。所有戰(zhàn)隊都應該同意按照相同的單位進行估算：要么是故事的俺猿，要么是理想人天茎匠。
其次，當多個團隊需要一起工作的時候押袍，盡早給他們的用戶故事增加細節(jié)常常很有幫助诵冒。進行這一工作的最佳辦法是確認產(chǎn)品負責人對于用戶故事的滿意條件。滿意條件就是一旦故事完全實現(xiàn)了谊惭，就可以進行演示的那些細節(jié)汽馋。
第三，在發(fā)布計劃過程中結合一個滾動性前瞻計劃圈盔，可以讓多個團隊受益豹芯。滾動性前瞻計劃簡單地向前看幾次迭代（典型的是2～3次），通過共享在不久的將來每個團隊分別會處理那些工作的信息驱敲，讓團隊之間可以協(xié)調(diào)工作铁蹈。
第四，在具有很多團隊間依賴性的高度復雜項目中众眨，把饋送緩沖區(qū)結合到計劃中是很有意義的木缝。饋送緩沖區(qū)是一段時間便锨，可以避免由于一個團隊推遲交付而導致另一個團隊推遲啟動围辙。
監(jiān)督迭代計劃：
任務板：常常是一張白板我碟、軟木板或者只是墻上特定的一片區(qū)域，可以幫助開發(fā)團隊組織他們的工作姚建，并把它們可視化矫俺。任務版的各列都帶有標題，團隊成員根據(jù)工作進展把任務卡在個列間移動掸冤。
迭代燃盡圖：只是用來跟蹤當前迭代中的工作厘托，它的縱軸是剩余工作的小時數(shù)，而橫軸是迭代中的天數(shù)稿湿。
團隊不應該計算或跟蹤個人速度铅匹。
