停掉生產線

3/26 21:39~23:05

『品質是內建，不是外加的』這句話應該算是常識了，現在大部分的人讀起來已經覺的沒什麼特別。但是在 19 年前，當 Teddy 還是個青澀少年時，在『由 C 到 C++: 物件導向革命』這本書中第一次看到這個觀念，卻是覺得很新奇：

哇，原來產品的品質在做好之後便已經決定了，更多的測試並不會增加產品的品質，所以要提昇產品的品質便需要提昇產品製作流程與流程中的每個活動的品質。

聽起來很有道理，但是，哪有可能！程式寫好不交給別人測試，能有這樣的勇氣直接拿給客戶用嗎？『暈倒死』的『藍色死亡畫面』看多了，電腦上面 reset 按鈕也按到手軟，再聽到『如何寫出零錯誤的程式』這類的話，心裡都會偷笑。久而久之，軟體有 bugs 算是正常，用到沒有 bugs 的軟體才是要懷疑是不是看到鬼。長此以往，programmers 對於 bugs 見怪不怪，因此對於如何提高軟體品質這檔子事的警覺性，也越來越低了。在業界中屢見不鮮的例子：

PM：這個功能做好了嗎？
Programmer：做好了，沒有問題。
PM：我剛剛測了一下，有很多 bugs...
Programmer：你咬我啊...

夜深人靜時，相信 programmers 的內心偶而也浮出小小的吶喊『我到底是在開發功能還是在開發 bugs？』。

軟體工程的主要目的之一，就是要探討如何做出高品質的軟體。達到這個目的有很多不同的手段，Teddy 在念研究所時，曾經修過 PSP (Personal Software Process) 這門課，PSP 希望 programmers 可以藉由多種不同層次的 review (design, code, etc)、紀錄一狗票的資料 (以分鐘為單位的 time log, 新增幾行程式碼, 修改幾行程式碼, 開發過程中所有發生的 bugs...) 、以及定期提出改善方案等手段來提昇品質。立意良好，但光是聽起來就覺的有點『違反人性』，窒礙難行。光是修課過程中寫 10 支小程式就快被搞死了，玩玩 Sony PSP (PlayStation Portable) 還差不多，怎麼可能用 PSP 來開發軟體...。

由於程式是人寫出來的 (程式產生器也是人寫的)，所以各種軟體品質改善方法或是開發流程，無不強調如何減少人為錯誤。因為很多 programmers (至少在台灣是這樣吧) 已經養成『差不多先生』的心態，因此 Teddy 認為無論採用何種方法，首要之務便是以『符合人性的方式』提昇 programmers 的 羞恥心 警覺心，讓他們慢慢覺沒有 bugs （或是很低的 bug rate）是常態，而非不可能。要怎麼做？

Teddy 最近在讀 Lean 和 Toyota Production System (TPS) 的書，其中有一個作法叫做 Stop the Line--停掉生產線，Teddy 覺的滿有趣的，也很想來試試。Stop the Line 大意就是說：如果一發現不良品，就馬上停止整條生產線，一直到找到問題的根源 (root cause) 為止。乍看之下覺的日本人怎麼這麼笨，整條生產線停工，那成本有多高？但是仔細一想，如果不徹底找出產生不良品的原因，這些生產出來的不良品都是浪費。更糟的是，如果不良品流入市面，商譽的損失與後續維護成本更是高的嚇人。

也許敏捷團隊都應該安裝一個類似救護車或是消防車上面的『警示燈』，當一發現 bug 的時候就按下這個燈，啟動之後還會發出『偶一、偶一』的聲音。此時大家都放下手邊的工作，一起來徹底找出造成 bug 的根本原因，並討論如何避免下次再發生同樣的 bug。這樣做的好處至少有以下兩點：

• 提高警覺：由於一發現 bug 需要暫停所有人的工作，所以大家都不會希望這個 bug 是自己造成的。因此在施工的時候，便會想辦法提昇軟體的品質。例如，主動找人幫你做 code review 、執行 pair programming、多做 unit testing、實施 test-driven development (TDD) 等等。甚至如果有人覺的 PSP 有幫助，也可以採用  PSP。總之，改善方法不限，由團隊自行決定。
• 提高共識：所有人一起找出原因並且討論改善方案，因此對於如何發生錯誤以及如何避免再次發生都會有比較高的共識。

但是，如果你的團隊沒有專屬的辦公室而且工作環境中還有其他團隊成員，如果真的裝了一個警示燈，以一般軟體開發團隊發生  bugs 的頻率，可能會把其他人吵死吧...

友藏內心獨白：或許可以考慮每個人發一個像是在『伯朗咖啡』點餐時所拿到的『振動器』來取代警示燈。