對從事項目管理的人員來說,敏捷已經成為一場席捲全國的風潮。但敏捷並不是什麼新事物,它已經有20多年的歷史。正如社交媒體圈子所說的那樣,敏捷的聲勢與流行程度正在逐年見長。但敏捷是不是真的如坊間傳聞的那樣,是一個可以解決所有項目困境的萬能葯?
當然不是!但敏捷的確是一種比較好的項目管理方法。敏捷為項目負責人及其團隊提供了一些獨特的優勢。
我們之前將敏捷方法與傳統的瀑布流方法進行了比較。敏捷這種軟體開發領域的項目管理辦法,在過去數年有著強勁的發展勢頭。它解決了產品需求與開發等方面的不確定性。與之相較的瀑布流方法則試圖將項目生命週期的各階段,即啟動、計劃、執行和收尾等,按照嚴格的結構順序進行組織。
什麼是敏捷?
要確切定義何為敏捷非常困難。不同的人可能會給出不同的答案。敏捷這個大範疇內包含下面幾個體系,如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。
敏捷將項目規劃變成了一個貫穿整個項目生命週期的迭代過程。「fail-fast」這個術語體現了對迭代的渴望,即通過先將開發出的不完美的產品提供給客戶使用,以收集客戶的反饋。
客戶的反饋至關重要。傳統的項目管理方法要求項目需求在項目開始之前就要收集並確定好。但敏捷方法則不同,敏捷更加實用和高效,要求產品負責人和關鍵利益相關者在產品開發過程中,參與構建和測試。
這樣做能夠大大節省時間。為什麼我們需要花上三個月的時間收集需求,再花上四個月的時間開發產品,到最後才發現開發的產品並不是客戶真正想要的?為什麼我們不能夠開發一部分之後,展示給客戶,將反饋整合到產品的開發中,然後不斷重複這個過程並在更短的時間內構建客戶想要的產品?簡而言之,這就是敏捷的目標。
使用敏捷的最佳條件是什麼?
當我們無法確定產品的需求是什麼時,最好使用敏捷方法。從收集用戶故事開始就讓產品負責人和Scrum團隊參與進來能夠讓我們更高效地利用時間。用戶故事是產品負責人希望開發的功能和特徵的簡要描述。
然後,根據這些軟體功能,產品負責人和Scrum團隊創建一個名為Product Backlog的待辦事項列表。建立Product Backlog後,Scrum團隊就會創建Sprint Backlog。客戶所需的產品功能將會被安排在不同的Sprint中完成。因此,Sprint中是下一個版本中的功能,這麼做的目的是為了每次都開發和部署產品的一小部分功能。