圖 3. 狀態(tài)墻

消除浪費

　　時間是軟件開發(fā)過程中為稀缺并不可替代的資源。其浪費將直接影響項目的進度。而軟件開發(fā)過程中存在各種各樣的浪費。因此，消除浪費是加快進度的一種重要途徑。

　　返工則是軟件開發(fā)過程中常見的一種浪費。避免返工不僅有利于加快進度，同時也能夠提升軟件的質量。敏捷開發(fā)中的一些實踐，如"定義完成的標準"、"結對編程"、"測試驅動開發(fā)"（TDD）等都有助于避免返工

　　定義完成的標準"通過定義質量要求和產(chǎn)出物避免返工。"結對編程"通過及時的 code review 避免缺陷在后期才被發(fā)現(xiàn)而造成返工。"測試驅動開發(fā)"則是通過明確需求，避免因需求理解錯誤引入缺陷而造成的返工。

　　過度設計也是一種常見的浪費。所謂"過度設計"，指在設計階段為未來可能發(fā)生的變化做過多的預測，并針對這些預測在設計上做過多預防。正如俗話所說"計劃不如變化快"，過早地為這些可能根本不會出現(xiàn)的變化做處理成了一種浪費。因此，敏捷開發(fā)中提倡的是"簡單設計"（Simple Design）。所謂簡單設計并不是沒有設計，而是采用盡可能簡單的設計方案。事實上，真正能夠以"不變應萬變"的設計方案是不存在的。如果它存在，它必然是一種簡單的方案，因為其簡單，它可以被輕易得推倒重來，這才是適應"萬變"的方法。

迭代速率（Velocity）與期望值管理

　　迭代速率反映了一個團隊在固定的時間（一個迭代周期）內(nèi)所能交付的 Story 個數(shù)。它反映了團隊的生產(chǎn)能力。前文我們討論的是如何從進度的角度提升這個生產(chǎn)能力――加快以及如何保證迭代進度。另外值得注意的是，有時候我們有必要適當?shù)梅怕�進度，進而"減低"團隊生產(chǎn)力。所謂"得寸進尺"，這反映了項目管理中很重要的一面――期望值管理。"得寸進尺"式的期望值提升告訴我們當團隊生產(chǎn)能力越大，組織上層和客戶對團隊的期望值也越大。但是，作為團隊的管理者要適當控制他們的期望值的提升，因為團隊的生產(chǎn)能力應該有它的上限，而期望值的提升取可能遠比團隊的生產(chǎn)力的提升要來得快，但這無論對于組織和客戶還是團隊來說都不是好事。因此，在進度管理中使得控制迭代進度，不要使其讓人感覺過快，也是進度管理中很重要的一方面。

計劃偏差分析與控制

　　布魯克斯法則 ( Brook's Law ) 告訴我們往一個已經(jīng)滯后的項目增加人力會使這個項目更加滯后。不幸的是，當一個項目滯后的時候，往往管理層首先想到的是增加人力，因為這樣他們會安心些。值得注意的是，此時增加的人是否反而使項目更加滯后，某種程度上說取決于我們?nèi)绾问褂眯略龅娜肆�。雖然新增的人力由于對本項目并不熟悉、而本項目原有人力也不可能抽出時間給這些"新人"培訓。但是，我們卻可以以揚長避短的方式去發(fā)揮新增人力的作用――把一些不需要項目背景知識的工作交由這些人做，從而使原有的開發(fā)人員能夠集中精力做他們值得做的事情。比如，可以把開發(fā)過程需要使用的與項目背景沒有直接聯(lián)系的函數(shù)交給"新人"開發(fā)。也可以將一些非項目開發(fā)相關的而平時大家又不得不做的一些例行任務（即通常所謂"項目干擾"）交由這些人做。

從長期的角度看，對計劃偏差進行分析和控制要求我們做以下幾件事情：

精確記錄任務消耗的實際時間

　　愛因斯坦曾經(jīng)幽默地解釋什么是相對論：坐在美女旁邊一小時像是一分鐘，坐在火爐旁一分鐘則像一小時�？梢�，人對時間的感知在缺乏時間衡量的情況下是多么不可靠。所以，要計算計劃偏差（通常是偏慢了），必須要有精確的實際消耗時間。一些軟件比如 JIRA 可以幫助我們輕松得記錄每個任務的實際消耗時間。

量化任務的計劃偏差

　　度量計劃偏差通常有持續(xù)時間偏差和進度偏差，其計算公式如下：

持續(xù)時間偏差 (%) =(( 實際持續(xù)時間 - 計劃持續(xù)時間 )/ 計劃持續(xù)時間 )*100［持續(xù)時間不包含非工作日］

進度偏差 (%)=(( 實際結束時間 - 計劃結束時間 )/ 計劃持續(xù)時間 )*100

　　持續(xù)時間偏差反映了任務實際消耗工作時間與任務計劃持續(xù)工作時間的偏移程度，而進度偏差則反映了任務實際結束時間與計劃結束時間的偏移程度。對于項目中的關鍵任務，進度偏差反映了項目總體進度的偏差。

　　將任務的計劃偏差進行量化可以讓人清晰、準確認識到偏差的程度。通常，筆者會讓導致計劃偏差的人員自己去計算這兩個指標的值，而不是由"專職人員"來計算。因為只有讓問題的引入者自己清晰得地意識到問題，這個問題才能從根本上解決。

對計劃偏差進行根因分析（Root Cause Analysis）

　　有了計劃偏差度量值后，固然要對這些度量值進行根因分析，以便找到規(guī)避和改進的措施。

　　但是，這些規(guī)避和改進措施，通過由專人（比如，項目經(jīng)理自己）給出然后交由開發(fā)、測試人員去執(zhí)行其效果不見得落實到位，因為這些措施對于其執(zhí)行者來說，它們都是"別人"的，不是執(zhí)行者"自己"的東西。

　　筆者則將根因分析的方法教給團隊成員，然后由團隊成員自行對偏差進行分析，并給出他們自己的規(guī)避和改進措施。筆者在組織全體成員對這些分析和改進措施進行討論，然后幫助團隊成員跟蹤和落實這些改進措施。

結論

　　本文分享了縮短項目工期的實踐以及進度信息的獲取、展現(xiàn)與核實。并討論項目進度管理與項目風險管理以及期望值管理間的關聯(lián)。