545
技術社區[雲棲]
《Cucumber：行為驅動開發指南》——6.4 停掉生產線和缺陷預防
本節書摘來自異步社區《Cucumber：行為驅動開發指南》一書中的第6章，第6.4節，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
6.4 停掉生產線和缺陷預防
在團隊的所有活動中，哪一件是你覺得最重要的：為新特性編寫代碼？修複測試中發現的bug？修複生產環境中發現的bug？加速新特性的開發？
令人遺憾的是，在大多數軟件團隊的優先級列表中，測試的維護都不會出現在靠前的位置。如果辦公室大樓裏的升降梯壞了，可以確信立刻會有人給設備團隊的人打電話。而當測試變得緩慢或脆弱時，除了依賴於它的程序員和測試人員，其他人都不會看到問題的存在。如果你多少還做些測試維護的工作，通常也隻在事情壞到令你無法繼續忍受，或者因為測試被嚴重破壞以致產品無法直接發布的時候才做。似乎總是有更重要的事情等著你做。
對測試采取這種思路的團隊成員是完全錯誤的。對依賴於自動測試的團隊來說，自動化測試就是團隊的心跳，團隊需要用一絲不苟的小心和關注來維持它的健康。
豐田的“停掉生產線”
在豐田的製造廠裏，每次出現問題時，車間的每位工人都有權力和職責停掉整條生產線。問題馬上會得到經驗豐富的員工給予的全力關注，且隻有等問題得到解決生產線才會重新啟動。生產線重新啟動之後，會有一個小組負責對問題實施根源分析（root-cause analysis），弄清發生的原因，從而從根源上解決問題。
大野耐1先生第一次提出這一想法時，生產經理們認為他瘋了。那時，人們覺得在製造行業最重要的事情當然是讓裝配線保持運行，必要時每日每夜都不間斷。
大野耐先生第一次向經理們提出實現這種新的係統時，有的人聽從了，有的人根本不聽。一開始，實施了這一策略的經理們發現他們的生產率下降了。每次遇到問題都馬上停下來處理降低了它們的產量，而且當他們將產出數字同那些無視老板想法的經理們進行比較時，看上去似乎是老板錯了。
然而，慢慢地那些允許生產線停下來處理每個問題的經理們開始發現他們的生產線上停工的情況越來越少了。因為每個問題都以缺陷預防的策略得到處理，這些生產線開始不斷為改善機器的質量和運營的過程提供投入。很快，這些生產線的產量便大大超過了那些對貌似發瘋的老板陽奉陰違的經理們所控製的生產線。那些經理們的生產線仍然沿著舊時的頻率定期地哐啷罷工，被同樣的老問題反複地折磨著。
缺陷預防
豐田反直覺卻又取得巨大成功的“停掉生產線”策略之所以有效，是因為它是一種更全麵的策略——缺陷預防——的一部分，缺陷預防關注於持續改善生產係統。若沒有這種更全麵的過程，“停掉生產線”的效果將微乎其微。缺陷預防過程分為以下4步。
（1）檢測異常情況。
（2）停下手邊的工作。
（3）修複或糾正眼下的問題。
（4）調查根源並實施對策。
這4個步驟非常重要，因為它能抓住手邊的問題所提供的機會，從而理解過程中一些更為根本的東西。它也意味著讓修正問題成為一種習慣，而不是可以推到日後不忙時的一件事情。
舉個例子，假設構建被一個失敗的測試破壞了。調查原因，發現有個家夥在提交代碼之前沒有運行所有測試，就是他提交了導致測試失敗的代碼。他為什麼不運行所有測試呢？好吧，是因為他覺得運行測試需要太長的時間，他隻運行了自認為覆蓋他的改動的那部分測試，然後雙手合十禱告一下便直接提交了代碼。所以，底層的原因的是特性運行得太慢。理解了問題的根源之後，我們就可以著手修複它了。
有些團隊維護一份構建失敗的日誌，其中記錄著每次失敗的根源。當有足夠的證據證明某個特定的根源有必要處理時，他們便會集中精力來妥善處理它。
把你的團隊想象成一條生產線，它為用戶生產有價值的特性。如果你發現有個問題在降低它的產出速度，那就停掉生產線，把問題永久修複。實現“停掉生產線”這一策略意味著你決定把獲得一套快速、高質量且可靠的測試列為整個團隊的頭等大事，僅次於處理影響客戶的生產問題。當測試出現問題——不論是測試失敗這種緊迫的問題，還是閃爍的場景這種無休止的煩惱——都要把最佳的人選推上去，永久地修複它。
最後更新：2017-06-05 13:31:28