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

　　在第一次會議中，團隊為所遇到的問題建立了一個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：敏捷團隊的性能指標示例

　　將一個敏捷團隊轉變為學習團隊

　　經歷過了以上兩個示例之后，加上我從這次經歷中所學到的經驗，我將為你推薦一種將敏捷團隊轉變為精益和學習團隊的路線圖：

　　對績效進行評估，讓它可為眾人所見，并且每天都要對它展開討論。

　　我能夠理解這一點對于某些非主流的敏捷教練來說是難以忍受的，但事實可能會令你感到沮喪：如果我們需要進行改進，那么首先要做的第一件事就是評估。此外，最重要的一點是，只有面對現實，才能進行深刻的學習。網絡巨擎(谷歌、亞馬遜、Twitter及Facebook)或者實踐領導者(Etsy)都是這樣做的：他們對每件事情都進行評估，如果他們僅僅關注于計算用戶故事的點數，就不可能達到如今的績效。在敏捷團隊方面有個實際的例子可供參考：除了Sprint燃盡圖之外，還要展示質量績效(沒有關閉的bug數量、每次發布的bug數量、每種類別的bug數量，等等)、客戶滿意度(例如對交付的用戶故事按照總分10分進行評分)，并且每一天都對燃盡圖沒有達到預期目標的原因進行分析。

　　確保使用精益的方式表達問題

　　對于某個問題的表達必須包含兩個方面：所觀察到的績效和目標績效。Pareto是一種將原始的bug進行分類處理的優秀工具，但還要專門進行分析，以理解每個類別是如何影響到績效的。

　　這種方式可以保證你已經清晰地為劃分了問題的類型，并且從商業績效的角度以正確的次序分別進行處理。

　　當問題出現時逐一分析解決

　　精益式解決問題方法的關鍵之一，就在于不要試圖同時解決多個問題。你只需要專注于一個問題，理解它如何影響你的績效指標，并確保你理解造成該問題的原因所在。

　　進行校驗

　　很遺憾，根據我的經驗來看，我們通常會傾向于忽略這一步驟。如果你的預估與現實不符、你的軟件不能正常工作，那很好!你是否可以從中學到些什么?如果你所想象中會發生的事與實際發生的事產生了偏差，那這一段偏差就是可以從中進行學習的地方。這正是在第二個示例中的團隊所做的事。正如 Stephen J. Spear在他的著作《Chasing the Rabbit》中所寫的一樣，這是你的組織中的系統在向你發出的一種聲音：“在我身上還有一些你所不了解的東西，但如果你愿意傾聽，我就會告訴你。”團隊正是這樣才能夠從工作與流程中快速地培養自己的專業技能，并真正地成為一支夢想中的團隊。

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