曾有陣子我很憧憬 SCRUM 的開發流程，但是現實和理論總是有相當的差距，在台灣 IT 不同於國外這樣嚴苛的工作環境中，究竟怎麼在理想的開發方式和實務中取得協調？
該格主剛好將自己部落格文章分類編輯後，針對這塊彙整成他個人過往的“經驗談”。
本書沒有什麼解答，但是以他自身經驗，可以給讀者一種：你遇過的困擾，也是大家共同的困擾 -- 這樣一種安慰劑。由於版主的個人風格強烈，又是以『搞笑談⋯⋯』為前提，整本書其實偏“消遣休閒娛樂”居多，能當作工具的參考價值相對較低，整本書讀下來常常讓我想起“獨孤木的『軟體超人 X 光眼』”和“洪志鵬的『背著老闆的深夜 MSN 對談』”這兩本書。
對於以 SCRUM 為主題的部分，我覺得有些章節還不錯，對於釐清、撥亂反正某些觀念或實務操作很有幫助，特別是關於估算 story 和 story point 這部分。需求，是一切專案的根源，定義需求已經是影響專案走向成功或失敗的關鍵一步。
如何寫出“有意義”的 story？作者給了些發人省思的原則：角色、目的、方法。
而當需求清楚時，老闆通常會馬上接著問一個所有開發領隊（或專案經理）都很頭大的問題：ETA（Estimated Time of Arrival）！就是要你預估什麼時候可以做完交出來啦！
預估時程，永遠都是開發經理最難掌控和回答的問題：團隊成員變異太大、同一個工作交給不同人執行可以有天差地遠的效率。沒做過的需求、不可預期的技術意外、舉凡種種都是估計的困擾。
Story Point 就是為了透過長期累積的估計資料來慢慢分辨團隊的開發效率，但是怎麼樣去評估才能縮減“評估”與“實際”的落差呢？這也關乎採用的計算基準。不同的開發文化會有不同的做法去適應，這部分算是本書讓我獲益較多的章節。
本書也顯示我們和作者都遇到的困難，跟工作文化（就是“人”的素質啦）有關，作者帶著團隊明明就體會到 Pair Programming 的好處，但是只要一鬆手，又會回歸渾沌、打回原形。就像我帶團隊明明就規範了“某些事”一定要怎麼做、怎麼做，一沒盯就會用他個人的習慣取代。
而且，軟體工程師不像是硬體生產線上的操作員，可以透過管理來提升良率、績效與品質。比較像是帶著一群畫家作畫，沒辦法單純透過『管理』就讓不擅長畫畫的人變成可以畫出名畫，所以採用 Pair Programming 類似『師徒制』，應該是比較合乎這個產業特性的方法。
再寫下去我就要開始跟作者一樣抱怨了，就點到為止吧。
沒有留言:
張貼留言