什麼是項目管理的“敏捷”

作者:樑珂 易佳諮詢學員

什麼是項目管理的“敏捷”

眾所周知,船舶出航前是要制定周密的航行計劃的,對出航期間的水文、天氣、海況要瞭如指掌,將電/磁羅經、六分儀、觀通導航設備進行徹底的檢查與校準,尤其是航海長必須對航海圖上的航線爛熟於心。那麼從理論上講出航之後按照既定的航行計劃走就是了。可為什麼在途中還要設置諸多檢查點,在檢查點上航海部門要重新校準積算艦位?有航海經驗的人都明白,航行計劃在實際航行過程中受到諸多因素的影響,單憑儀表盤和圖紙是無法保證航行安全的。同理,在項目管理過程中,單憑事前制定的一成不變的計劃也很難保證項目的最終成功。

於是,“敏捷”一詞便引入了項目管理過程中。

其實,敏捷開發對項目經理來説並不陌生。近年來,國內越來越多的互聯網軟件公司也開始採用敏捷開發的方法來做項目管理,在很多公司的桌椅旁邊到處可見白板和貼滿各種顏色便籤的任務牆,然後,每天大家圍着白板開個站會,這其實就是敏捷開發的特徵。敏捷的反義當然是不敏捷,但是這個“不敏捷”在軟件工程裏面卻有個專業的術語叫做“瀑布式開發”。

傳統項目管理通常採用的是瀑布式、部分迭代開發模式,要求在項目開發時,需求足夠明確、文檔足夠規範,迭代過程中需求變更越多、越晚,對項目影響越大,會影響到項目的交付質量。敏捷項目管理簡化了傳統項目管理的繁瑣流程和文檔。以 Scrum 為代表,歡迎需求變更,在客户整體需求不明確的時候,以在較短的週期內開發出可用的軟件或功能為目標,來幫助客户描述自己的需求。

傳統項目管理一般分為五個過程組:啟動、規劃、執行、監控、收尾。還有十大知識領域,要對項目的所有過程和領域進行管理和風險把控,並要求在不同環節的有輸入和輸出。如果採用傳統的項目管理模式,每個環節都必須要進行嚴格的規劃,一旦出現規劃以外的變更,都需要經過審批後才能執行改變。

敏捷項目管理簡化了繁瑣的流程和文檔管理,主張團隊內部的面對面溝通和交流。簡單、持續集成、不斷交付、價值優先、擁抱變化的原則在面對時刻變化的需求。包括代碼部署頻率、從提交到部署的前置時間、變更失敗率、故障恢復時間都較之傳統項目管理有很大的不同。儘管敏捷方法帶來了一些成功案例,但還是有很多因素阻礙它被廣泛採納。敏捷方法的組織和管理者經常發現:在應用過程中,對頻繁的動態變更很難得到管理方面的支持。這些方法需要開發者、管理者和用户都改變他們工作習慣和思考的方式。從規劃和設計,計劃與跟蹤,迭代開發,持續交付這些方面。敏捷開發意味着不斷推翻之前的原型。這就對項目的風險控制產生了極高的要求。傳統項目管理要求項目在規劃過程中規劃風險管理、識別風險,並且對風險進行定性/定量分析,給出風險應對方案。雖然已知的風險可以在被識別和分析後採取應對措施,但正是因為風險的不確定性,要求項目風險管理必須給未知風險或者已知卻又無法主動管理的風險分配一定的儲備。因此,傳統項目管理會要求提供風險登記表,並且記錄風險應對措施在處理已識別風險及其根源方面的有效性,完成風險再評估和風險審計,直到風險被降到最低。

有的公司把敏捷項目的開發評估以工作量為導向而非時間導向。需求到交付階段作為整個設計階段。敏捷管理在高度變化的項目中始終關注價值、質量和約束條件。承認在開發過程中的變化是正常的,計劃是用來適應變化的,並在這個過程中不斷調整。所以,在進行開發任務評估時採用的是相對估算而不是絕對估算,為風險留了應對空間。將計劃本身作為管理單元,計劃對變化的適應能力來源於計劃本身粒度的縮小。在項目沒有正式結束前,交付的可用軟件是允許風險存在的,並且是根據風險的優先級來進行排期修復。

由於在敏捷開發中軟件的很多功能是不可能被預定義的,更多的用户直接參與到設計過程中,功能需求即用户需求的轉化,項目開發的管理屬性和工程屬性的銜接點實際上就是版本管理,持續交付就是解決系統耦合性的問題(代碼級耦合、組件級耦合、服務級耦合)。那麼,如何在敏捷開發項目中更有效的進行運作和管理?

優化流程,減小耦合

將服務、功能和任務包進行更小的拆分,進一步減少它們之間的耦合度,減小各個環節交接時所產生的浪費。各個環節之間建立合適的緩衝區,降低工作流程中的同步時間。做好可視化看板的管理,不但要做好每日站會,而且在各個過程中設置檢查點,及時互動溝通,收集反饋。

控制粒度,及時交付

在移動互聯網時代,隨着時間的變化,市場環境、用户需求、競爭對手等因素都在時時發生着改變,需求方會不斷地賦予產品新的需求來應對這種變化。為了讓需求方儘早地看到結果,我們就應該以控制開發和交付過程的顆粒度、小步快跑的姿勢來做產品,儘早地交付新的版本。對於敏捷來説,給用户快速交付可用的軟件勝過宂長的完備的各類文檔。這也意味着產品交付的時間間隔越來越短,也縮短了產品的迭代週期,

項目計劃是用來適應敏捷變化的

敏捷並不意味着不做項目計劃,恰恰相反的是,敏捷更加注重計劃的制定,但計劃應該具有足夠的彈性與針對性。因為敏捷開發就是為了能夠及時地響應用户的需求,所以並不會死守着項目開始時的計劃不進行調整,一旦情況發生變化,即使到了開發後期,敏捷管理也接收需求的改變,不斷地修正自己原先的計劃,利用變化來為產品創造競爭優勢。

迭代版本週期內儘可能少的添加任務

儘管敏捷開發的目的是為了儘量讓產品能夠適應市場及用户需求的變化,但也並不意味着可以毫無節制地添加和修改項目任務。從這個角度來看,我們可以把每個版本迭代看作一次小的瀑布式開發,那麼,每個版本都有自己的開始時間和結束時間,也在項目剛開始的時候就配置了相關的資源來實現此次迭代的需求,如果臨時突然插入新的需求或是修改需求的話,肯定會對項目的進度產生影響。所以,還是儘量在版本開始前就規劃清楚一些,除非碰到特殊情況,否則盡肯能的做到版本迭代週期內不加任務。

進行敏捷的團隊結構配置

為了實現項目的敏捷,在團隊結構上也是需要進行敏捷編組。在當前的情況下,一個敏捷的項目團隊規模將會被做限定,人數太多的話可進行團隊分組。將相互強關聯的部門進行合併,比如測試部門合併進研發部門等。每個團隊人員不超過二三十人,拿每日站會來説,也是要基於敏捷的團隊的配置才能更好的完成。如果一個辦公場地,站滿了幾十上百人,每個人説一下自己的日常工作,那麼基本上一個上午的時間就過去了,這是效率非常低下的一種表現形式。相反,項目成員在一個辦公室進行辦公將會大大提高溝通效率,有什麼問題可用直接面對面地解決。這樣的話,也可以充分利用辦公室裏的白板和空間。

敏捷也是需要總結的

項目階段完成或結束時一定有項目總結的,在敏捷環境下,項目團隊成員也需要定期對前一個或者前一段時間的工作進行總結,以便調整自己的行為,提高項目的開發效率。因為很多不確定的因素都會導致原計劃變更,比如需求的變更、人員的變動、組織戰略的變化等等都會讓我們做出不同的反應。在每次失敗中進行反思,吸取經驗教訓,其實是對敏捷的進一步認識,團隊成員只有通過不斷地總結、反思和調整,才能更好地保持團隊的敏捷性。

本文發表於 易佳雲課堂-互動專區實戰經驗專欄 。未經許可,禁止轉載!

瞭解更多PMP、NPDP諮詢請關注青島易佳諮詢!