示例1：敏捷開發(fā)中的情景
當(dāng)時(shí)我在這個(gè)使用敏捷開發(fā)的團(tuán)隊(duì)中擔(dān)任經(jīng)理一職。和許多團(tuán)隊(duì)一樣，我們團(tuán)隊(duì)也不是一個(gè)跨職能的團(tuán)隊(duì)（典型的Scrum-but），而是一個(gè)負(fù)責(zé)后臺(tái)的團(tuán)隊(duì)。它在某個(gè)迭代內(nèi)負(fù)責(zé)構(gòu)建基礎(chǔ)服務(wù)端軟件，以便讓應(yīng)用團(tuán)隊(duì)在之后的迭代中使用這部分功能。
我們按照Paretos原則（即80-20原則）對(duì)產(chǎn)生的bug進(jìn)行了一些分析，并且找出了一個(gè)占總數(shù)約20%的bug類別：這些bug都是由應(yīng)用團(tuán)隊(duì)所提出的，與我們團(tuán)隊(duì)所建立的后臺(tái)軟件所暴露的API對(duì)“隱式”這一概念的定義有關(guān)。當(dāng)應(yīng)用團(tuán)隊(duì)在使用我們提供的功能時(shí)，經(jīng)常會(huì)發(fā)生遺漏了某些輸入?yún)?shù)，或者是缺少了某些輸出數(shù)據(jù)等問(wèn)題……因此他們就會(huì)為我們創(chuàng)建一些bug，而我們的團(tuán)隊(duì)則會(huì)說(shuō)：嘿！這個(gè)API已經(jīng)隱式地表明了它不會(huì)返回這些數(shù)據(jù)。
我們同時(shí)注意到了這些bug的持續(xù)時(shí)間，通常從創(chuàng)建直到關(guān)閉為止一共持續(xù)了大約4個(gè)星期。（在最好的情況下）在以一個(gè)月為周期的迭代的最后階段會(huì)進(jìn)行代碼發(fā)布，客戶端團(tuán)隊(duì)則可以在下一個(gè)迭代時(shí)使用這些代碼。因此當(dāng)客戶端團(tuán)隊(duì)創(chuàng)建了bug，并指派給原來(lái)的開發(fā)者時(shí)，往往距離她開發(fā)那些代碼時(shí)已經(jīng)過(guò)去了兩三個(gè)星期，開發(fā)者不得不再度拾起這段代碼……
為了處理這種情況，我們決定改變一下工作的方式，將相關(guān)人員組織在一起，而產(chǎn)生一個(gè)相關(guān)聯(lián)、跨職能并且跨技能的團(tuán)隊(duì)。
采用了新的方式之后，我們注意到這些“隱式API”相關(guān)的bug數(shù)量大幅下降了（約50%）。最令人欣慰的是，這種類型的bug的持續(xù)時(shí)間下降到了幾個(gè)工作日以內(nèi)。當(dāng)然，這個(gè)數(shù)字有一定的水分，有些bug雖然被發(fā)現(xiàn)了，但是并沒(méi)有記錄下來(lái)，因?yàn)殚_發(fā)者們現(xiàn)在進(jìn)行結(jié)對(duì)編程，于是許多bug直接在座位上就解決了。
雖然成果是顯著的，但我總感覺(jué)到還有些不適之處，卻說(shuō)不出究竟是哪里出了問(wèn)題。之后不久我才發(fā)覺(jué)，從精益的角度來(lái)說(shuō)，我們目前還有兩個(gè)不足之處：
首先，我們的系統(tǒng)中依然存在bug，因此我們不得不重復(fù)勞動(dòng)，這使得整個(gè)開發(fā)系統(tǒng)出現(xiàn)了生產(chǎn)力的浪費(fèi)。但是由于缺乏內(nèi)建的質(zhì)量標(biāo)準(zhǔn)，我們無(wú)法保證服務(wù)端開發(fā)者所開發(fā)的API不存在問(wèn)題。此外，對(duì)于錯(cuò)誤的處理也沒(méi)有真正的標(biāo)準(zhǔn)，我們的解決手段就是：遇到問(wèn)題就坐下來(lái)一起解決。
盡管結(jié)果非常顯著且令人振奮，但它與團(tuán)隊(duì)的每日績(jī)效沒(méi)并有什么直接的關(guān)聯(lián)，團(tuán)隊(duì)也無(wú)法立即采取行動(dòng)并在第二天直接看到結(jié)果。我們只是從宏觀上在6個(gè)月結(jié)束后的發(fā)布中才能夠看到這一效果：即在bug總數(shù)中與API相關(guān)的bug只占少數(shù)。因此我們看到：建立一個(gè)跨技能的團(tuán)隊(duì)確實(shí)能夠在某種程度上改進(jìn)質(zhì)量，但我們還未能提供一種有效的方法，讓我們能夠每天監(jiān)控它的情況，并采取相應(yīng)的行動(dòng)。
示例2：精益開發(fā)中的情景
時(shí)間轉(zhuǎn)眼間過(guò)去了幾年，我還是任職于同一家公司中，但目前的職位是項(xiàng)目主管及教練，負(fù)責(zé)一個(gè)大型的多團(tuán)隊(duì)、多種技術(shù)的敏捷項(xiàng)目的實(shí)施。某一個(gè)團(tuán)隊(duì)遇到了一個(gè)很有挑戰(zhàn)的技術(shù)難題，他們要與某個(gè)大家都沒(méi)有什么經(jīng)驗(yàn)的技術(shù)進(jìn)行整合。整個(gè)團(tuán)隊(duì)在過(guò)去的兩個(gè)Sprint中沒(méi)有交付任何用戶故事，他們深陷于質(zhì)量問(wèn)題（例如bug）中難以自撥。當(dāng)?shù)诙€(gè)Sprint結(jié)束后，依然沒(méi)有任何完成的用戶故事（比方說(shuō)，按照我們對(duì)完成的定義來(lái)看，該用戶故事在功能性需求上需要做到?jīng)]有任何bug）可以交付。因此在回顧會(huì)議中，整個(gè)團(tuán)隊(duì)一致決定，將每周進(jìn)行bug評(píng)審（在精益中稱為紅箱分析）。
在第一次會(huì)議中，團(tuán)隊(duì)為所遇到的問(wèn)題建立了一個(gè)Pareto模型。我們創(chuàng)建了一張表格，將bug類別放在一列里，bug的數(shù)量和bug ID則分別用余下的幾列來(lái)表示。
之后的目標(biāo)是逐個(gè)排除每種bug類別背后的根本問(wèn)題，首先從發(fā)生次數(shù)最頻繁的開始。為了鼓勵(lì)團(tuán)隊(duì)成員就這一話題展開交流，Scrum Master決定將這張Pareto表格貼在Scrum公告板與bug數(shù)量的旁邊，并且每天對(duì)其進(jìn)行更新。在每天早上的站立會(huì)議上，團(tuán)隊(duì)都會(huì)報(bào)告當(dāng)前的bug情況，而新產(chǎn)生的bug都會(huì)按照其分類添加到該表格中。這種方式能夠使團(tuán)隊(duì)更明顯地意識(shí)到每日質(zhì)量性能的變化情況，同時(shí)也是實(shí)現(xiàn)PDCA中的C——Check（檢驗(yàn)）的一種良好方式。當(dāng)問(wèn)題被根除之后，這方面的bug應(yīng)該至少在一周之內(nèi)不復(fù)存在了。不過(guò)，某些時(shí)候還是會(huì)發(fā)生這些bug，而這也是需要學(xué)習(xí)的地方。
舉一個(gè)例子，該團(tuán)隊(duì)已經(jīng)認(rèn)識(shí)到了bug類別中有一種屬于回歸缺陷，即對(duì)軟件的改動(dòng)破壞了原本能夠正常工作的特性。這種bug多數(shù)情況下發(fā)生在圖形用戶界面端，因?yàn)閷?duì)這一部分進(jìn)行自動(dòng)化測(cè)試是非常困難的事。我們所找出的一個(gè)根本問(wèn)題在于，初級(jí)程序員并不總是完全理解他們對(duì)代碼的改動(dòng)可能會(huì)造成的影響。對(duì)此問(wèn)題的解決措施是在流程中加入一個(gè)新的步驟，在提交代碼之前先讓某個(gè)更資深的開發(fā)者進(jìn)行代碼復(fù)審。這一步驟大概只需要15分鐘，但能夠大幅降低回歸缺陷出現(xiàn)的次數(shù)。此外還將對(duì)每次發(fā)布的bug數(shù)量進(jìn)行每日評(píng)估（每天發(fā)布兩次）。這種方式還能夠提高初級(jí)開發(fā)者的技能水平。
最終，所有的問(wèn)題都得到了解決，結(jié)果是令人驚嘆的：所有的問(wèn)題都通過(guò)標(biāo)準(zhǔn)流程（在提交代碼之前進(jìn)行代碼復(fù)審）得以一一根除。每日的bug數(shù)量直線下降，每個(gè)迭代周末能夠提交的包括完整功能并且無(wú)bug的用戶故事數(shù)量也在上升。3個(gè)月之后，該團(tuán)隊(duì)就從之前產(chǎn)生bug數(shù)量最多的困境中搖身一變，成為了整個(gè)項(xiàng)目中高質(zhì)量、高效率團(tuán)隊(duì)的代名詞。
這種方式相比之前的方法顯得更為精益。因?yàn)樗鼘?duì)每日績(jī)效（質(zhì)量）和生產(chǎn)力（提交的用戶故事數(shù)量）產(chǎn)生了直接的影響，并且為團(tuán)隊(duì)帶來(lái)了新的操作標(biāo)準(zhǔn)。
圖2：敏捷團(tuán)隊(duì)的性能指標(biāo)示例
將一個(gè)敏捷團(tuán)隊(duì)轉(zhuǎn)變?yōu)閷W(xué)習(xí)團(tuán)隊(duì)
經(jīng)歷過(guò)了以上兩個(gè)示例之后，加上我從這次經(jīng)歷中所學(xué)到的經(jīng)驗(yàn)，我將為你推薦一種將敏捷團(tuán)隊(duì)轉(zhuǎn)變?yōu)榫婧蛯W(xué)習(xí)團(tuán)隊(duì)的路線圖：
對(duì)績(jī)效進(jìn)行評(píng)估，讓它可為眾人所見(jiàn)，并且每天都要對(duì)它展開討論。
我能夠理解這一點(diǎn)對(duì)于某些非主流的敏捷教練來(lái)說(shuō)是難以忍受的，但事實(shí)可能會(huì)令你感到沮喪：如果我們需要進(jìn)行改進(jìn)，那么首先要做的第一件事就是評(píng)估。此外，最重要的一點(diǎn)是，只有面對(duì)現(xiàn)實(shí)，才能進(jìn)行深刻的學(xué)習(xí)。網(wǎng)絡(luò)巨擎（谷歌、亞馬遜、Twitter及Facebook）或者實(shí)踐領(lǐng)導(dǎo)者（Etsy）都是這樣做的：他們對(duì)每件事情都進(jìn)行評(píng)估，如果他們僅僅關(guān)注于計(jì)算用戶故事的點(diǎn)數(shù)，就不可能達(dá)到如今的績(jī)效。在敏捷團(tuán)隊(duì)方面有個(gè)實(shí)際的例子可供參考：除了Sprint燃盡圖之外，還要展示質(zhì)量績(jī)效（沒(méi)有關(guān)閉的bug數(shù)量、每次發(fā)布的bug數(shù)量、每種類別的bug數(shù)量，等等）、客戶滿意度（例如對(duì)交付的用戶故事按照總分10分進(jìn)行評(píng)分），并且每一天都對(duì)燃盡圖沒(méi)有達(dá)到預(yù)期目標(biāo)的原因進(jìn)行分析。
確保使用精益的方式表達(dá)問(wèn)題
對(duì)于某個(gè)問(wèn)題的表達(dá)必須包含兩個(gè)方面：所觀察到的績(jī)效和目標(biāo)績(jī)效。Pareto是一種將原始的bug進(jìn)行分類處理的優(yōu)秀工具，但還要專門進(jìn)行分析，以理解每個(gè)類別是如何影響到績(jī)效的。
這種方式可以保證你已經(jīng)清晰地為劃分了問(wèn)題的類型，并且從商業(yè)績(jī)效的角度以正確的次序分別進(jìn)行處理。
當(dāng)問(wèn)題出現(xiàn)時(shí)逐一分析解決
精益式解決問(wèn)題方法的關(guān)鍵之一，就在于不要試圖同時(shí)解決多個(gè)問(wèn)題。你只需要專注于一個(gè)問(wèn)題，理解它如何影響你的績(jī)效指標(biāo)，并確保你理解造成該問(wèn)題的原因所在。
進(jìn)行校驗(yàn)
很遺憾，根據(jù)我的經(jīng)驗(yàn)來(lái)看，我們通常會(huì)傾向于忽略這一步驟。如果你的預(yù)估與現(xiàn)實(shí)不符、你的軟件不能正常工作，那很好！你是否可以從中學(xué)到些什么？如果你所想象中會(huì)發(fā)生的事與實(shí)際發(fā)生的事產(chǎn)生了偏差，那這一段偏差就是可以從中進(jìn)行學(xué)習(xí)的地方。這正是在第二個(gè)示例中的團(tuán)隊(duì)所做的事。正如Stephen J. Spear在他的著作《Chasing the Rabbit》中所寫的一樣，這是你的組織中的系統(tǒng)在向你發(fā)出的一種聲音：“在我身上還有一些你所不了解的東西，但如果你愿意傾聽，我就會(huì)告訴你。”團(tuán)隊(duì)正是這樣才能夠從工作與流程中快速地培養(yǎng)自己的專業(yè)技能，并真正地成為一支夢(mèng)想中的團(tuán)隊(duì)。
從敏捷到精益
我從2004年開始成為一名敏捷實(shí)踐者，而在過(guò)去的幾年中，我的思維方式漸漸轉(zhuǎn)為精益。正是它幫助我跨越了一些單純依靠敏捷無(wú)法跨過(guò)的障礙。
按我的經(jīng)驗(yàn)來(lái)看，精益已經(jīng)被證明是一種有效的手段，它能夠幫助你超越敏捷，建立起一種持續(xù)改進(jìn)的實(shí)踐，并為團(tuán)隊(duì)帶來(lái)直接的績(jī)效提高和激勵(lì)作用。而明確地區(qū)分bug與問(wèn)題這一方式已經(jīng)被證實(shí)是對(duì)持續(xù)改進(jìn)的一大助力。
如果你也開始了這一相同的過(guò)程，你是否能指出bug與問(wèn)題之間有哪些關(guān)鍵的區(qū)別因素嗎？