性。在實(shí)際操作時，我們讓團(tuán)隊(duì)成員每天對其參與的每一任務(wù)都鍵入下列兩項(xiàng)數(shù)字：1）該任務(wù)花費(fèi)時間，和2）該任務(wù)所剩時間。結(jié)果就會生了類似如下的燃盡圖。
如圖所示，起初這項(xiàng)目被估計(jì)是要3480小時完成。大致上來說，一般的研發(fā)團(tuán)隊(duì)因著人員請假、會議和其他突發(fā)事情，平均每人每天只能有六小時花在實(shí)際項(xiàng)目工作上?，F(xiàn)這項(xiàng)目有七個人參與，估算出來大約需要四個月完成。（也就是從2009年11月29日到2010年3月29日，圖中紅色直立線為起始線，藍(lán)色直立線為終止線。）這圖里共有三條曲線。紅色號碼?/span>表示到現(xiàn)在為止在該項(xiàng)目的總花費(fèi)時間，紅色號碼?表示估算的項(xiàng)目剩余時間，紅色號碼?是到目前為止所花的時間與剩余時間之和的曲線。到了2010年3月21日就得到了上面的這個圖。到了這一天，我們發(fā)現(xiàn)原本估計(jì)的3480總小時數(shù)是低估了，更可能的是?所示的3740小時。
以縱軸的性質(zhì)區(qū)分，燃盡圖可以分為兩大類，即縱軸可以是時間或是事件。以范圍區(qū)分，燃盡圖至少可以分為三類：項(xiàng)目級的、任務(wù)級的和需求級的。透過燃盡圖，我們可以看到項(xiàng)目進(jìn)行的情況，項(xiàng)目需求是否按計(jì)劃進(jìn)入開發(fā)流程，工作是否有延時，或者工作安排的飽和度是否適合。如上圖所示，我們可以輕易地看到，照著現(xiàn)在的進(jìn)度，這項(xiàng)目最可能會延期6到7工作天。當(dāng)高層看到這圖時，就可以在資源上做調(diào)動，以避免延期產(chǎn)生的不良后果。
我們刻意使用了這個較理想的圖做講解，為的是讓讀者更容易理解。它不是個典型的圖。在大多情況，使用燃盡圖會是比較復(fù)雜的，因?yàn)樗赡馨诵枨笏鸭⒕幊?、單元測試、集成測試和缺陷修復(fù)，并且還可能有迭代。所以估算時間會較困難。這個燃盡圖的過程是比較穩(wěn)定的，結(jié)果是比較理想的，其原因至少有二：（一）項(xiàng)目里單純地只有編程、單元測試和缺陷修復(fù)任務(wù)，全都由程序員搞定；它里頭沒有需求搜集、集成測試或其他任務(wù)。（二）這個項(xiàng)目復(fù)雜度低，約一半的編碼任務(wù)是機(jī)械性的，所以估出來的時間較為準(zhǔn)確。
（2） 固化工作流以管控過程
對于公司里既定的流程，我們在DevSuite里以圖形化的工作流將其固化。下圖就是以前面王總監(jiān)提到的需求變更流程設(shè)計(jì)出來的。
這工作流指明了，在一個變更事件被創(chuàng)建后，它需要經(jīng)過一個《評審》狀態(tài)。在評審階段里，有三個人（A，B和C）要全部同意，才能到達(dá)《通過》狀態(tài)。有任何一人不同意，狀態(tài)就轉(zhuǎn)到《拒絕》。當(dāng)一到達(dá)《評審》狀態(tài)，系統(tǒng)馬上促發(fā)郵件和手機(jī)通知，將信息寄給A，B和C。系統(tǒng)可以預(yù)先設(shè)定這三人有兩天的時間評審該變更。假如兩天過了，狀態(tài)仍為《評審》，那就是有人未及時處理該事件。這時候，系統(tǒng)會自動將事件升級，把狀態(tài)轉(zhuǎn)換為《升級處理》，系統(tǒng)馬上促發(fā)郵件，將信息寄給研發(fā)部王總監(jiān)。王總監(jiān)可以斟酌情況，做最妥善的處理。
使用固化的工作流至少有四個優(yōu)點(diǎn)：1）提高通知效率 ?郵件和手機(jī)自動通知提高效率，溝通出錯的機(jī)會減少了；2）避免流程出錯 ?DevSuite的工作流將流程完全自動化，每個人在收到郵件或短信通知時，照著工作流中既定的步驟操作就行了，省心又省力； 3）工作流變動時處理很容易 ?當(dāng)流程或人員變動時，系統(tǒng)配置員可以輕易地花幾分鐘就做完調(diào)整，之后所有團(tuán)隊(duì)成員就照著流程走便行了；4）避免摩擦?人是有情緒的，固化的工作流使得操作完全對事不對人，避免了人和人之間不必要的摩擦。
以上提到的軟件項(xiàng)目風(fēng)險(xiǎn)實(shí)例幾乎在每個項(xiàng)目中都出現(xiàn)，而且，它們造成的