摘要：新的一年即將開始，你在2020計划完成的事已實現了多少？我們知道，很多人會在新年伊始滿懷期待的做計划，並努力做好時間管理，但是當計划趕不上變化的時候，往往會措手不及，一再耽擱。因此我們需要明白“響應變化高於遵循計划”的原則。那么如何維持這兩者之間的平衡，高效的完成一件事，這個問題也正是這篇文章所要和大家分享的，如何在敏捷開發中做計划，即敏捷規划。
一個人不能沒有生活，而生活的內容，也不能使它沒有意義。做一件事。說一句話，無論事情的大小，說話的多少，你都得自己先有了計划，先問問自己做這件事，說這句話，有沒有意義?你能這樣做，就是奮斗基礎的開始奠定。——戴爾·卡耐基
2020年馬上就要過去了，很多公司和團隊以及個人都陸續着手這整年工作的歸納和總結，與此同時也開始對新的一年的展望。從小編上大學開始（那好像是一個很久遠的時候……），大家會在QQ空間或者QQ簽名上寫一些很正能量的話以肯定自己一年的努力和鼓勵自己在新的一年能百尺竿頭更進一步。當然很多有心人不僅是心懷美好期盼，而且還做了新一年的計划，比如，使用近些年來比較流行的bullet journal——子 彈筆記。子 彈筆記能它能讓你在短時間內找到最重要的事情，高效的做好時間管理，告別盲目的做事情。在記錄的時候，記得都是關鍵詞或短句子，並且配合着一定意義的符號有條理的排列內容，給人一種簡約和清爽的感覺。
-------圖片來源於網絡
子 彈筆記之所以被全球范圍所推廣和認可正是以為這樣簡約、高效的做計划的方式，其實這也正是遵循了現實的生活狀態，即我們需要高效的同時，正每時每刻不再面臨着變化，而詳盡復雜的計划往往只是費力不討好。這在軟件行業中也是一樣的。
原來的瀑布式開發的方式已經無法適應當今快速的變化，詳盡周密的計划必定無法指引軟件走出VUCA時代所帶來的“黑暗”，而敏捷開發的方式應時代所需勢在必行，因為在敏捷宣言中就提出了“響應變化 高於 遵循計划”的口號。可能有些讀者會有疑問說“難道敏捷就不做計划了嗎？”，其實不是這樣的。敏捷一樣需要做計划。那么有些讀者可能又會問“不是說響應變化高於遵循計划嗎？怎么還做計划呢？”其實敏捷宣言不是說不做計划，而是說相比做計划更有價值的是響應變化，一切以變化為依據。那么有讀者可能又會問“既然當今世界無時不刻不再變化，你如果響應了變化還怎么做計划呢？”很高興有讀者會有這樣的疑問和思考，而這個問題也正是這篇文章所要和大家分享的，如何在敏捷開發中做計划，即敏捷規划。
什么是敏捷規划
敏捷規划是一種逐漸完善過程的規划方法，是對價值的探求過程。規划為一個概括性的項目開發問題“我們要構建什么？”找到最佳的答案，這一答案綜合了功能、資源和進度三個方面。規划應該足夠可靠，可以用來作對該產品和項目進行決策的基礎。敏捷規划更關注規划過程而不只是建立一個計划。它鼓勵修改、產生易於修改的計划，並且延續到整個項目過程。
敏捷規划有效的原因
- 經常進行重新規划
- 在不同層次上制定計划
- 基於功能而不是基於任務制定計划
- 小故事保持工作流暢
- 每次迭代都要消除處理中的工作
- 在小組層次跟蹤
- 承認不確定性並為之做計划
敏捷規划和傳統規划的區別
敏捷規划追求真實需求，重復初始計划
敏捷團隊開始時對項目的願景有一個初步的討論，之后用原型進行迭代。干系人可以在原型的基礎上對項目進行反饋和調整。而在瀑布計划中，范圍和解決方案還沒有確定就需要干系人對項目進行詳細的說明和反饋。敏捷通過原型來更好的理解相關領域，並以原型為基礎進行進一步的計划和細化，這也體現了漸進明細的概念。
敏捷規划貫穿於整個項目中，不僅僅是前期的工作
傳統規划中強調前期計划的重要性，主要集中在項目范圍規划、時間規划、成本規划、質量規划、人力資源規划、溝通規划、風險規划、采購規划、干系人規划以及變更管理、配置管理和過程改進等相關計划上。這些過程都在項目開始之前就需要執行。敏捷恰恰相反，敏捷認為知識型項目的風險等級和不確定性使得前期計划出現了許多問題，所以敏捷方法提倡在整個項目生命周期中都進行規划，會有不同層次和詳細程度的計划。但是， 敏捷認為前期計划是很有必要的，只是不宜過度，需要找到一個平衡點，既要做好足夠的前期計划以減少大量重復和返工的風險，也能避免過度計划導致ROI下降以及多變的項目計划。
敏捷規划是移動打靶，需要及時調整中期計划
當目標是靜止的時候，可以做很多計划，從而向着那個靜止目標努力前進，當目標是移動的時候，就更加需要作出大量中期調整以保證目標達成，類似移動打靶。為了達成目標，敏捷方法使用了復雜的探測和適應系統去獲取反饋並作出調整。
敏捷規划的原則
- 假設事先無法制定完美的計划
- 事先規划有幫助，但不宜過度
- 最后責任時刻再敲定計划
- 關注調整與重新規划勝於與遵循計划
- 正確管理WIP
- 提倡更小、更頻繁的發布
- 快速學習規划並在必要時候調整方向
敏捷規划的方法
規划各層級計划，明確產品開發的方向
在敏捷方法中，早期的計划是必要的，但有可能是不太完美的。不確定性導致了重復計划的必要性。為了體現適應性計划的特點，分別為：敏捷願景、產品計划、版本計划、迭代計划、每日站會計划。計划的層次體現了漸進明細的特點，漸進明細的最終目的是為了交付與原始設計對象一致的產品。五層計划體現了在敏捷項目中一些細節不斷涌現，需要根據反饋重新排序優先級，從而調整整個項目。這一點體現了敏捷宣言中的最后一條“響應變化勝過遵循計划”。五層計划如下圖所示。
定義願景
規划洋蔥圖的頂端是願景層。產品願景要清楚描述從哪些方面為用戶或者客戶之類的利益干系人提供價值。這一層是定義產品要解決的首要問題和產品的目標人群。考慮這些問題有助於了解產品為用戶帶來的真正價值，和如何讓產品與其他試圖解決相同問題的產品區別開來。
確定產品概要列表和路線圖
開始時必須產生一些最基本的需求來填充產品列表，在確立列表之后，建立一個產品路線圖。路線圖要有時間軸、版本號和對應的特性功能信息。路線圖可以表示產品隨着時間的推移如何以增量方式構建和交付，以及驅動每一個版本的重要因素。
制定版本計划
根據產品路線圖的時間路標從產品列表中選取適當的特性進入對應的版本計划中。版本規划是主要針對增量交付取得范圍、日期和資源之間的平衡。每個企業和公司都需要有一個合適的節奏，有規律的向客戶交付產品特性。迭代結束的可交付增量是潛在可發布的，是否發布要依據組織的發布節奏。通常的發布節奏有三種。
在完成每個沖刺后發布：讓發布和迭代的節奏保持一致。
在完成多個沖刺后發布：將多個迭代的結果合並為一個版本進行發布。
在完成每個特性后發布：不考慮迭代是否結束，做完一個特性就發布一個，這就是通常所說的持續發布。很多企業和公司完成一個特性后就馬上向部分或者所有客戶發布特性，非常頻繁，有時可能甚至一天發布很多次。
制定迭代計划
迭代計划聚焦於實現本迭代所應開發的用戶故事的詳細任務以及任務的下發。一個迭代是一個較短的研發周期，通常持續2-4周。團隊從產品列表中選擇排序較高的用戶故事納入當前迭代中進行開發。制定迭代計划是為團隊選擇本迭代要完成的需求或任務。
每日計划
在每日站會中，團隊成員聚在一起，每個人依次講述自己在上次每日例會后做了什么，今天准備做什么，是否遇到了任何阻礙。團隊通過每日站會的形式評估自己的狀態，以一種非常直觀的形式告訴大家當天計划做什么，這也可以讓團隊盡早識別風險。雖然早晨的這項儀式開始於對前一天的成果的討論，但成功的團隊會意識到每日站會是討論計划的會議，而不是討論狀態的。因此，每日站會應該專注於制定一個每日進度的計划。
最后以圖的形式總結在這些級別產生的工件及其相互之間的聯系。
持續調整規划，保證產品的價值
在敏捷的整個層級規划中，是一個持續規划的過程，團隊會不斷根據過程中的所學所獲來逐步完善計划；這種方法使團隊在短期內就能明確責任，同時幫助他們了解自己的責任是如何推動長期目標的實現的。規划洋蔥圖的每一個層次都不止執行一次，而是在產品的整個生命周期中多次執行。不過，每層執行的頻率取決於該層的位置。一般而言，最常規划的是較低的級別，隨着向更高級別的邁進，你將逐步減慢你計划的步伐。比如說，你要經常、乃至每天做日常規划，但你可能只需要每隔幾個月甚至一年才重新審視你的產品願景。
在敏捷產品整個開發過程每個階段都是持續進行的，結合開發過程圖我們理解一下敏捷中的持續計划，過程圖如下所示。
通過流程圖可以看出，先制定一個前期計划，通常是當前迭代以及未來2-3個迭代的任務是明確的；然后盡早實現並發布給客戶獲取反饋；根據反饋及時進行計划，對前期制定的版本計划和產品路線圖進行調整，不停的在前期計划和及時計划中尋找平衡，保證團隊的目標始終是給用戶帶來價值，從而保證產品的價值。
敏捷規划的工具
時間盒
時間盒是固定的一段時間，相對比較短，計划的工作要在這段時間內完成。敏捷比較關注時間盒的概念，比如：一個迭代的時間盒是2-4周，一個迭代的計划會議是2個小時，一個回顧會的時間盒是1個小時，一個站會的時間盒是15分鍾。時間盒的結束點可以視為一個檢查點，采用時間盒的方式給整個敏捷項目的實施提供了頻繁的檢查點，通過結果評估、獲取反饋、控制成本、管理風險來監控外界變換的不穩定的環境，從而測量進度並且重新計划進行中的工作。
漸進明細
漸進明細是一種滾動式規划的技術。 在PMI編制的PMBOK中，是一種對進度計划編制的技術，是指在項目進程中，隨着信息越來越詳細，估算越來越准確，持續改進和細化計划。細化是量化的基礎，逐步細化我們的工作，可以提升項目計划的指導意義。
最小可售功能（MMF）
最小可售功能（MMF）是一個最小和可市場化的軟件特征或者產品特佂，可以快速開發並為用戶提供重要的價值。互聯網時代的競爭中，第一個占領市場就可以搶占先機，即便這個功能可能還不完備，僅具備部分可用的功能。最小可售功能代表功能包足夠完整到可以為用戶或者市場提供價值，同時也足夠小。在軟件項目中，增量交付的方式讓客戶可以更早地獲取可用功能，從而早期受益。增量交付在幫助團隊獲得早期投資回報的同時，也獲得了早期的反饋，給后續功能開發提供了參考。
怎么樣，各位讀者朋友，魚和熊掌是不是可以兼得啦。在敏捷的開發中也許你還有會這樣或那樣魚和熊掌的問題，那不妨來華為雲的DevCloud專業服務轉轉，這里不僅提供了解決方案還有各種能力評估呢！
在專業服務中針對不同的崗位提供了評估的能力，讓開發者可以對號入座，並基於你所在的崗位、技術得到客觀、全面、系統的測評以及名師般的學習引導。
快來訪問專業服務平台，通過個人能力評估，看看自己是什么水平吧！