敏捷開發之「燃盡圖之謎」

原文：http://blog.csdn.net/sunlen/article/details/4843239

  

1     燃盡圖的起點是迭代當天仍是迭代前一天？

2     用工時仍是故事點來計算剩餘工做量？

3     只統計開發任務仍是包括測試呢？

4     測試Story就是不能關閉？

5     中途加班如何控制？

6     進度變更怎麼辦？

7     敏捷工具自動畫燃盡圖可信嗎？

 

咱們在進行敏捷開發的時候，通常都要畫燃盡圖，在咱們理想的思惟裏面，燃盡圖很明白易懂的，而實際使用的時候，你慢慢發現不是這麼一回事，這到底是怎麼回事呢？

1         燃盡圖的起點是迭代當天仍是迭代前一天？

畫的燃盡圖的起點是迭代開始當天，仍是迭代前一天呢？終點是迭代結束當天，仍是迭代結束的下一天呢？咱們經過敏捷管理工具JIRA觀察，發現JIRA工具將啓動設置爲迭代開始當天，而結束點設置爲結束的下一天。以下，迭代週期爲2009年10月20號到2009年11月16號，而燃盡圖的起點設置成了10月20號，結束點設置成了11月17號。

 

 

因爲JIRA是一個自動統計工具，因此這樣畫沒有問題，但若是是咱們手工畫燃盡圖呢？通常來講，咱們畫燃盡圖，有兩個時間點，一個是在早上，通常是幹活以前，一個是在晚上，或下班前。我好比說在21號早上（或20號晚上），咱們通常的習慣是會標誌上20號的那個點上，而不是標誌在21號上，不然可能讓人以爲奇怪，爲何21號尚未過，就開始給它畫上點呢？因此，應該說，手工畫圖，更合理的方式是設置起點爲迭代開始的前一天，終點爲迭代結束那天。

2         用工時仍是故事點來計算剩餘工做量？

JIRA工具提供兩種燃盡圖，其實就是縱軸計算單位的不一樣，一種是用工時來統計，也就是工做量的小時數；一種是用issue來統計，也就是還剩下多少個故事。

咱們細心分析，就會發現這兩種統計方式都是存在問題的。用工時來統計，這是咱們通常經常使用的方法，但工時準確嗎？根據我開發這麼多年的經驗，通常在開發初期估算出來的工時，不是通常的不許確，而是很不許確，開發人員通常帶有很嚴重的樂觀傾向，總以爲作某個事情很easy，兩三天就搞定，結果一週還沒搞定，加上敏捷開發須要測試和問題修改等，結果工時是嚴重的不許確。另外，工時的統計量過度細化，很難精確量化，好比說，昨天剩餘900小時的工做量，今天5我的，每一個人幹了8小時，那今天就剩下860小時的工做量了？你若是這個統計，那好，你的圖形基本是和符合燃盡圖的虛線了，你卻發現，工時用完了，還有大量的工做量沒有完成了。比較合理的作法，是咱們天天再來統計剩餘工做的工做量，若是是用工時，那光統計工時都很耗工做量了，並且問題是，如何統計呢？這能靠開發人員嘴上說說，而後管理員一頓狂計算。從這點來講，人天還好一點，只是工時仍然是一個不許確的值而已。

用issue來統計，你會發現更離譜，由於每一個issue的工做量不同，相差還挺大，並且，通常來講，issue都是比較粗粒度的，若是按照issue來統計，你會發現一連不少天，可能都是一條橫着的線。

因此我建議採用故事點作爲縱軸，因此故事點，是一個虛擬的基準單位，是用來作相對統計的，好比說，我估計一個迭代中大概有30個故事點的工做量，那這30個故事點大概是多少人天的工做量呢？對不起，不知道，但我能夠在迭代前給你一個大概估算的值，好比說，我估算了1個故事點大概是4人天，那30個故事點就是120人天的工做量了。好了，在迭代二，假設4我的開發了一週，也就是花了20人天的工做量，照理說應該完成5個故事點的工做量，結果發現只完成了3個故事點的工做量，那好，我立刻修正每一個故事點工做量的估值，咱們初步定成6人天，那麼30個故事點就變成180人天了。

故事點的大小要計算合適，我建議是以半天到一天（不是一人天）作爲大概的估算點，好比說，4我的開發，那一個故事點大約包含4～8人天的工做量，那麼咱們天天畫圖可以平均往下畫1~2個故事點，太多了以爲統計麻煩，太少了以爲天天都沒有變化。

3         只統計開發任務仍是包括測試呢？

敏捷開發實際上是以故事爲單位的，它的一個完成過程是包含了設計、開發、測試、返工的，那麼咱們畫的燃盡圖是應該包含這4部分，仍是隻有開發呢？你可能會脫口而出，認爲確定是包含4部分的，而實際使用中，你可能發覺並非這麼一回事。

下面是著名的《硝煙中的SCRUM and XP》一書中提到的處理迭代關係的一種方法，

它的意思大概指：咱們在迭代一完成後，即進行迭代二的開發，迭代二中間優先處理迭代一發現的Bug。

 

 

仔細觀察上面的過程，上圖的紅色部分，實際上是迭代一的測試和返工部分。這實際上是在告訴咱們，迭代一的真正結束時間，實際上是1.01那個點，而不是1.00，而咱們若是以1.00作爲結束點的話，那麼必然是到最後結束點的時候，咱們的燃盡圖是不閉合的。若是你硬性將設計、開發、測試、返工都畫到燃盡圖中，那麼好比畫出的燃盡圖，必然往上偏離參考線，那麼以這個作爲調整工做量的參考，還有意義嗎？

而後在看最後一個迭代，它跟上圖的迭代一不同，它除了須要處理上一個迭代的Bug以外，還須要處理本迭代的全部Bug，由於已經沒有迭代能夠繼續處理Bug了。

因此，比較合理的方案，我以爲應該是這樣的，迭代一去掉上面紅色部分的工做量；迭代二則加上紅色部分工做量，去掉劃到迭代三的工做量；最後一個迭代只加上上個迭代測試返工部分的工做量。

這裏還有一個問題，就是設計的工做量，設計工做並非有開發人員完成的，而是由設計人員（架構師、分析師等）在迭代開始以前就完成了的，咱們把這個迭代開始前進行的設計工做叫作迭代0。若是是這種方式的話，咱們在迭代中就不該該統計設計時間。

這裏還有問題，迭代一的時候，前期開發人員在作設計開發工做，測試人員投入就少，後期隨着故事一個一個被開發出來，測試投入的工做量就大了，那麼其實迭代一的圖形，理論上的參考線應該不是一條直線，而是一條微微向上突的曲線纔對。

 

4         測試Story就是不能關閉？

上面說了這麼多，但說到測試，頭就大了。對於開發，咱們能夠估算今天開發了1/5，明天開發了2/5，到了週末，功能開發出來了。而對於測試呢，一切數據均是虛幻，你不知道測試狀況如何，測試出來的問題單少，多是版本的質量好，也多是測試不充分，它很難找到一個衡量測試效果的方法。另外，敏捷開發是按照故事來進行的，對測試來講，如何保證這個測試的充分？好比說，預計某個故事須要測試1周，那好，開發完成了，將故事移交給測試人員測試了一週了，沒有發現問題了，那麼是否是這個故事就能夠關閉了呢？我假設關閉了故事點，那後續這個故事還能不能測試呢？極可能這一週中，測試人員就對這個故事沒怎麼測試，而後你滿心歡喜，覺得質量很好，哪知道，等轉SDV測試後，卻發現測試部開始大量提交這個故事的問題單了。

另外，通常認爲不能對測試逼得太緊，太緊了，極可能會致使測試不充分。

那麼，是任由故事遲遲不關閉，一直處於測試狀態嗎？還有啊，測試發現問題，須要開發人員返工，而後測試又進行測試，這個週期常常很長，致使故事點常常是處於「測試中」。

我以爲，其實這至關於一個長尾理論，前面的測試工做很集中，然後面則拖着一個長長的尾巴，咱們能夠定一個範圍，好比說測試完成了90%，則轉入關閉狀態，這樣就能夠把後面的尾巴砍斷了。若是對這個尾巴還不放心，咱們還能夠設置一種狀態，好比說叫「測試驗證狀態」或「後續測試狀態」，主要測試工做完成後，就能夠進入這個狀態了。

另外，測試工做老是跟隨在開發後面的，開發完成一個故過後，測試才能真正對功能進行測試，這就致使測試的工做是沒法平均分配的，有時無東西可測，有時一大堆測試任務。針對這種狀況，首先是開發的計劃須要作得比較合理一點，儘可能不要把全部故事都在同個時間完成；另外，測試人員最好可以動態調節，把測試人員分爲兩部分，一部分是純粹的測試人員，一部分則是由開發人員承擔，在測試任務比較空閒時，開發人員作開發人員，在測試任務比較忙時，部分開發人員則承擔起測試的任務。

 

5         中途加班如何控制？

由於燃盡圖是一開始就畫出了時間點，因此若是出現中途加班的狀況，那是沒有辦法，當天的燃盡圖就不用畫了。

6         進度變更怎麼辦？

通常的說法，敏捷開發的進度是固定的，是不能變更的，可是在中國，啥事均可能發生。若是進度變了，咱們可能有下面幾種方法來解決：

一、  從新那張紙來畫刻度。

二、  原先的刻度就不是畫上去的，而是拿着橡皮筋別上去的，如今從新移一下

三、  棄用燃盡圖

 

7         敏捷工具自動畫燃盡圖可信嗎？

想JIRA這樣的工具，都是可以自動畫出燃盡圖的，不過嘛，我以爲，這樣的燃盡圖根本是沒有做用的，理由以下：

一、  燃盡圖須要每位員工的很忠實的記錄工做日誌，少記、不記都將影響到燃盡圖的效果

二、  工做日誌是寫在每一個故事上面的，這樣就會少記不少工時，好比說，8個小時中，有6個小時是處理某個故事的，有2個小時是處理郵件、接電話等，咱們在故事寫上真實的時間，每每比咱們真實的會少。

三、  燃盡圖中途增長原本已經計劃過的故事，結果的圖形會往上走。

 

最重要的一點，就是燃盡圖原本就是比較容易統計的一個指標，按照JIRA等工具進行統計，結果每每是花了很大的力氣，圖形的走勢仍需是千奇百怪，沒法正常知道開發。還不如在天天晨會的時候，花點時間瞭解你們的完成狀況，就能夠畫出一個正常的燃盡圖了。