什麼是敏捷？（Agile）
從本質上講，敏捷（Agile）並不是開發方法，而是一種理念。對於項目管理而言，敏捷是一個全新的術語，敏捷強調在軟件研發過程中持續性的根據用戶反饋和需求優先級來發布新版本，不斷進行迭代，讓產品逐漸完善。
在數十年前，瀑布式項目管理是軟件研發的主流方法，在研發過程中，團隊成員將會花大把的時間和精力在項目前期去收集資源和信息，然後基於這些去做產品設想和研發規劃。
到了70年代，有先覺的研發人員發現瀑布式研發不僅在執行中各處受限，研發速度還很慢，顯然Out了。尤其到了90年代末期，開始出現黑客來搗亂，這就意味着前功盡棄、全部推倒重來，這簡直是研發的噩夢。
相比瀑布基於線性、可預測性地去開發產品，研發人員更想要能夠靈活管理用戶反饋、Bug和需求的方法。這也就是敏捷方法出來以後受歡迎的原因。
另外，你也可以通過這個視頻學習什麼是敏捷（Agile）
在2001年，17位研發人員共同探討出了《敏捷宣言》這份文檔，闡述了他們對於軟件研發的看法。文中他們定義了敏捷開發需要遵守的四項價值觀
我將之總結爲：
以人爲本：重視個體間的合作互動
目標導向：我們最終交付的是“可使用的軟件”，而不是一堆繁重的文檔
客戶爲先：理解客戶需求，與客戶合作
擁抱改變：客戶會在不斷變化需求的過程中明晰真正需要的，因此敏捷需要擁抱變化
儘管如此，這四項價值觀並不意味着我們就該放棄工具、文檔和計劃。因爲它們對研發結果依然有非常重要的價值，只是相比之下，我們應該關注更核心的事物：人、產品模型、協作和迭代。爲了讓這四項原則變得簡單易懂好執行，他們又將寫了敏捷開發12項原則作爲指導：
我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
欣然面對需求變化，即使在開發後期也一樣。爲了客戶的競爭優勢，敏捷過程掌控變化。
經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向於採取較短的週期。
業務人員和開發人員必須相互合作，項目中的每一天都不例外。
激發個體的鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
可工作的軟件是進度的首要度量標準。
敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
以簡潔爲本，它是極力減少不必要工作量的藝術。
最好的架構、需求和設計出自自組織團隊。
團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
如果我們把這些原則和遇到的問題對號入座，很快我們就會發現，這12項原則正是對應了客戶期望。比如，客戶不會關心開發文檔寫的怎麼樣，他們更感興趣交付的成品能幹什麼；他們不在意你的開發計劃，他們希望你能立馬交付；昨天他們想要修個BUG，而不是等到下次版本更新。
我們總會遇到需求多樣化的客戶，而這時，敏捷能夠確保你在研發過程中始終將用戶需求作爲核心。
怎麼知道敏捷（Agile）和團隊成員是否三觀相合
敏捷雖然聽起來光鮮亮麗，但不是所有項目都能用敏捷來做。
敏捷在公司裏投入使用後可能與預想的結果背道而馳。敏捷意味着快速推進項目，也就是說並不是所有事情都是按部就班。因此，我們得知道在這種快速變化的環境下，團隊是否能夠適應變化。
所以在我們部署使用敏捷前，先來點前戲試試看。在使用前，我們可以先問自己5個問題：
1.你是否會願意接手目標不明確的項目？
敏捷項目管理中有句話叫做：快速失敗。比如我們接手了一個連最終產出都不明確的項目，首先我們會先交付最小模型產品，這時我們得做好被質疑的準備。畢竟沒人知道要做出怎麼樣的產品，所以我們的最小模型的產品很可能是個怪胎。在與客戶反覆測試後，我們會纔會逐步瞭解他們的真實需求，這時候我們離成功又近了一步。
2.你會如何規避項目風險？
就像我們前面提到的，敏捷提倡不斷從犯錯中積累學習並持續迭代。如果我們走老路，用傳統項目管理的方法來推進的話，我們會要承擔更大的風險。當然就算我們開始敏捷之後，也要準備好隨時響應未知問題。
3.你的團隊能有多靈活？
作爲項目經理，我們的責任是和客戶一起把產品做的更好。這麼做很可能和設計、研發、其他成員的想法背道而馳。這時我們需要找主心骨聊一聊，是否願意放下老套路，根據用戶需求來調整想法、重新規劃方向。
4.公司階層制度嚴格嗎？
敏捷的其中一項原則不僅是和用戶一起工作，研發成員的身份也會發生變化。你們公司的文化開放嗎？是否能接受扁平和開放的管理方法？
5.你怎麼衡量進度？怎麼定義成功？
用敏捷來管理項目能夠幫我們逐漸進步的同時也督促我們將產品做得更好。如果因爲突發靈感而放棄正在執行的任務，那麼敏捷將毫無意義。我們先花些時間來看看團隊是怎麼看待進步和成功。然後再來看我們是不是離最終目標一步步的更近了？
研發團隊如何使用敏捷
讀到這兒，我想你已經躍躍欲試，準備踏上敏捷之路了。
敏捷非常注重節奏，當你有多個任務要交付，團隊更需要注重節奏的把握。而身爲項目經理，我們的職責是讓整個團隊通過協作最終交付產品。
敏捷是不斷規劃、執行、學習和迭代的過程，敏捷項目通常可以分解爲一下7步：
第1步：通過戰略會議定義你的願景
每當開始新項目時，第一件要做的事情是定義產品的業務需求，或者說想要達到的願景。事實上，我們只需要回答一個問題：你爲什麼想要做這個產品。這是我們心中的藍圖，時時提醒我們不要跑偏。
作爲一家產品公司，定義願景的最佳方法之一是電梯演講：
用於：（哪部分目標客戶）
需求：（用戶的需求）
類別：（我的產品是哪種類型）
功能：（產品的價值、客戶爲什麼選我們）
競品：（主要的競爭對手有哪些）
差異化：（和競品的差異化描述）
即使我們做的不是軟件產品，我們也可以根據項目的目標來調整上述內容。
戰略會議的參與角色都有誰？
此時我們要讓更多人認同這個項目，所以很多關鍵的利益相關者自然不能缺席，包括相關主管、經理、主任和產品經理。
戰略會議該什麼時候召開？
項目開始前我們就該來開戰略會，或者至少每年一次的定期會議來保證願景依然不過時
戰略會議要召開多久？
這個就由你主觀來決定了，一般來講，花4-16小時來探討戰略已經足夠了。
第2步：繪製產品路線圖
當我們開完戰略會後，就該輪到產品經理把願景變成產品路線圖。產品路線圖能幫助我們縱觀全局、理清思路，讓我們有寬鬆的時間來開發每個產品需求。“寬鬆”並不是說我們可以花數天或是數週的時間來推進每步計劃，而是輕量級的去定義產品、理清需求優先級和粗略估算產品每個需求的時間。
項目管理專家Roman Pichler認爲：目標導向的產品線路圖能夠聚焦於目標和產出結果（比如：獲客、增加活躍度、滿足客戶需求）。而產品特性來自於這些目標，所以我們在制定目標時應謹慎，每個目標對應3-5個產品特徵。
而每個目標，我們需要包含5個關鍵信息：時間、名稱、目標、產品特徵和衡量標準，有了這些，我們就能清楚知道哪些該做、什麼時候算做成功了以及我們如何取得了成功。
產品線路圖誰來畫？
當然是產品經理，但我們也該聽聽其他利益相關者的想法，比如：客戶、市場、銷售、支持和研發團隊的代表。
產品路線圖什麼時候來畫？
路線圖自然是要在開始實施迭代之前，當然最好是能在戰略會後就着手開始。
繪製產品路線圖要多久？
儘早實施，不是在前期糾結。雖然線路圖看起來有點紙上談兵，但當你的路線圖能涵蓋所有的目標時，我們也會更有信心去做好。
第3步：制定發佈計劃
當我們有了戰略和計劃，下一步我們就可以暫定幾個時間節點。
這個階段產品經理要嚴格按照計劃發佈新版本。我們也不用擔心功能不齊全的問題，敏捷項目都會有多次發佈的過程，所以我們只要優先發布核心功能的版本即可。
舉例來說，你的項目要在11月交付，而你可能在2月初就已經做好了最小模型，打算在5月左右發佈完整版。這些時間節點的安排都將由你的項目難度和每次迭代時長（或者說每次達成目標需要的工作時長）決定。通常每次發佈新版本都需要經歷3-5次迭代。
誰來制定發佈計劃？
產品經理、項目經理和所有團隊成員都該來參與其中。當然，邀請少數利益相關者來加入其中也是對其他成員的鼓勵，讓團隊能夠儘早開始。
發佈計劃什麼時候來做？
越早越好，你的發佈計劃應該在確認新產品後的第一天開始制定。在隨後的每個季度中至少記錄一次。
制定發佈計劃要多久？
一般來說會需要4-8小時，實際時長由具體情況決定，但不能因爲它拖進度。
第4步：制定迭代（Sprint）計劃
迭代（Sprints），我將其理解爲通過短期研發完成具體任務來達到目標的一個過程，也是幫助產品經理和研發團隊逐漸切入項目細節的方法。
通常情況下，每次迭代大約要花費1-4周。具體的時長我們需要根據團隊過往的表現情況來制定，同時儘量保持每次迭代的時長相同。
哪些角色參與制定迭代計劃？
迭代是整個團隊的活，因此，產品經理、項目經理以及其他所有成員都該積極參與其中，表達自己的聲音和想法。
迭代計劃什麼時候來制定？
在每次迭代週期開始前，我們就需要做好迭代計劃。比如說，你的計劃是每週迭代，那麼就你就需要在每週一（或者你選好的某一天）告訴其他人迭代計劃。
制定迭代計劃要多久？
迭代計劃是迭代週期的基石，雖然如此，我們也不要在這上面浪費過多的時間，通常2-4小時足夠了。寫好了迭代計劃也就意味着我們已經踏上了正軌。
第5步：每日站會
在每次迭代過程中我們需要有時間來確認項目組沒有遇到阻礙，同時保證能準時完成既定目標。這時候我們就需要使用每日站會。
每日站會，如同字面意思一樣通俗易懂，每天花15分鐘左右的時間來討論下面3件事：
昨天我完成了哪些事情
今天我打算做哪些事情
我有遇到哪些問題，如何解決
或許討論這3件事，可能讓團隊的一部分人的臉掛不住。但這對推動敏捷項目管理的溝通有積極意義。敏捷之所以能夠跨團隊協作，主要依靠的就是團隊快速響應和有讓成員發聲表達的空間。
第6步：迭代（Sprint）結束了？那就進入評審階段吧
如果迭代中一切順利，那麼迭代週期結束後，我們需要來檢測下軟件的功能。我們可以借評審的機會來向團隊成員和利益相關者展示成果。
作爲產品經理，你對產品功能有選擇的權利。如果有哪步錯誤，嘗試多問幾個爲什麼？下次迭代時我該怎麼調整才能讓團隊達成目標？敏捷是不斷學習和迭代的過程，你的流程管控和最終產出也是同一道理。
哪些角色參與評審？
團隊全員和利益相關者都應該參加迭代評審會來確認項目進度和表達他們的觀點。
什麼時候執行評審？
每次迭代結束後就可以開始。
評審階段要多長久？
無需特意去準備PPT、功能說明，審查會最多1-2小時就夠了。
第7步：下一步？迭代（Sprint）回顧總結
爲了讓敏捷項目管理能順利運作，我們在每個階段結束後需要知道下一步要做什麼。這是我們在迭代回顧階段要做的事。當迭代和審查結束後，接下來該去決定下次要做哪些工作。我們需要回顧下，在迭代中是否發生了些事情改變了你的既定時間，甚至是項目願景。
誰來參加回顧總結會議？
回顧總結是審查的延伸，這時利益相關者離開也沒有關係，而其他團隊成員則加入其中，給出自己的意見。
什麼時候來做？
當然最好是在審查階段結束後，立刻開始迭代回顧總結。
這會花多長時間來做？
概括下來大概幾個詞：簡短明瞭、甜蜜溫馨，最多花1-2小時來總結和大致規劃下次計劃。
整個過程都結束了，接下來幹啥？
這時候我們可以選擇發佈新版本、獲取用戶反饋、規劃新功能或者修復bug。持續性的發佈、學習、再建，這一系列過程讓敏捷在管理方法中異軍突起。
比起單純的靠產品需求清單來執行項目，在敏捷指導下，我們可以通過不斷髮布新版本來看看客戶的反饋。相比花一年時間來開發和發佈，然後發現缺失核心功能的傳統方法，敏捷能在每次迭代後迅速發現問題，並在下次迭代中及時調整。
如何實施敏捷方法：Scrum和看板
我想此時你已經躍躍欲試想把敏捷帶給團隊。但還有重要的一步，正如我們前面所說的，敏捷是項目管理的全新理念。爲了能更好的執行，有些人研究出了一些敏捷方法。這些方法相似度很高，但從實施的角度來看，兩者各有不同：
Scrum
Scrum應該是最廣爲人知的敏捷方法，與看板並駕齊驅。其受歡迎的原因歸功於操作簡單、高效以及極高的可複製性。你可以觀看這個7分鐘視頻，學習如何使用Scrum。
我們來看下Scrum的工作原理：
在Scrum中，產品經理和項目團隊緊密協作，一起定義目標、梳理產品需求清單。清單中通常會包含產品特性、修復bug、非必要功能需求以及其他要在交付時完成的工作。
有了產品清單，產品經理就會開始確定需求優先級，研發團隊通常會在接下來30天左右的迭代中產出“潛在可交付版本”。當研發團隊制定了迭代清單後，除了團隊成員外，任何人都不能再加入需求。當一輪迭代完成後，全員再次分析需求清單、劃分需求優先級，然後進入下一輪迭代。
看板（Kanban）
看板作爲敏捷方法的一種，提倡化繁爲簡，不讓研發團隊超負荷工作。因此它和Scrum有一定相似，都強調持續性交付，這個視頻解釋了看板管理項目的原理。
當然看板也會有自己的三原則：
1.工作流可視化
當項目逐漸複雜的時候，看板工具用“白板”幫我們理清所有項目的進度和歸屬：代辦、進行中、已完成，洞悉項目的關聯信息，讓事情逐步變得簡單清晰。
2.WIP原則
WIP類似於Scrum的迭代清單，一旦制定後就不再加入新的需求（研發團隊除外），團隊需要依靠看板來了解他們在每次迭代具體的任務量。
3.明確規劃下一步
爲了更好的實施看板，我們需要知道下一個任務是什麼。這也就意味着我們需要實時更新產品需求，重新確定需求優先級。
實施敏捷管理最後的建議
恭喜！你現在應該已經學會了敏捷的概念，和如何實施敏捷開發的方法，現在可以再自己的團隊內推廣了。
但是值得提醒的是，由於敏捷開發中涉及到大量的計劃、開發任務管理、時間進度和負責人，你需要使用一個項目管理工具，讓整個管理過程更可控。一個項目管理工具可以這樣幫助你做好敏捷開發：
1.進度報告：你可以看到還有多人任務等待完成、有多少延期任務
2.溝通：讓每個人反饋任務中遇到的問題和進展
3.分配：項目下的任務應該支持分配到具體的負責人