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

　　關于精益的定義有許多，但其中最令我感到鼓舞的是精益企業研究所主席John Shooke在它的著作《管理精益》中所描述的一段話：精益通過提高員工的水平來保證產品開發。在這個定義的基礎上，這篇論文接下來解釋了精益是怎樣提高人員的水平的：方法就是解決問題。這一定義揭示了以下管理實踐的美妙之處：仔細設計你的工作，讓你能夠清晰地看見所發生的問題(以及同時出現的學習機會)，并在問題出現后以科學的方式解決。

　　在與使用敏捷方法進行軟件開發的團隊共同工作時，我曾經有過一些誤解：起初時，我混淆了bug和問題的概念，并且確信敏捷過程就是精益，因為它能夠使bug變得可見。在最后的幾個月里，在我頭腦中的概念開始漸漸清晰起來，回想起當初的情景，我開始相信，我所在的敏捷團隊產生的bug，與精益系統產生的學習機會并不是一回事：后者表明在我的團隊中確實存在著質量問題，而在其它許多團隊身上我也看到了同樣的問題。

　　寫這篇文章的目的，是為了描述我對bug與質量問題這一點上的思考方式是怎樣逐漸變化的。這對于讀者更好地理解造成bug產生的質量問題，并相應地提高績效能夠起到一些啟示作用。并通過一些真實的故事描述來看清楚真正的問題所在。(先聲明一點：我們并不假設所有的敏捷團隊都對此問題抱有類似的誤解)

　　　什么是bug?

　　在軟件工業中，一個bug可以代表任何形式的系統錯誤(NullPointerException、Http 404錯誤代碼或是藍屏……)、功能性錯誤(在我單擊B的時候，系統本應執行Z，卻最終執行了Y)、性能問題以及配置錯誤等等。

　　在精益的術語中，一個bug必須能夠按照下一節提到的定義進行清晰的表達，才能說它是一個問題。請相信我，我所見過的(和自己產生的)bug中，95%以上都不像是某種問題——性能問題或許是個常見的例外情況，但有趣的是，它們也是績效的一部分，不是嗎?

　　什么是問題?

　　讓我們在這里做一個標準的定義吧。在《豐田模式：精益模式的實踐》(Toyota Way Field book)這本書中，Jeffrey Liker定義了一個問題所需的四個方面的信息：

　　當前的實際績效

　　預期的績效(標準績效或目標績效)

　　以當前績效和目標績效之差所體現的問題嚴重程度

　　問題的范圍和特點

　　正如Brenée Brown在TED所做的一次關于漏洞的演講中所說的一樣，如果你不能評估某個漏洞，那么它就不存在。從更實用的角度來說，如果你不能解釋在績效差距上的問題所在，那么很可能是由于你并沒有花足夠的時間去思考它。

　　在開始著手解決一個問題之前，重要的一點是要清晰地表達它，花一定時間去理解它(按照精益專家Michael Ballé的說法：要善待它)，并且克制住直奔解決方案的沖動。我們都聽說過愛因斯坦的名言：“如果我只有一小時的時間去解決一個問題，我會首先用55分鐘去思考問題，最后用5分鐘去思考解決方案。”沒有人說這是件容易的事。

　　在軟件開發敏捷團隊的情境中，績效指標或許是一張燃盡圖(表示工作量與延遲)、bug數量、系統響應時間(質量)、客戶對已提交的用戶故事的評價(以總分10分來表示客戶滿意度)，以及每個Sprint提交的用戶故事(或用戶故事總點數)數量(生產力)。

　　按照這些指標，可以有以下這些問題存在：

　　質量：這個頁面的響應時間目標是在500ms以內，而在5000個并發用戶的情況下，我們測量到的結果是1500ms。

　　質量：在Sprint結束時仍未解決的bug數量(2個，而不是0個)

　　工作量/延遲：我們預計這個用戶故事需要3天時間完成，而實際上用了8天才完成

　　生產力：在Sprint結束時，整個團隊共提交了5個完成的用戶故事，而之前的計劃是完成7個。

　　客戶滿意度：我們希望每個用戶故事都能夠得到8分以上(滿分10分)，而在上個Sprint結束后，有兩個用戶故事的客戶滿意度低于這個分數(6.5分和7分)。

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