敏捷項目管理實戰(zhàn)之進度管理

優(yōu)化項目計劃敏捷開發(fā)的基本特征是迭代開發(fā)。而迭代開發(fā)的強調(diào)的是小批量、頻繁交付。因此，每次迭代所要實現(xiàn)的需求相對較少。這使得迭代開發(fā)中的項目計劃制定相對容易，制定項目計劃時任務(wù)與任務(wù)間的邏輯關(guān)系也比較容易掌握。但是，由于迭代開發(fā)往往采用時間盒(Time-box)的方式進行，即要求每次迭代的時間是固定的(業(yè)界推薦的是 24 周)。而每次迭代所要實現(xiàn)的需求(Story)的個數(shù)及其難度都不盡相同。這就要求我們在某些情況下要盡可能地優(yōu)化項目計劃，以保證工期不會超出時間盒的范圍。優(yōu)化項目計劃的常見方法是盡可能地使各個任務(wù)并行。比如，有兩個功能的開發(fā)任務(wù)，其中一個功能 A 依賴于另外一個功能 B。但這并不意味著我們必須將這兩個功能的開發(fā)任務(wù)串行安排(即先開發(fā) B 功能，再開發(fā) A 功能)。此時，可以使用測試樁(Testing Stub)來模擬 B 功能的實現(xiàn)，這樣使得 A 功能的開發(fā)和測試可以先獨立于 B 功能的實現(xiàn)。因此這兩個功能的開發(fā)可以并行。計劃安排時考慮避免重復(fù)勞作也是縮短工期的一個常見方法。在 Story 驅(qū)動的一個迭代開發(fā)過程中，從第二個迭代開始，往往存在多個 Story 的實現(xiàn)涉及同一個模塊的代碼修改。此時，計劃可以安排多個人并行開發(fā)這幾個 Story、但是轉(zhuǎn) Story 測試時，這幾個 Story 可以合并成一個大 Story一起轉(zhuǎn)測試。從而避免了多次測試同一個模塊帶來的浪費。出于應(yīng)對風險的需要在安排計劃時留出所謂的緩沖時間有其合理性。但是，這個緩沖時間延長了任務(wù)的持續(xù)時間。而關(guān)鍵任務(wù)持續(xù)時間的延長則延長了整個迭代持續(xù)的時間。值得注意的帕金森定律(Parkinsons Law)所闡述的現(xiàn)象卻給了我們在某些情況下要適當壓縮任務(wù)尤其是關(guān)鍵任務(wù)的持續(xù)時間。帕金森定律告訴我們：只要還有可用的時間，一件工作消耗的時間就會不斷地擴展，直到用完所有的可用的時間。也就是說，一件任務(wù)如果需要 3 天時間完成，而計劃安排的持續(xù)時間是 5 天的話，這個任務(wù)會消耗 5 天甚至更多的時間才能完成。這種現(xiàn)象的方面給了我們一個啟示：如果一件任務(wù)如果需要 3 天時間完成，而計劃安排的持續(xù)時間是 2 天，那么這件任務(wù)真的可能在 2 天內(nèi)完成，最多也可能是 4 天時間完成。這也比將該任務(wù)計劃為 5 天完成節(jié)省時間?？梢?，過于寬松的機會反而可能拖慢了進度，而有一定緊迫感的計劃所帶來的適當壓力可以激發(fā)人的動力和潛能反而可以加快進度。對于迭代中的技術(shù)風險點要優(yōu)先安排進行驗證。比如，對于從未使用過的技術(shù)或者新技術(shù)，要優(yōu)先安排原型的驗證，避免中途才發(fā)現(xiàn)技術(shù)障礙。進度信息的獲取由于團隊開發(fā)中的每個團隊成員的日常工作之間都存在或多或少的依賴關(guān)系：某個人的工作要以其他人的一件工作產(chǎn)出為輸入，同時其工作的輸出又是另一個人的某件工作的輸入。從團隊自我管理的角度來說，進度信息是將團隊成員的工作自主得銜接起來的重要因素。因此，敏捷開發(fā)團隊中，進度不應(yīng)該是只有項目經(jīng)理才關(guān)心的事情，而是整個團隊成員都應(yīng)該關(guān)心的事情。但事實上，團隊成員往往傾向于只關(guān)心自己手頭上的工作。因此，項目經(jīng)理需要引導(dǎo)和鼓勵團隊成員主動關(guān)注自己手頭上的任務(wù)所依賴的任務(wù)的進度。另一方面，進度是整個團隊應(yīng)該關(guān)心的事情，這就要求在團隊內(nèi)有一個統(tǒng)一的進度信息獲取與發(fā)布的平臺和途徑。這個平臺可以是一個管理軟件，比如工作流軟件。也可以是一個即時通訊軟件。不管采用什么樣的平臺，項目經(jīng)理應(yīng)該引導(dǎo)和鼓勵團隊成員主動將各自的進度信息推送到這個平臺，而不是每個人進度還要等其他人來詢問。站立會議也是進度信息的發(fā)布和獲取的一個常見途徑。站立會議中，每個團隊成員都要介紹自己昨天完成了什么，今天計劃做什么。這樣，每個人的進度信息都可以讓其他人了解到。定義完成的標準和進度信息的核實獲取進度信息后，要及時對其進行核實。敏捷開發(fā)中的優(yōu)秀實踐定義完成的標準(Definition of Done)可以幫助我們對進度信息進行核實。下面我們討論什么是完成的標準、定義完成的標準的作用以及如何定義完成的標準。曾經(jīng)有個剛剛開始帶領(lǐng)團隊的人向我咨詢這樣一個問題：他向他的組員分配一個任務(wù)，然后他不定期得檢查這個任務(wù)的進度?？墒敲看嗡麢z查進度的時候，他的結(jié)論都是這個組員的工作成果沒有達到他所期望的，而這個組員卻是認為自己已經(jīng)完成了當天的任務(wù)。這種情形導(dǎo)致這種組員不斷得為返工而加班，最后導(dǎo)致其身心俱疲，提出離職申請。事實上，這樣一個問題產(chǎn)生是因為任務(wù)的分配者和執(zhí)行者事先沒有約定好什么叫做完成。雙方都只是在依照自己心中的標準來判斷是否完成，從而導(dǎo)致了對于進度認定的沖突?？梢?，在我們斷定一個任務(wù)是否完成、進行到什么情況前，首先要規(guī)定什么叫完成，否則就會在衡量進度的時候產(chǎn)生上述例子中的沖突。這種對于什么才叫做完成的規(guī)定就叫做完成的標準。顯然，進度不能在脫離質(zhì)量的前提下孤立得衡量，因此完成的標準不僅定義了質(zhì)量要求(通常是最低質(zhì)量標準)，也是進度衡量的重要依據(jù)。比如，如果你讓一個沒有什么工作經(jīng)驗的人去安裝一個數(shù)據(jù)庫管理系統(tǒng)(DBMS)，他很可能就是把安裝程序執(zhí)行一遍，若執(zhí)行過程中沒有遇到安裝程序提示錯誤就認為是完成了軟件的安裝。而最后，其他人都不知道這個已經(jīng)安裝完成的軟件的訪問信息，比如它所在機器的 IP 地址、偵聽端口。甚至知道了這些信息后，在實際使用時卻發(fā)現(xiàn)所安裝的軟件根本就無法正常運作。其實，對于這樣一個任務(wù)我們可以定義一個完成標準：所安裝的 DBMS 要經(jīng)過驗證(比如使用 SQL 能夠在數(shù)據(jù)庫中插入一條記錄，并能夠使用相應(yīng) SQL 查詢到插入的記錄)，并輸出軟件的相關(guān)使用信息(如軟件所在機器的 IP 地址、軟件的偵聽端口)?？梢?，完成的標準不僅定義了質(zhì)量要求(通常是一個最低質(zhì)量要求)，也定義了任務(wù)所要交付的產(chǎn)出物。完成的標準所定義的產(chǎn)出物和質(zhì)量要求正是評估任務(wù)進度的依據(jù)。一個任務(wù)在整個團隊中有了一個大家一致認同的完成標準時，任務(wù)完成的質(zhì)量和進度的衡量才不會出現(xiàn)沖突。進度風險控制進度管理中很重要的一個方面是進度風險控制。提高進度信息的獲取頻率可以盡可能早得發(fā)現(xiàn)進度障礙，為消除障礙爭取了最大時間，從而有效減低進度風險。由于敏捷開發(fā)中的一個迭代周期持續(xù)的時間較之傳統(tǒng)項目要短得多，進度信息的獲取頻率也要相應(yīng)有所體現(xiàn)。筆者通常每天對項目進度信息進行匯總。任務(wù)采用認領(lǐng)的方式而非采用分配的方式落實到人，也有助于規(guī)避人力風險導(dǎo)致的進度風險。比如，在需求評審與分析的時候，筆者并不指定誰負責哪個 Story，而是要求全體成員對本次迭代的所有需求都要有所理解，并能夠講解自己對本次迭代中的任意一個需求的理解。敏捷開發(fā)采用迭代的方式，每次迭代所要實現(xiàn)的需求量同傳統(tǒng)項目比較要少得多，這使得每個團隊成員對本次迭代的所有需求都進行理解成為可能。在確認每個團隊成員對本次迭代所要實現(xiàn)的所有需求都有所理解之后，筆者才讓團隊成員對相應(yīng)需求的開發(fā)測試任務(wù)進行認領(lǐng)，具體落實到人。采用這種任務(wù)認領(lǐng)的方式，使得每個團隊成員對本次迭代的所有需求都有所理解。從而，在人力變更(如原先負責某個需求的開發(fā)人員請假了)時，可以快速得找到能夠承接任務(wù)的人。進而規(guī)避了進度風險。從一開始就將需求落實到相應(yīng)的開發(fā)測試人員，很容易就造成團隊成員只關(guān)注自己手頭上的一畝三分田，從而使得對于需求的理解沒有備份人力，一旦人力變更則很容易影響項目進度。筆者在項目組中強調(diào)一個個人規(guī)避進度風險的原則。該原則要求團隊成員在遇到問題時，通過個人的努力消耗了 30 分鐘而仍然未能將問題解決時，要及時尋求幫助，而不是繼續(xù)在問題上打轉(zhuǎn)，甚至于走進問題的死胡同。當然，團隊成員在遇到自己無法解決的問題時，可能會覺得不好意思讓被人知道，而項目經(jīng)理要消除他們的這種顧慮。尤其是一些工作經(jīng)驗不長的員工，由于個人經(jīng)驗、能力等方面的限制，在遇到問題時候，往往容易只是一門心思地想著要解決問題，而完全沒有顧及到時間。這往往使得他們對于問題的解決就像是走進了一條死胡同，心里明明想要走出去，可是越是往前走，就越是走不出去，而時間卻悄然而逝!進度信息的展示、傳播及其激勵作用Scrum 中提倡的采用燃盡圖(Burn-down Chart)來直觀得展現(xiàn)項目總體進度。它展示了時間和項目剩余總體工作量間的關(guān)系，如圖 1 所示。 圖 1. 燃盡圖筆者認為，燃盡圖更多得是給人以一種壓迫感-讓人清晰直觀得感受到隨著時間的推移，項目所剩的工作量逐天減少!因此，燃盡圖也受到了一定的批判。而燃起圖(Burn-up Chart)則直觀地展現(xiàn)了時間與已完成的工作間的關(guān)系，如圖 2 所示。 圖 2. 燃起圖傳統(tǒng)項目由于項目周期較長，團隊成員往往在漫長的開發(fā)過程中看不到自己的工作成果，慢慢得失去工作的熱情。因此，讓團隊成員看見其工作成果，對其來說也是一種激勵。敏捷開發(fā)由于采用迭代的方式，一定程度上能夠讓員工更快得看到自己的勞動成果。而燃起圖則更加有助于展示團隊的工作成果。因為它將團隊成員的工作成果直觀得展現(xiàn)出來。因此，某種程度上燃起圖不僅僅展示了項目進度，也是對團隊成員的一種激勵形式。狀態(tài)墻則直觀得展示了每個任務(wù)的進度。許多推行敏捷項目管理的團隊，都采用這種方式來管理進度。如圖 3 所示 圖 3. 狀態(tài)墻消除浪費時間是軟件開發(fā)過程中最為稀缺并不可替代的資源。其浪費將直接影響項目的進度。而軟件開發(fā)過程中存在各種各樣的浪費。因此，消除浪費是加快進度的一種重要途徑。返工則是軟件開發(fā)過程中常見的一種浪費。避免返工不僅有利于加快進度，同時也能夠提升軟件的質(zhì)量。敏捷開發(fā)中的一些優(yōu)秀實踐，如定義完成的標準、結(jié)對編程、測試驅(qū)動開發(fā)(TDD)等都有助于避免返工定義完成的標準通過定義質(zhì)量要求和產(chǎn)出物避免返工。結(jié)對編程通過及時的 code review 避免缺陷在后期才被發(fā)現(xiàn)而造成返工。測試驅(qū)動開發(fā)則是通過明確需求，避免因需求理解錯誤引入缺陷而造成的返工。過度設(shè)計也是一種常見的浪費。所謂過度設(shè)計，指在設(shè)計階段為未來可能發(fā)生的變化做過多的預(yù)測，并針對這些預(yù)測在設(shè)計上做過多預(yù)防。正如俗話所說計劃不如變化快，過早地為這些可能根本就不會出現(xiàn)的變化做處理成了一種浪費。因此，敏捷開發(fā)中提倡的是簡單設(shè)計(Simple Design)。所謂簡單設(shè)計并不是沒有設(shè)計，而是采用盡可能簡單的設(shè)計方案。事實上，真正能夠以不變應(yīng)萬變的設(shè)計方案是不存在的。如果它存在，它必然是一種簡單的方案，因為其簡單，它可以被輕易得推倒重來，這才是適應(yīng)萬變的方法。迭代速率(Velocity)與期望值管理迭代速率反映了一個團隊在固定的時間(一個迭代周期)內(nèi)所能交付的 Story 個數(shù)。它反映了團隊的生產(chǎn)能力。前文我們討論的是如何從進度的角度提升這個生產(chǎn)能力加快以及如何保證迭代進度。另外值得注意的是，有時候我們有必要適當?shù)梅怕M度，進而減低團隊生產(chǎn)力。所謂得寸進尺，這反映了項目管理中很重要的一面期望值管理。得寸進尺式的期望值提升告訴我們當團隊生產(chǎn)能力越大，組織上層和客戶對團隊的期望值也就越大。但是，作為團隊的管理者要適當控制他們的期望值的提升，因為團隊的生產(chǎn)能力應(yīng)該有它的上限，而期望值的提升取可能遠比團隊的生產(chǎn)力的提升要來得快，但這無論對于組織和客戶還是團隊來說都不是好事。因此，在進度管理中使得控制迭代進度，不要使其讓人感覺過快，也是進度管理中很重要的一方面。計劃偏差分析與控制布魯克斯法則 ( Brooks Law ) 告訴我們往一個已經(jīng)滯后的項目增加人力會使這個項目更加滯后。不幸的是，當一個項目滯后的時候，往往管理層首先想到的是增加人力，因為這樣他們會安心些。值得注意的是，此時增加的人是否反而使項目更加滯后，某種程度上說取決于我們?nèi)绾问褂眯略龅娜肆?。雖然新增的人力由于對本項目并不熟悉、而本項目原有人力也不可能抽出時間給這些新人培訓(xùn)。但是，我們卻可以以揚長避短的方式去發(fā)揮新增人力的作用把一些不需要項目背景知識的工作交由這些人做，從而使原有的開發(fā)人員能夠集中精力做他們最值得做的事情。比如，可以把開發(fā)過程需要使用的與項目背景沒有直接聯(lián)系的函數(shù)交給新人開發(fā)。也可以將一些非項目開發(fā)相關(guān)的而平時大家又不得不做的一些例行任務(wù)(即通常所謂項目干擾)交由這些人做。從長期的角度看，對計劃偏差進行分析和控制要求我們做以下幾件事情：精確記錄任務(wù)消耗的實際時間愛因斯坦曾經(jīng)幽默地解釋什么是相對論：坐在美女旁邊一小時就像是一分鐘，坐在火爐旁一分鐘則像一小時?？梢?，人對時間的感知在缺乏時間衡量的情況下是多么不可靠。所以，要計算計劃偏差(通常是偏慢了)，必須要有精確的實際消耗時間。一些軟件比如 JIRA 可以幫助我們輕松得記錄每個任務(wù)的實際消耗時間。量化任務(wù)的計劃偏差度量計劃偏差通常有持續(xù)時間偏差和進度偏差，其計算公式如下：持續(xù)時間偏差 (%) =( 實際持續(xù)時間 - 計劃持續(xù)時間 )/ 計劃持續(xù)時間 )*100持續(xù)時間不包含非工作日進度偏差 (%)=( 實際結(jié)束時間 - 計劃結(jié)束時間 )/ 計劃持續(xù)時間 )*100持續(xù)時間偏差反映了任務(wù)實際消耗工作時間與任務(wù)計劃持續(xù)工作時間的偏移程度，而進度偏差則反映了任務(wù)實際結(jié)束時間與計劃結(jié)束時間的偏移程度。對于項目中的關(guān)鍵任務(wù)，進度偏差反映了項目總體進度的偏差。將任務(wù)的計劃偏差進行量化可以讓人清晰、準確認識到偏差的程度。通常，筆者會讓導(dǎo)致計劃偏差的人員自己去計算這兩個指標的值，而不是由專職人員來計算。因為只有讓問題的引入者自己清晰得地意識到問題，這個問題才能從根本上解決。對計劃偏差進行根因分析(Root Cause Ana