如何肯定敏捷是否適合你的團隊？

對從事項目管理的人員來講，敏捷已經成爲一場席捲全國的風潮。但敏捷並非什麼新事物，它已經有20多年的歷史。正如社交媒體圈子所說的那樣，敏捷的聲勢與流行程度正在逐年見長。但敏捷是否是真的如坊間傳聞的那樣，是一個能夠解決全部項目困境的萬能藥？
固然不是！但敏捷的確是一種比較好的項目管理方法。敏捷爲項目負責人及其團隊提供了一些獨特的優點。

咱們以前將敏捷方法與傳統的瀑布流方法進行了比較。敏捷這種軟件開發領域的項目管理辦法，在過去數年有着強勁的發展勢頭。它解決了產品需求與開發等方面的不肯定性。與之相較的瀑布流方法則試圖將項目生命週期的各階段，即啓動、計劃、執行和收尾等，按照嚴格的結構順序進行組織。

什麼是敏捷?

要確切定義何爲敏捷很是困難。不一樣的人可能會給出不一樣的答案。敏捷這個大範疇內包含下面幾個體系，如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。
敏捷將項目規劃變成了一個貫穿整個項目生命週期的迭代過程。「fail-fast」這個術語體現了對迭代的渴望，即經過先將開發出的不完美的產品提供給客戶使用，以收集客戶的反饋。
客戶的反饋相當重要。傳統的項目管理方法要求項目需求在項目開始以前就要收集並肯定好。但敏捷方法則不一樣，敏捷更加實用和高效，要求產品負責人和關鍵利益相關者在產品開發過程當中，參與構建和測試。
這樣作可以大大節省時間。爲何咱們須要花上三個月的時間收集需求，再花上四個月的時間開發產品，到最後才發現開發的產品並非客戶真正想要的？爲何咱們不可以開發一部分以後，展現給客戶，將反饋整合到產品的開發中，而後不斷重複這個過程並在更短的時間內構建客戶想要的產品？簡而言之，這就是敏捷的目標。

使用敏捷的最佳條件是什麼？

當咱們沒法肯定產品的需求是什麼時，最好使用敏捷方法。從收集用戶故事開始就讓產品負責人和Scrum團隊參與進來可以讓咱們更高效地利用時間。用戶故事是產品負責人但願開發的功能和特徵的簡要描述。
而後，根據這些軟件功能，產品負責人和Scrum團隊建立一個名爲Product Backlog的待辦事項列表。創建Product Backlog後，Scrum團隊就會建立Sprint Backlog。客戶所需的產品功能將會被安排在不一樣的Sprint中完成。所以，Sprint中是下一個版本中的功能，這麼作的目的是爲了每次都開發和部署產品的一小部分功能。

產品負責人和Scrum團隊將召開每日站會來review開發進度。這種方法有助於解決產品或需求中的不肯定問題。因此整個產品開發流程就是：開發部分功能—測試—收集反饋並繼續開發—直至產品負責人對最終產品滿意爲止。

什麼狀況下敏捷不是最佳選擇？

敏捷並不老是最好的方法，例如需求基本是肯定的。當項目具有可靠的歷史記錄做爲開發基準時，咱們最好採用瀑布式開發方法。
數據中心的構建就是一個很好的例子。需求和任務開發順序都很明確，無需作太多的規劃。所以，若是按照前文所述的「部分開發-反饋-繼續開發」這一流程進行顯然是不切實際的。

那麼，什麼時候步入敏捷？

如今，咱們已經清楚瞭解了敏捷的定義，適用條件及在什麼狀況下最好使用傳統的開發方法。下面，讓咱們瞭解一下在什麼狀況下最好使用敏捷。具體狀況可能比較多，僅在下文中列舉幾類主要狀況：

• 產品需求不肯定時

這種狀況下，敏捷可使項目更快啓動，並讓產品負責人蔘與到開發過程當中。用敏捷的方式，咱們就沒必要在不肯定客戶是否會滿意的狀況下花六個月的時間記錄產品需求。產品負責人能夠在開發新產品功能時，根據他或她的反饋做爲開發過程的一部分，以最快的速度將功能呈現出來，從而確保產品能夠更快交付。

• 敏捷是軟件開發項目的最佳選擇

由於軟件開發過程自己就容許整個系統中的部分功能先進行開發、測試和交付。這就意味着某些特定功能的交付時間會早於其餘功能。Sprint則容許開發團隊單獨測試和部署這些功能，從而確保開發效率。

• 協做的團隊可從敏捷方法中受益（每日站會）

敏捷方法的關鍵是天天的站立會議。會議上，團隊能夠討論當前的開發進度、遇到的問題和來自產品負責人的反饋。若是有人可以負責召開這些會議並將會議結果更新到敏捷看板上就行了。由於協做的團隊成員能夠隨時訪問和更新故事板，這將有助於團隊協做的順利開展。

這一點能夠經過Worktile的迭代故事板能夠作到，在每日站會的時候迭代負責人能夠拖動需求看板來改變需求狀態及時更新需求進度。

• 積極參與的產品負責人

產品負責人的實時反饋是敏捷成功的關鍵。這樣不只能夠取代繁瑣的需求文檔，還能確保清晰的傳達產品負責人的需求。產品負責人蔘與併爲開發團隊提供持續的反饋，能使團隊更快地開發出正確的產品。產品負責人應該參加天天站會，並表達本身的指望、喜愛和不滿。這樣能確保開發團隊開發出產品負責人想要的產品。

• 團隊工做與協做——積極主動的團隊成員

社會責任是敏捷方法的關鍵驅動因素。敏捷但願建立一個能在必定程度上實現自我管理的團隊環境。敏捷教練但願建立一個積極並表現出主動性的團隊。若是團隊成員沒能遇上進度或積極參與，那麼敏捷教練但願其餘團隊成員可以互相幫助、鼓勵和激勵。敏捷教練將以身做則，奠基團隊中相互鼓勵和問責的協做基調。

• 從失敗中學習的意願

快速試錯更快速地從失敗中學習。原型設計和反饋是敏捷的重要工具。傳統的開發方式試圖在項目啓動前描述全部的需求，這麼作會浪費大量時間，尤爲是在開發新產品時。因此一旦有了想法就應該馬上進行開發，即便當前的產品並不是產品負責人想要的。這樣作的目的是要經過不斷的反饋來調整產品方向並繼續開發。

• 管理層支持敏捷框架並具有團隊賦權的企業文化

敏捷能夠爲企業帶來文化和指望層面的轉變，由於它鼓勵團隊賦權，讓團隊負責作出決策並承擔相應的風險。與之相反的是，在傳統的開發團隊中，項目經理須要提供明確的方向，而在敏捷開發中，敏捷教練則會鼓勵開發團隊提出最適合產品開發和產品負責人的方案。管理層必須賦予團隊必要的自由，僅提供能讓團隊快速成長的指導和方向，而不是控制團隊的每一步行動。

擁抱敏捷令人興奮。由於它讓項目負責人多了一種項目管理方法，來解決項目進度中的各種問題。但與其餘方法同樣，敏捷的應用也存在限制，也有其不適合的任務。總而言之，敏捷爲項目經理提供了更多的選擇，讓他們有可能更好地管理項目。

項目管理工具讓項目經理能夠更好地完成本職工做，正確的項目管理工具讓咱們可以在預算範圍內，按時保質地完成工做。Worktile在這方面能夠發揮巨大做用。做爲一個項目管理工具，它爲您提供了實時規劃、監控和報告的方法。

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。