答客問

April 18 21:20~22:35

趁著 Teddy 還記得的時候整理一下上禮拜六 Scrum 經驗分享活動中來賓所問的問題。

人客甲：我有一個新專案是 fixed price 的專案，如果按照 Scrum 的講法，客戶可以一直改需求但是 fixed price 的專案又不能增加費用，這樣可以採用 Scrum 嗎？

Teddy：請問您以前是否有接過類似性質的專案？

人客甲：有。

Teddy：請問以前的案子都有準時結案嗎？客戶都不會更改需求嗎？

人客甲：沒有準時結案過，客戶會修改需求。

Teddy：那你還怕甚麼....XD

***

上面這個算是有點不負責任的回答，不過既然以前的方法已經多次被證明了不 work，那換個新的 Scrum 方法有什麼好怕的？當場 Teddy 沒有給這位人客太多 狡辯 回應的機會，他心裡可能在想，『雖然以前的方法不 work，但是可能只會 delay 個兩個月，萬一改用 Scrum 變成 delay 三個月甚至更久那怎麼辦？』

的確，這種情況很可能發生。好幾年前 XP 很流行的時候，Teddy 聽過一個故事，台灣某家本土做 ERP 的大公司的某個小團隊，決定採用 XP 來開發某個軟體。因為他們認為 『XP 不需要做 big up-front design，只需要透過 refactoring 來改善 design』，於是他們就真的沒有做什麼 design，導致有一陣子連續花了超過 6 個月的時間在 refactor 他們的軟體。最後這個案子已失敗告終。該公司得到一個結論，就是 XP 不 work。

人客啊，俗話說『不會駛船嫌溪彎』，自己不學好要怪東怪西這樣 Teddy 也沒辦法。Teddy 在『同誰，九陰真經不是這樣子練滴』曾經說過：

就算你是『逆練九陰真經』，好歹練功的內容還是和『九陰真經』相關連，總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』，這樣就『騙太大了』。

那有採用 XP 的團隊會連續 6 個月以上都在做 refactoring 的，這樣就是在練『瑜伽』而不是在練『九陰真經』了，別搞錯方向了。

回到原本的問題上面，如果怕自己 Scrum 不熟，那麼至少有兩個方法可以解決：

• 花錢：找顧問來協助導入，這樣最快而且比較保險。但是，千萬，千萬記住，不要找錯顧問啊，否則是會...祝恐怖..滴...。花錢又不能消災，到時候又要怪 Scrum 不好。如果不知道要找誰，請看『工商服務 』，服務範圍應該有包含海峽兩岸。
• 自己慢慢試：這個方法風險就比較高了，首先，在公司內部找到一個類似 Teddy 這樣的人來擔任 Scrum Master 幫忙導入。可以先送這個人去上課（2 天搞定），然後從『殺傷力最小』的地方開始導入 Scrum。例如，可以先改善工作環境，把辦公室隔間先拆掉，幫 developers 換大桌子，大螢幕，好電腦，並且多準備一些測試環境。接著，試著將需求改用 story 的方式來表達，如果客戶無法接受，那麼這個 story 就變成開發者自己看的資料就好，不需要告訴客戶。再下來就可以開始 sprint planning meeting, daily scrum, sprint demo meeting, and retrospective meeting。如果一開始無法立即上手，可以試著採用 iteration 0。.... 等等...再寫下去可以寫一本書了，下面就自由發揮。

總之，Teddy 的經驗是，只要找對 Scrum Master，事情應該就成功一半了。至於採用 Scrum 的效果，就要看公司文化，長官的支持程度，每個團隊成員的能力與配合度，這是需要時間來證明的。

***

人客乙是一位年輕小伙子，問了 Teddy 好幾個問題，試圖將 350 元報名費發揮到極致，不過 Teddy 只記得其中兩個問題。

人客乙：請問如果到專案快結束的時候，客戶改了一個需求影響到整個軟體架構，需要大改，那該怎麼辦？

Teddy：請問每個 sprint demo 的時候客戶都在做什麼？如果 sprint demo 客戶都有參加，『理論上』你講的這個問題發生的機率應該是很低的。這樣的問題在採用 waterfall 的專案倒是很常見。不管如何，萬一真的發生，你也只好認了啊。不過，至少你可以說『每個 sprint demo 的過程你都有參與，現在你要做這麼大的改變，是不是應該要重新談專案合約』。雖然客戶並不一定會買單，但是只要有點人性的客戶應該多多少少有點商量的餘地。

***

當人客乙問了下一個問題之後 Teddy 就知道他一定沒有看過（或是沒有專心看）搞笑談軟工，問題如下。

人客乙：Use case 裡面有所謂的 main success path 以及 extension 或是 exceptional path。通常我們會把 main success path 寫成 story，那麼 extension 與 exceptional path 要怎麼辦？

Teddy：嘿，嘿，嘿，你沒看過搞笑談軟工對不對？ 嗯嗯...總之這個問題說來話長，請參考 Teddy 部落格的『exception handling』分類文章，至少要把『敏捷式例外處理設計的第一步：決定例外處理等級』與『用 Robustness stories 評估 SyncFree 有多強壯』看完。

最後再奉送一篇免費的 paper『敏捷式例外處理』，如果這樣還不了，那就要付費請 Teddy 一對一教學了... XD

 ***

還有一位人客問到：如果團隊有 50 - 60 人那怎麼辦？Teddy 回答那要用 Scrum of Scrum... 不過很可惜，Teddy 的團隊人數遠遠遠小於這個數目（Teddy 內心獨白：我也很想有 50-60 個人可以帶啊），所以沒辦法分享任何具體的經驗。
 
ㄟ，年紀大了，只記得這四個問題，下次還有機會的話，Teddy 要記得把人客的問題記下來。

 ***

友藏內心獨白：其實 Teddy 的博速論文就是研究 exception handling 滴...