優(yōu)化項目計劃

　　敏捷開發(fā)的基本特征是迭代開發(fā)。而迭代開發(fā)的強調(diào)的是"小批量、頻繁交付"。因此，每次迭代所要實現(xiàn)的需求相對較少。這使得迭代開發(fā)中的項目計劃制定相對容易，制定項目計劃時任務與任務間的邏輯關(guān)系也比較容易掌握。但是，由于迭代開發(fā)往往采用時間盒（Time-box）的方式進行，即要求每次迭代的時間是固定的（業(yè)界推薦的是 2~4 周）。而每次迭代所要實現(xiàn)的需求（Story）的個數(shù)及其難度都不盡相同。這要求我們在某些情況下要盡可能地優(yōu)化項目計劃，以保證工期不會超出時間盒的范圍。

　　優(yōu)化項目計劃的常見方法是盡可能地使各個任務并行。比如，有兩個功能的開發(fā)任務，其中一個功能 A 依賴于另外一個功能 B。但這并不意味著我們必須將這兩個功能的開發(fā)任務串行安排（即先開發(fā) B 功能，再開發(fā) A 功能）。此時，可以使用測試樁（Testing Stub）來模擬 B 功能的實現(xiàn)，這樣使得 A 功能的開發(fā)和測試可以先獨立于 B 功能的實現(xiàn)。因此這兩個功能的開發(fā)可以并行。

　　計劃安排時考慮避免重復勞作也是縮短工期的一個常見方法。在 Story 驅(qū)動的一個迭代開發(fā)過程中，從第二個迭代開始，往往存在多個 Story 的實現(xiàn)涉及同一個模塊的代碼修改。此時，計劃可以安排多個人并行開發(fā)這幾個 Story、但是轉(zhuǎn) Story 測試時，這幾個 Story 可以合并成一個"大 Story"一起轉(zhuǎn)測試。從而避免了多次測試同一個模塊帶來的浪費。

　　出于應對風險的需要在安排計劃時留出所謂的緩沖時間有其合理性。但是，這個緩沖時間延長了任務的持續(xù)時間。而關(guān)鍵任務持續(xù)時間的延長則延長了整個迭代持續(xù)的時間。值得注意的帕金森定律（Parkinson's Law）所闡述的現(xiàn)象卻給了我們在某些情況下要適當壓縮任務尤其是關(guān)鍵任務的持續(xù)時間。帕金森定律告訴我們：只要還有可用的時間，一件工作消耗的時間會不斷地擴展，直到用完所有的可用的時間。也是說，一件任務如果需要 3 天時間完成，而計劃安排的持續(xù)時間是 5 天的話，這個任務會消耗 5 天甚至更多的時間才能完成。這種現(xiàn)象的方面給了我們一個啟示：如果一件任務如果需要 3 天時間完成，而計劃安排的持續(xù)時間是 2 天，那么這件任務真的可能在 2 天內(nèi)完成，多也可能是 4 天時間完成。這也比將該任務計劃為 5 天完成節(jié)省時間�？梢�，過于寬松的機會反而可能拖慢了進度，而有一定緊迫感的計劃所帶來的適當壓力可以激發(fā)人的動力和潛能反而可以加快進度。

　　對于迭代中的技術(shù)風險點要優(yōu)先安排進行驗證。比如，對于從未使用過的技術(shù)或者新技術(shù)，要優(yōu)先安排原型的驗證，避免中途才發(fā)現(xiàn)技術(shù)障礙。

進度信息的獲取

　　由于團隊開發(fā)中的每個團隊成員的日常工作之間都存在或多或少的依賴關(guān)系：某個人的工作要以其他人的一件工作產(chǎn)出為輸入，同時其工作的輸出又是另一個人的某件工作的輸入。

　　從團隊自我管理的角度來說，進度信息是將團隊成員的工作自主得銜接起來的重要因素。因此，敏捷開發(fā)團隊中，進度不應該是只有項目經(jīng)理才關(guān)心的事情，而是整個團隊成員都應該關(guān)心的事情。但事實上，團隊成員往往傾向于只關(guān)心自己手頭上的工作。因此，項目經(jīng)理需要引導和鼓勵團隊成員主動關(guān)注自己手頭上的任務所依賴的任務的進度。

　　另一方面，進度是整個團隊應該關(guān)心的事情，這要求在團隊內(nèi)有一個統(tǒng)一的進度信息獲取與發(fā)布的平臺和途徑。這個平臺可以是一個管理軟件，比如工作流軟件。也可以是一個即時通訊軟件。不管采用什么樣的平臺，項目經(jīng)理應該引導和鼓勵團隊成員主動將各自的進度信息推送到這個平臺，而不是每個人進度還要等其他人來詢問。

　　站立會議也是進度信息的發(fā)布和獲取的一個常見途徑。站立會議中，每個團隊成員都要介紹自己昨天完成了什么，計劃做什么。這樣，每個人的進度信息都可以讓其他人了解到。

定義完成的標準和進度信息的核實

　　獲取進度信息后，要及時對其進行核實。敏捷開發(fā)中的實踐"定義完成的標準"（Definition of Done）可以幫助我們對進度信息進行核實。

下面我們討論什么是完成的標準、定義完成的標準的作用以及如何定義完成的標準。

　　曾經(jīng)有個剛剛開始帶領(lǐng)團隊的人向我咨詢這樣一個問題：他向他的組員分配一個任務，然后他不定期得檢查這個任務的進度�？墒敲看嗡麢z查進度的時候，他的結(jié)論都是這個組員的工作成果沒有達到他所期望的，而這個組員卻是認為自己已經(jīng)完成了當天的任務。這種情形導致這種組員不斷得為返工而加班，后導致其身心俱疲，提出離職申請。事實上，這樣一個問題產(chǎn)生是因為任務的分配者和執(zhí)行者事先沒有約定好什么叫做"完成"。雙方都只是在依照自己心中的"標準"來判斷是否完成，從而導致了對于進度認定的沖突。

　　可見，在我們斷定一個任務是否完成、進行到什么情況前，首先要規(guī)定什么叫"完成"，否則會在衡量進度的時候產(chǎn)生上述例子中的沖突。這種對于什么才叫做完成的規(guī)定叫做完成的標準。顯然，進度不能在脫離質(zhì)量的前提下孤立得衡量，因此完成的標準不僅定義了質(zhì)量要求（通常是低質(zhì)量標準），也是進度衡量的重要依據(jù)。

　　比如，如果你讓一個沒有什么工作經(jīng)驗的人去安裝一個數(shù)據(jù)庫管理系統(tǒng)（DBMS），他很可能是把安裝程序執(zhí)行一遍，若執(zhí)行過程中沒有遇到安裝程序提示錯誤認為是完成了軟件的安裝。而后，其他人都不知道這個已經(jīng)安裝"完成"的軟件的訪問信息，比如它所在機器的 IP 地址、偵聽端口。甚至知道了這些信息后，在實際使用時卻發(fā)現(xiàn)所安裝的軟件根本無法正常運作。

　　其實，對于這樣一個任務我們可以定義一個完成標準：所安裝的 DBMS 要經(jīng)過驗證（比如使用 SQL 能夠在數(shù)據(jù)庫中插入一條記錄，并能夠使用相應 SQL 查詢到插入的記錄），并輸出軟件的相關(guān)使用信息（如軟件所在機器的 IP 地址、軟件的偵聽端口）。

　　可見，完成的標準不僅定義了質(zhì)量要求（通常是一個低質(zhì)量要求），也定義了任務所要交付的產(chǎn)出物。完成的標準所定義的產(chǎn)出物和質(zhì)量要求正是評估任務進度的依據(jù)。一個任務在整個團隊中有了一個大家一致認同的完成標準時，任務完成的質(zhì)量和進度的衡量才不會出現(xiàn)沖突。

進度風險控制

　　進度管理中很重要的一個方面是進度風險控制。

　　提高進度信息的獲取頻率可以盡可能早得發(fā)現(xiàn)進度障礙，為消除障礙爭取了大時間，從而有效減低進度風險。由于敏捷開發(fā)中的一個迭代周期持續(xù)的時間較之傳統(tǒng)項目要短得多，進度信息的獲取頻率也要相應有所體現(xiàn)。筆者通常每天對項目進度信息進行匯總。

　　任務采用認領(lǐng)的方式而非采用分配的方式落實到人，也有助于規(guī)避人力風險導致的進度風險。

　　比如，在需求評審與分析的時候，筆者并不指定誰負責哪個 Story，而是要求全體成員對本次迭代的所有需求都要有所理解，并能夠講解自己對本次迭代中的任意一個需求的理解。敏捷開發(fā)采用迭代的方式，每次迭代所要實現(xiàn)的需求量同傳統(tǒng)項目比較要少得多，這使得每個團隊成員對本次迭代的所有需求都進行理解成為可能。在確認每個團隊成員對本次迭代所要實現(xiàn)的所有需求都有所理解之后，筆者才讓團隊成員對相應需求的開發(fā)測試任務進行認領(lǐng)，具體落實到人。采用這種任務認領(lǐng)的方式，使得每個團隊成員對本次迭代的所有需求都有所理解。從而，在人力變更（如原先負責某個需求的開發(fā)人員請假了）時，可以快速得找到能夠承接任務的人。進而規(guī)避了進度風險。從一開始將需求落實到相應的開發(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 所示。