敏捷開發之“燃盡圖之謎”
敏捷開發之“燃盡圖之謎”
我們在進行敏捷開發的時候，一般都要畫燃盡圖，在我們理想的思維裏面，燃盡圖很明白易懂的，而實際使用的時候，你慢慢發現不是這麼一回事，這究竟是怎麼回事呢？
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 進度變動怎麼辦？
一般的說法，敏捷開發的進度是固定的，是不能變動的，但是在中國，啥事都可能發生。如果進度變了，我們可能有下面幾種方法來解決：
1、 重新那張紙來畫刻度。
2、 原先的刻度就不是畫上去的，而是拿着橡皮筋別上去的，現在重新移一下
3、 棄用燃盡圖
7 敏捷工具自動畫燃盡圖可信嗎？
想 JIRA 這樣的工具，都是能夠自動畫出燃盡圖的，不過嘛，我覺得，這樣的燃盡圖根本是沒有作用的，理由如下：
1、 燃盡圖需要每位員工的很忠實的記錄工作日誌，少記、不記都將影響到燃盡圖的效果
2、 工作日誌是寫在每個故事上面的，這樣就會少記很多工時，比如說， 8 個小時中，有 6 個小時是處理某個故事的，有 2 個小時是處理郵件、接電話等，我們在故事寫上真實的時間，往往比我們真實的會少。
3、 燃盡圖中途增加本來已經計劃過的故事，結果的圖形會往上走。
最重要的一點，就是燃盡圖本來就是比較容易統計的一個指標，按照 JIRA 等工具進行統計，結果往往是花了很大的力氣，圖形的走勢仍需是千奇百怪，無法正常知道開發。還不如在每天晨會的時候，花點時間瞭解大家的完成情況，就可以畫出一個正常的燃盡圖了。