修復bug與解決問題——從敏捷到精益
英文原文：Bug Fixing Vs. Problem Solving - From Agile to Lean
關于精益的定義有許多，但其中最令我感到鼓舞的是精益企業研究所主席 John Shooke 在它的著作《管理精益》中 所描述的一段話：精益通過提高員工的水平來保證產品開發。在這個定義的基礎上，這篇論文接下來解釋了精益是怎樣提高人員的水平的：方法就是解決問題。這一 定義揭示了以下管理實踐的美妙之處：仔細設計你的工作，讓你能夠清晰地看見所發生的問題（以及同時出現的學習機會），并在問題出現后以科學的方式解決。
在與使用敏捷方法進行軟件開發的團隊共同工作時，我曾經有過一些誤解：起初時，我混淆了 bug 和問題的概念，并且確信敏捷過程就是精益，因為它能夠使 bug 變得可見。在最后的幾個月里，在我頭腦中的概念開始漸漸清晰起來，回想起當初的情景，我開始相信，我所在的敏捷團隊產生的 bug，與精益系統產生的學習機會并不是一回事：后者表明在我的團隊中確實存在著質量問題，而在其它許多團隊身上我也看到了同樣的問題。
寫這篇文章的目的，是為了描述我對 bug 與質量問題這一點上的思考方式是怎樣逐漸變化的。這對于讀者更好地理解造成 bug 產生的質量問題，并相應地提高績效能夠起到一些啟示作用。并通過一些真實的故事描述來看清楚真正的問題所在。（先聲明一點：我們并不假設所有的敏捷團隊都 對此問題抱有類似的誤解）
什么是 bug？
在軟件工業中，一個 bug 可以代表任何形式的系統錯誤（NullPointerException、Http 404 錯誤代碼或是藍屏……）、功能性錯誤（在我單擊B的時候，系統本應執行Z，卻最終執行了Y）、性能問題以及配置錯誤等等。
在精益的術語中，一個 bug 必須能夠按照下一節提到的定義進行清晰的表達，才能說它是一個問題。請相信我，我所見過的（和自己產生的）bug 中，95% 以上都不像是某種問題。性能問題或許是個常見的例外情況，但有趣的是，它們都
而在精益團隊中，一個 bug 并不代表一個問題，xXXX。我所見過的 95% 以上的 bug 表面上并不像真正的問題——性能問題或許是個常見的例外情況，但有趣的是，它們也是績效的一部分，不是嗎？
什么是問題？
讓我們在這里做一個標準的定義吧。在《豐田模式：精益模式的實踐》（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 分）。
怎樣從 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 評審（在精益中稱為紅箱分析）。
在第一次會議中，團隊為所遇到的問題建立了一個 Pareto 模型。我們創建了一張表格，將 bug 類別放在一列里，bug 的數量和 bug ID 則分別用余下的幾列來表示。
之后的目標是逐個排除每種 bug 類別背后的根本問題，首先從發生次數最頻繁的開始。為了鼓勵團隊成員就這一話題展開交流，Scrum Master 決定將這張 Pareto 表格貼在 Scrum 公告板與 bug 數量的旁邊，并且每天對其進行更新。在每天早上的站立會議上，團隊都會報告當前的 bug 情況，而新產生的 bug 都會按照其分類添加到該表格中。這種方式能夠使團隊更明顯地意識到每日質量性能的變化情況，同時也是實現 PDCA 中的C——Check（檢驗）的一種良好方式。當問題被根除之后，這方面的 bug 應該至少在一周之內不復存在了。不過，某些時候還是會發生這些 bug，而這也是需要學習的地方。
舉一個例子，該團隊已經認識到了 bug 類別中有一種屬于回歸缺陷，即對軟件的改動破壞了原本能夠正常工作的特性。這種 bug 多數情況下發生在圖形用戶界面端，因為對這一部分進行自動化測試是非常困難的事。我們所找出的一個根本問題在于，初級程序員并不總是完全理解他們對代碼的 改動可能會造成的影響。對此問題的解決措施是在流程中加入一個新的步驟，在提交代碼之前先讓某個更資深的開發者進行代碼復審。這一步驟大概只需要 15 分鐘，但能夠大幅降低回歸缺陷出現的次數。此外還將對每次發布的 bug 數量進行每日評估（每天發布兩次）。這種方式還能夠提高初級開發者的技能水平。
最終，所有的問題都得到了解決，結果是令人驚嘆的：所有的問題都通過標準流程（在提交代碼之前進行代碼復審）得以一一根除。每日的 bug 數量直線下降，每個迭代周末能夠提交的包括完整功能并且無 bug 的用戶故事數量也在上升。3 個月之后，該團隊就從之前產生 bug 數量最多的困境中搖身一變，成為了整個項目中高質量、高效率團隊的代名詞。
這種方式相比之前的方法顯得更為精益。因為它對每日績效（質量）和生產力（提交的用戶故事數量）產生了直接的影響，并且為團隊帶來了新的操作標準。
圖2：敏捷團隊的性能指標示例
將一個敏捷團隊轉變為學習團隊
經歷過了以上兩個示例之后，加上我從這次經歷中所學到的經驗，我將為你推薦一種將敏捷團隊轉變為精益和學習團隊的路線圖：
- 對績效進行評估，讓它可為眾人所見，并且每天都要對它展開討論。
我能夠理解這一點對于某些非主流的敏捷教練來說是難以忍受的，但事實可能會令你感到沮喪：如果我們需要進行改進，那么首先要做的第一件事就是評估。 此外，最重要的一點是，只有面對現實，才能進行深刻的學習。網絡巨擎（谷歌、亞馬遜、推ter 及 非死book）或者實踐領導者（Etsy）都是這樣做的：他們對每件事情都進行評估，如果他們僅僅關注于計算用戶故事的點數，就不可能達到如今的績 效。在敏捷團隊方面有個實際的例子可供參考：除了 Sprint 燃盡圖之外，還要展示質量績效（沒有關閉的 bug 數量、每次發布的 bug 數量、每種類別的 bug 數量，等等）、客戶滿意度（例如對交付的用戶故事按照總分 10 分進行評分），并且每一天都對燃盡圖沒有達到預期目標的原因進行分析。
- 確保使用精益的方式表達問題
對于某個問題的表達必須包含兩個方面：所觀察到的績效和目標績效。Pareto 是一種將原始的 bug 進行分類處理的優秀工具，但還要專門進行分析，以理解每個類別是如何影響到績效的。
- 這種方式可以保證你已經清晰地為劃分了問題的類型，并且從商業績效的角度以正確的次序分別進行處理。
- 當問題出現時逐一分析解決
精益式解決問題方法的關鍵之一，就在于不要試圖同時解決多個問題。你只需要專注于一個問題，理解它如何影響你的績效指標，并確保你理解造成該問題的原因所在。
- 進行校驗
很遺憾，根據我的經驗來看，我們通常會傾向于忽略這一步驟。如果你的預估與現實不符、你的軟件不能正常工作，那很好！你是否可以從中學到些什么？如 果你所想象中會發生的事與實際發生的事產生了偏差，那這一段偏差就是可以從中進行學習的地方。這正是在第二個示例中的團隊所做的事。正如 Stephen J. Spear 在他的著作《Chasing the Rabbit》中所寫的一樣，這是你的組織中的系統在向你發出的一種聲音：“在我身上還有一些你所不了解的東西，但如果你愿意傾聽，我就會告訴你。”團隊正是這樣才能夠從工作與流程中快速地培養自己的專業技能，并真正地成為一支夢想中的團隊。
從敏捷到精益
我從 2004 年開始成為一名敏捷實踐者，而在過去的幾年中，我的思維方式漸漸轉為精益。正是它幫助我跨越了一些單純依靠敏捷無法跨過的障礙。
按我的經驗來看，精益已經被證明是一種有效的手段，它能夠幫助你超越敏捷，建立起一種持續改進的實踐，并為團隊帶來直接的績效提高和激勵作用。而明確地區分 bug 與問題這一方式已經被證實是對持續改進的一大助力。
如果你也開始了這一相同的過程，你是否能指出 bug 與問題之間有哪些關鍵的區別因素嗎？
關于作者
Cecil Dijoux 在 Operae Partners 擔任精益 IT 教練，他是一位具有 25 年國際經驗的 IT 專家。 他對探索 21 世紀的管理方式（精益、敏捷、Enterprise 2.0 等等）充滿熱情。Cecil 在他的博客 http://thehypertextual.com/ 中寫了大量有關于互聯世界中的組織文化方面的文章，有法語和英語兩個版本。紐約時報在線和 Read Write Enterprise 曾經專門報道過他的一篇博客文章。Cecil 還是一位國際性的演講者，并且還是一份法語電子書“#hyperchange - petit guide de la conduite du changement dans l'économie de la connaissance”的作者，書中主要描寫了關于知識經濟時代的管理方式的變化。
<span id="shareA4" class="fl"> </span> </div>