敏捷項(xiàng)目管理實(shí)戰(zhàn)之進(jìn)度管理

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