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