嗯，那妳最需要用敏捷了。讓我們從《敏捷評估和規劃》這本書開始。
1傳統項目管理和敏捷項目管理的區別
首先，我們來看看傳統項目管理和敏捷項目管理的區別。
差異1:傳統項目是基於活動(項目活動)而不是基於特性(功能完成)，客戶很難從活動的完成中獲得價值。另壹方面，完成是面向活動的完成，而不是功能特性的完成。盡管在當前的傳統項目中增加了對項目各階段需求的跟蹤，但每個階段仍然面向需求活動，而不是功能的交付。
對於基於特性(價值)的計劃，在評審活動進度時，評審的重點應該是缺失的功能特性而不是缺失的活動。
區別二:多任務導致更多延遲。
同時處理多項任務會對生產效率產生可怕的影響。當壹個人同時處理三個或三個以上的任務時，花在增值任務上的時間會迅速減少，不同任務之間的切換需要壹個過渡時間。所以盡量用專職人員，集中精力同壹時間只做壹件事，或者盡量在同壹天上午下午處理不同的內容。
敏捷項目通過限制WIP，讓團隊成員在短時間內專註於壹項任務，即停止開始，專註於當下。
區別3不按優先級開發特性。
傳統項目完成特性的順序是隨機的，優先級和開發順序是按照便利性來安排的，而不是像敏捷項目壹樣按照功能特性的值來安排開發優先級。而且，由於所有的工作都需要完成，所以不需要遵循任何順序。如果在項目前期規劃中因時間限制需要減少功能，將優先保證主要功能。但是如果壹開始沒有明確的定義，項目進展到後期，壹些更有價值的活動會因為進度的壓力而被壓縮或者不做。那麽最好的辦法就是在前期做好評估，實現明確定義的關鍵和高優先級的可交付成果，確保關鍵特性或任務不會被迫放棄或被壓縮。
差異4忽略了不確定性。
傳統項目往往忽略了用戶最終需要什麽(什麽)和如何開發產品(如何)的不確定性，這將導致項目的完成，但它可能不是用戶想要的，項目將錯過重要的項目活動，這將增加延遲項目、放棄功能和降低交付質量的可能性。
項目需求和計劃中會有壹些不確定性。傳統項目通常采用壹次交付所有需求的方法。雖然需求跟蹤+階段論證的方法或者項目的初始風險評估需要考慮如果項目延期的應對措施，但是可以部分避免這個問題。敏捷使用短周期叠代方法和最小可用系統方法，可以減少不確定性對用戶需求評審和如何在短周期內做出產品的影響。
差異5將估算視為承諾。
許多公司混淆了評估和承諾。團隊只要給出壹個預估，就會被迫按照承諾完成。壹方面，壹些開發者往往只給出開發完成的時間，而不考慮測試和驗證的時間。另壹方面，在做出承諾之前，會有大量的外部因素(如經營因素、風險、資源等。)影響評價結果。這樣的預估通常被評估為業績承諾，項目的延遲會導致項目的失敗。但是現在項目計劃中有很多不同的承諾計劃，同時考慮項目相關資源的可用性和突發事件也是壹種有效的方式。敏捷開發團隊使用發布計劃、叠代計劃和每日計劃。在估算完故事之後，它用速度來計算所需的時間並得到叠代所需的周期，然後在過程中隨著每次叠代快速調整速度。
當然，目前所有的管理理論都在逐漸趨同，但最終都是為了快速滿足客戶的需求。
在理解了敏捷和傳統項目管理的區別之後，我們壹起來理解敏捷估算。
2敏捷評估
敏捷估算有兩種方法，即故事點估算和理想人日估算。
在餐館吃飯時，我們會根據相對大小點菜，而不是確切的數量。我們的標準做法是有小有大，故事點也是，這是相對的。
我們可以用兩種方法來評價故事點。壹種是找到最小的故事設置為1，或者找到中等大小的故事設置為5，總範圍設置為1-10。將其他故事與這個故事進行比較，以獲得該故事的相對大小。
速度是開發團隊生產力的度量，可以通過計算團隊在壹次叠代中完成的用戶故事所分配的故事點的總和來獲得。
把所有特征的故事點加在壹起就是項目的總規模，加上速度，然後計算叠代次數；把它映射到時間表，它就是時間表。經過幾次叠代，可以通過修正速度來修正規劃的誤差。
我們在估算用戶故事所需的理想工日時，可以把理想工日作為壹種估算規模的方法，不考慮額外的組織費用。就像故事點壹樣，我們可以用速度來把理想日表示的大小轉換成時長的估計。
但是無論妳怎麽估計，妳都會發現，當妳需要壹個估計的時候，無論妳怎麽仔細的估計，最後都無法得到壹個能夠精確匹配坐標值的精確值。
故事點或理想工日是對要實現功能的整體規模和復雜程度的估計，而不是對時間的估計。實現壹個功能所需要的時間是該功能的大小(故事點的估算或理想的人日表達)和群體的進度率的函數。只有當用戶故事的相對規模發生變化時，才需要重新評估。
那麽有哪些估算方法呢？
最好的估計——包括將要做這項工作的人——是團隊壹起工作。壹方面，估算時沒有明確誰是任務的執行者；另壹方面，即使是專家估算，也需要其他人討論確定。
估計的比例使用兩個非線性序列，即:
1、2、3、5、8
1、2、4、8
當用上述序列估算故事點時，當遇到壹個估算值為“0”的故事時，仍然應該反映出來，即使概率很小，或者可以將多個故事點為“0”的故事聚合成壹個故事。
獲得估計值的方法:
每種方法都可以單獨使用，但要獲得最佳效果，需要綜合使用三種方法。
快速獲得估算值時咨詢專家的方法；有類似項目，可采用類比估算法；您還可以將壹個用戶故事或特性分解成更小的、更容易評估的部分來進行評估。
敏捷性的最佳估計方法是玩有計劃的撲克(Grenning2002)，它將專家意見、類比和分解結合成壹種令人愉快的估計方法，可以產生快速可靠的估計。估算的目的是合理性，而不是準確性。
故事點和理想人物之間的評價方式如何選擇？
首先，故事點有助於驅動跨職能行為，對故事點的估計可以幫助團隊學習跨職能工作。故事點的估算是對單個故事點的整體估算，而理想人物則需要根據特長來估算。
其次，故事點估算不會過期，故事點估算不會隨著團隊的技術、業務領域、經驗的不同而改變。只有當故事點的相對大小發生變化時，才需要重新估算。
第三，故事點是壹個純粹的大小尺度，不因開發成員熟練度的變化而改變。尺寸大到不會隨其變化。這種不變性是任何尺寸測量的理想特征。
第四，故事點估算通常更快，故事點估算更多的是從更高的層面。
最後，我的理想中的人不等於妳的理想中的人。
當然，理想的人在團隊之外很好解釋，估算也容易啟動，也方便快速估算和預測。
壹般來說，建議用故事點進行估算，但我們可以先用理性人日進行估算，然後慢慢轉向故事點估算。
3價值計劃
用估算法估算出故事點後，就可以安排項目進度了。但是在排期之前，需要建立產品功能(範圍)、進度和成本的最佳組合。
當然，短時間內不可能把所有的功能都開發出來，所以要分清故事和主題的輕重緩急。這時候要考慮的主題或故事的投入產出比是多少？能獲得的學習和知識有多重要，有多少？開發這個主題可以降低多少風險？這些因素結合在壹起對優先級進行排序。
優先級可以根據原始需求的願望進行選擇和排序。具體方法有兩種:1。使用KANO特征(閾值特征是必要特征；線性特征；興奮和驚喜)；2.按相對權重(價值工程，按功能的價值和權重評價)。
用戶故事的優先級排出後，通過分解用戶故事來安排具體進度。(具體分解方法可以在《用戶故事與地圖》這本書裏了解到。)
具體日程主要從發布計劃、叠代計劃、日計劃三個方面進行規劃。
發布計劃是建立覆蓋壹個以上叠代周期的高層計劃的過程。壹個典型的發布可能覆蓋3-6個月，根據叠代周期的長度，它可能包括3-12次叠代或更多。
規劃發布計劃的步驟。
建立發布計劃有兩種方法:壹種是建立壹個發布計劃，說明在每次叠代中開發什麽，另壹種是決定在整個發布中開發什麽，每次叠代的具體內容將在後面考慮。壹般來說，產品負責人在規劃發布時，需要選擇將優先級最高的對象放入第壹次叠代。
在叠代計劃中，團隊將更加關註並詳細研究完全實現那些新叠代所選擇的用戶故事所必需的內容。
叠代計劃是在叠代計劃會議上制定的。叠代計劃是壹個電子表格或者壹組寫有任務的記錄卡。不管用哪種形式，任務都需要和故事對應。應該註意的是，在叠代規劃期間，任務是不被分配的。否則，會與團隊成員實現叠代目標的壹致承諾相矛盾。
日常策劃是開發團隊每天上到15min的事件；開發團隊使用每日Scrum station檢查完成sprint目標的進度和完成Sprint待辦事項的進度趨勢。會議要麽以問題為導向，要麽以討論為基礎。會後立即聚在壹起進行更詳細的討論，或者調整或重新規劃sprint中的其余工作。
妳準備好了嗎？開始狂奔...
以上三個步驟完成後，我們項目的策劃活動就完成了。討論完交付計劃後，我們將特性分解成小任務項，在壹個工作日內進行。我們會在明顯的地方設計看板的位置，分別張貼功能圖和任務項，召開每日例會，保證每天交付，讓第壹個沖刺的交付在短時間內快速實現。
然後，繼續沖刺……...
妳準備好了嗎？
讓我們壹起開始實踐敏捷項目評估和計劃，並開始評估和計劃項目...
#圖書推薦專題，參與活動鏈接/p/3646b7e76fd8
#今天學習打卡