延續上一篇,這裡寫一點第 2 章<流程改善,沒有魔法>的筆記。
精實(Lean)製程定義了七種會破壞客戶價值流的浪費:
作者認為,花太多時間專注在開發底層架構和元件等「基礎設施」上,可能會讓客戶久候,苦等不到他們想要的東西。為了經常獲得客戶的回饋意見,快速反覆(iteration)有個基本前提:開發應該「深度優先,而非廣度優先(depth first, not breadth first)。
廣度優先意味著包羅萬象,要求納入所有能想到的功能,並對每一項功能進行設計,設計階段完成後再全部一起實作,然後一起測試。深度優先則著重於把單一功能做好,完成了某項功能的設計、實作、測試之後,才繼續處理下一個功能。兩種極端都不好,但是對大部分的開發團隊來說,最好是先做一次高階的廣度設計,之後就立刻改以深度優先的方式進行底層的設計與實作。
的確,我覺得偏好深度優先的另一層意義是對品質的堅持,而不是以量取勝、上(線)了再說的心態。因為開發人力和時間都很寶貴,如果想要全都顧到,很可能結果就是每項功能的品質都差了點。一次交付預定的那些功能,專案進度表自然是交代得過去,可是當客戶開始使用時,可能會發現怎麼跟當初期望的不太一樣:好像每一項功能都做了,但又沒幾個讓人覺得滿意的。開發團隊並沒有真正實現當初對品質的承諾。
如果專案經理光是盯著進度表,只求達到表面上的實現承諾,卻從不認真思考軟體品質與維護成本的問題,我覺得是相當短視、而且不負責任的作法。這種領導風格可能一開始會讓客戶和老闆很高興,但是胡亂承諾、扮好人的結果,往往會讓後面維護的人疲於奔命:接客戶的抱怨電話、除 bug、改規格、加需求;每做一個專案就在團隊腳上綁一塊大石,到最後整個團隊精疲力竭,只能選擇抽身離去。
喔,又忍不住寫太多感想了,就此打住。
精實(Lean)製程定義了七種會破壞客戶價值流的浪費:
- 過度生產(overproduction):開發太多不重要、甚至無用的功能。
- 傳遞成本(transportation):專案建置(build)、版本分支(branch)、和團隊成員之間透過 e-mail 溝通等傳遞成本。
- 多餘動作(motion):花在找資料、找解法、搞清楚要做甚麼等動作的時間太多。
- 等待時間(waiting):系統功能的優先順序沒訂好、開發流程不當、品質不良等因素,導致各開發小組之間彼此等待。
- 過度處理(overprocessing):把軟體功能設計得太複雜、對已經跑夠快的程式不斷做效能最佳化的調整、增加不必要的擴充等等。
- 庫存過剩(inventory):矇著頭開發了一堆功能,後來發現有很多都白做了,在系統上線前就被拿掉,所以客戶也看不到這些功能--未實現的價值是種浪費。
- 產品瑕疵(defects):太多 bugs 將令客戶失去信心,也會造成重工(rework)。
作者認為,花太多時間專注在開發底層架構和元件等「基礎設施」上,可能會讓客戶久候,苦等不到他們想要的東西。為了經常獲得客戶的回饋意見,快速反覆(iteration)有個基本前提:開發應該「深度優先,而非廣度優先(depth first, not breadth first)。
廣度優先意味著包羅萬象,要求納入所有能想到的功能,並對每一項功能進行設計,設計階段完成後再全部一起實作,然後一起測試。深度優先則著重於把單一功能做好,完成了某項功能的設計、實作、測試之後,才繼續處理下一個功能。兩種極端都不好,但是對大部分的開發團隊來說,最好是先做一次高階的廣度設計,之後就立刻改以深度優先的方式進行底層的設計與實作。
的確,我覺得偏好深度優先的另一層意義是對品質的堅持,而不是以量取勝、上(線)了再說的心態。因為開發人力和時間都很寶貴,如果想要全都顧到,很可能結果就是每項功能的品質都差了點。一次交付預定的那些功能,專案進度表自然是交代得過去,可是當客戶開始使用時,可能會發現怎麼跟當初期望的不太一樣:好像每一項功能都做了,但又沒幾個讓人覺得滿意的。開發團隊並沒有真正實現當初對品質的承諾。
如果專案經理光是盯著進度表,只求達到表面上的實現承諾,卻從不認真思考軟體品質與維護成本的問題,我覺得是相當短視、而且不負責任的作法。這種領導風格可能一開始會讓客戶和老闆很高興,但是胡亂承諾、扮好人的結果,往往會讓後面維護的人疲於奔命:接客戶的抱怨電話、除 bug、改規格、加需求;每做一個專案就在團隊腳上綁一塊大石,到最後整個團隊精疲力竭,只能選擇抽身離去。
喔,又忍不住寫太多感想了,就此打住。
感謝晝龍點睛的導讀,但什麼是高階的廣度設計呢?能否舉例,謝謝
回覆刪除比如說,一個系統裡面,預計包含八大子系統,各子系統裡面又還有許多模組和程式。在初步分析出整個系統的範圍後,一般會思考系統的架構、各子系統的初步分析、各子系統之間需要介接的部分等。接下來就針對優先權較高的子系統進一步分析、設計。而不是所有的子系統都完成鉅細靡遺的分析(其實不可能)之後,才全部進入設計階段。
回覆刪除先完成整體系統的架構分析、設計,以及優先權最高的子系統/功能,可及早發現系統架構設計的瑕疵。如果所有子系統幾乎以同步的節奏進行開發,恐怕到最後會經常聽到:「來不及了,幾百隻程式都已經這樣寫,不可能改了」這類令人洩氣又無奈的理由。