《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、改規格、加需求;每做一個專案就在團隊腳上綁一塊大石,到最後整個團隊精疲力竭,只能選擇抽身離去。

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

Post Comments

技術提供:Blogger.