對從事專案管理的人員來說，敏捷已經成為一場席捲全國的風潮。但敏捷並不是什麼新事物，它已經有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官網：www.worktile.com
內容整理：worktile
如何評判OpenStack是否適合你
傳統架構難以保證業務關鍵性應用虛擬化技術穩定性，部署管理複雜。你的資料中心可能，也可能不需要乙個可擴充套件的開源雲。你的設施準備好應對架構中儲存與硬體的爆發式增長嗎?每個it廠商都希望說服資料中心管理員，他們的基礎設施如果沒有上雲，就不是最先進的。但雲技術真的會被認為是最先進的嗎?什麼樣的雲才是最先...
如何確定自己是否適合做程式設計師
衡量乙份工作是否適合自己的標準至少有三個 你所擅長的 你所喜歡的 對你最有價值的 最能掙錢的 如果你把世界上所有的工作按自己的標準分類到這三個組裡，理想的狀態是這三個組存在交集上，然後你從這個交集裡選乙個。然而不幸的是，對有些人來講，這三者的交集為空，還有更不幸的情況是任意兩組交集都為空，最不幸的情...
敏捷方法適合什麼樣的團隊？
敏捷開發適用於研發團隊嗎？距敏捷開發宣言的發布已經過去了將近二十年，現在很多團隊都在思考 敏捷 的工作方式。營銷團隊想要嘗試sprint的方式來加速盈利，運營團隊正在採用scrum敏捷專案管理，而人力資源團隊則正在尋求如何為公司戰略注入更多的靈活可變性。那麼對於研發團隊而言，敏捷實際上只是一套幫助解...