《I. M. Wright's "Hard Code"》第二章閱讀札記

延續上一篇，這裡寫一點第 2 章＜流程改善，沒有魔法＞的筆記。

精實（Lean）製程定義了七種會破壞客戶價值流的浪費：

• 過度生產（overproduction）：開發太多不重要、甚至無用的功能。
• 傳遞成本（transportation）：專案建置（build）、版本分支（branch）、和團隊成員之間透過 e-mail 溝通等傳遞成本。
• 多餘動作（motion）：花在找資料、找解法、搞清楚要做甚麼等動作的時間太多。
• 等待時間（waiting）：系統功能的優先順序沒訂好、開發流程不當、品質不良等因素，導致各開發小組之間彼此等待。
• 過度處理（overprocessing）：把軟體功能設計得太複雜、對已經跑夠快的程式不斷做效能最佳化的調整、增加不必要的擴充等等。
• 庫存過剩（inventory）：矇著頭開發了一堆功能，後來發現有很多都白做了，在系統上線前就被拿掉，所以客戶也看不到這些功能－－未實現的價值是種浪費。
• 產品瑕疵（defects）：太多 bugs 將令客戶失去信心，也會造成重工（rework）。
  

深度 vs. 廣度

作者認為，花太多時間專注在開發底層架構和元件等「基礎設施」上，可能會讓客戶久候，苦等不到他們想要的東西。為了經常獲得客戶的回饋意見，快速反覆（iteration）有個基本前提：開發應該「深度優先，而非廣度優先（depth first, not breadth first）。

廣度優先意味著包羅萬象，要求納入所有能想到的功能，並對每一項功能進行設計，設計階段完成後再全部一起實作，然後一起測試。深度優先則著重於把單一功能做好，完成了某項功能的設計、實作、測試之後，才繼續處理下一個功能。兩種極端都不好，但是對大部分的開發團隊來說，最好是先做一次高階的廣度設計，之後就立刻改以深度優先的方式進行底層的設計與實作。

的確，我覺得偏好深度優先的另一層意義是對品質的堅持，而不是以量取勝、上（線）了再說的心態。因為開發人力和時間都很寶貴，如果想要全都顧到，很可能結果就是每項功能的品質都差了點。一次交付預定的那些功能，專案進度表自然是交代得過去，可是當客戶開始使用時，可能會發現怎麼跟當初期望的不太一樣：好像每一項功能都做了，但又沒幾個讓人覺得滿意的。開發團隊並沒有真正實現當初對品質的承諾。

如果專案經理光是盯著進度表，只求達到表面上的實現承諾，卻從不認真思考軟體品質與維護成本的問題，我覺得是相當短視、而且不負責任的作法。這種領導風格可能一開始會讓客戶和老闆很高興，但是胡亂承諾、扮好人的結果，往往會讓後面維護的人疲於奔命：接客戶的抱怨電話、除 bug、改規格、加需求；每做一個專案就在團隊腳上綁一塊大石，到最後整個團隊精疲力竭，只能選擇抽身離去。

喔，又忍不住寫太多感想了，就此打住。