『敏捷開發法的逆襲』讀後感

        『搞笑談軟工』是去年我在搜尋一些單元測試的相關文章,偶然間發現的部落格。該格主對於軟體開發領域的知識耕耘相當深厚,令人佩服。另外在軟體工程的敏捷開發有相當的實務經驗,也專門開班授課、擔任顧問協助導入敏捷開發流程。

        曾有陣子我很憧憬 SCRUM 的開發流程,但是現實和理論總是有相當的差距,在台灣 IT 不同於國外這樣嚴苛的工作環境中,究竟怎麼在理想的開發方式和實務中取得協調?

        該格主剛好將自己部落格文章分類編輯後,針對這塊彙整成他個人過往的“經驗談”



        本書沒有什麼解答,但是以他自身經驗,可以給讀者一種:你遇過的困擾,也是大家共同的困擾 -- 這樣一種安慰劑。由於版主的個人風格強烈,又是以『搞笑談⋯⋯』為前提,整本書其實偏“消遣休閒娛樂”居多,能當作工具的參考價值相對較低,整本書讀下來常常讓我想起“獨孤木的『軟體超人 X 光眼』”和“洪志鵬的『背著老闆的深夜 MSN 對談』”這兩本書。

        對於以 SCRUM 為主題的部分,我覺得有些章節還不錯,對於釐清、撥亂反正某些觀念或實務操作很有幫助,特別是關於估算 story 和 story point 這部分。需求,是一切專案的根源,定義需求已經是影響專案走向成功或失敗的關鍵一步。

        如何寫出“有意義”的 story?作者給了些發人省思的原則:角色、目的、方法

        而當需求清楚時,老闆通常會馬上接著問一個所有開發領隊(或專案經理)都很頭大的問題:ETA(Estimated Time of Arrival)就是要你預估什麼時候可以做完交出來啦!

        預估時程,永遠都是開發經理最難掌控和回答的問題:團隊成員變異太大、同一個工作交給不同人執行可以有天差地遠的效率。沒做過的需求、不可預期的技術意外、舉凡種種都是估計的困擾。

        Story Point 就是為了透過長期累積的估計資料來慢慢分辨團隊的開發效率,但是怎麼樣去評估才能縮減“評估”與“實際”的落差呢?這也關乎採用的計算基準。不同的開發文化會有不同的做法去適應,這部分算是本書讓我獲益較多的章節。

        本書也顯示我們和作者都遇到的困難,跟工作文化(就是“人”的素質啦)有關,作者帶著團隊明明就體會到 Pair Programming 的好處,但是只要一鬆手,又會回歸渾沌、打回原形。就像我帶團隊明明就規範了“某些事”一定要怎麼做、怎麼做,一沒盯就會用他個人的習慣取代。

        而且,軟體工程師不像是硬體生產線上的操作員,可以透過管理來提升良率、績效與品質。比較像是帶著一群畫家作畫,沒辦法單純透過『管理』就讓不擅長畫畫的人變成可以畫出名畫,所以採用 Pair Programming 類似『師徒制』,應該是比較合乎這個產業特性的方法

        再寫下去我就要開始跟作者一樣抱怨了,就點到為止吧。

熱門文章