修復bug與解決問題——從敏捷到精益(2)

　　怎樣從bug中分析問題所在?

　　Bug的出現往往是系統中產生了更常見問題的一種癥狀，而對于精益團隊來說，將這些癥狀與真正的問題相關聯起來是至關重要的?？梢赃@么說，正如米開朗基羅從大理石碎片中發現它的美麗，并最終打造成迷人的雕像一樣，精益團隊的任務(例如某些團隊會將持續改進作為他們每日工作內容的一部分)就是發揮他們的洞察力，從大量的bug中發現問題，并將其抽取出來。實現這一點需要進行細致地分析，并將這些原始的問題轉化為學習的機會。

　　我發現了一種著手進行這種分析的良好方式，就是將所有bug分門別類，并且理解每個bug類別的權重。大多數情況下，某個bug類別就體現了造成某個現有問題的原因，或者它本身就是一個問題。這種關聯性可以幫助你以正確的順序處理這些問題，并首先從對整個操作績效影響最大的問題開始解決。如果你仍然不確定應該從何處著手，那么優先解決質量問題是比較保險的做法。

　　示例1：敏捷開發中的情景

　　當時我在這個使用敏捷開發的團隊中擔任經理一職。和許多團隊一樣，我們團隊也不是一個跨職能的團隊(典型的Scrum-but)，而是一個負責后臺的團隊。它在某個迭代內負責構建基礎服務端軟件，以便讓應用團隊在之后的迭代中使用這部分功能。

　　我們按照Paretos原則(即80-20原則)對產生的bug進行了一些分析，并且找出了一個占總數約20%的bug類別：這些bug都是由應用團隊所提出的，與我們團隊所建立的后臺軟件所暴露的API對“隱式”這一概念的定義有關。當應用團隊在使用我們提供的功能時，經常會發生遺漏了某些輸入參數，或者是缺少了某些輸出數據等問題……因此他們就會為我們創建一些bug，而我們的團隊則會說：嘿!這個API已經隱式地表明了它不會返回這些數據。

　　我們同時注意到了這些bug的持續時間，通常從創建直到關閉為止一共持續了大約4個星期。(在最好的情況下)在以一個月為周期的迭代的最后階段會進行代碼發布，客戶端團隊則可以在下一個迭代時使用這些代碼。因此當客戶端團隊創建了bug，并指派給原來的開發者時，往往距離她開發那些代碼時已經過去了兩三個星期，開發者不得不再度拾起這段代碼……

　　為了處理這種情況，我們決定改變一下工作的方式，將相關人員組織在一起，而產生一個相關聯、跨職能并且跨技能的團隊。

　　采用了新的方式之后，我們注意到這些“隱式API”相關的bug數量大幅下降了(約50%)。最令人欣慰的是，這種類型的bug的持續時間下降到了幾個工作日以內。當然，這個數字有一定的水分，有些bug雖然被發現了，但是并沒有記錄下來，因為開發者們現在進行結對編程，于是許多bug直接在座位上就解決了。

　　雖然成果是顯著的，但我總感覺到還有些不適之處，卻說不出究竟是哪里出了問題。之后不久我才發覺，從精益的角度來說，我們目前還有兩個不足之處：

　　首先，我們的系統中依然存在bug，因此我們不得不重復勞動，這使得整個開發系統出現了生產力的浪費。但是由于缺乏內建的質量標準，我們無法保證服務端開發者所開發的API不存在問題。此外，對于錯誤的處理也沒有真正的標準，我們的解決手段就是：遇到問題就坐下來一起解決。

　　盡管結果非常顯著且令人振奮，但它與團隊的每日績效沒并有什么直接的關聯，團隊也無法立即采取行動并在第二天直接看到結果。我們只是從宏觀上在6個月結束后的發布中才能夠看到這一效果：即在bug總數中與API相關的bug只占少數。因此我們看到：建立一個跨技能的團隊確實能夠在某種程度上改進質量，但我們還未能提供一種有效的方法，讓我們能夠每天監控它的情況，并采取相應的行動。

　　示例2：精益開發中的情景

　　時間轉眼間過去了幾年，我還是任職于同一家公司中，但目前的職位是項目主管及教練，負責一個大型的多團隊、多種技術的敏捷項目的實施。某一個團隊遇到了一個很有挑戰的技術難題，他們要與某個大家都沒有什么經驗的技術進行整合。整個團隊在過去的兩個Sprint中沒有交付任何用戶故事，他們深陷于質量問題(例如bug)中難以自撥。當第二個Sprint結束后，依然沒有任何完成的用戶故事(比方說，按照我們對完成的定義來看，該用戶故事在功能性需求上需要做到沒有任何bug)可以交付。因此在回顧會議中，整個團隊一致決定，將每周進行bug評審(在精益中稱為紅箱分析)。

原文轉自：http://www.infoq.com/cn/articles/bug-fixing-problem-solving