Scrum 三年兩個月

July 14 21:07~22:15

算一算從開始帶第一個 Scrum team 到現在也已經過了三年兩個月了，在那之前，Teddy 雖然讀了一堆 agile methods 的書和 papers，對裡面的作法也十分認同，但是並沒有機會真正帶領一個 agile team。經過這三年兩個月，Teddy 有幾點感想。

首先，這幾年 Scrum 在台灣算是有一點小流行，而且由於 Scrum 框架本身很簡單，因此採用的門檻不算高。但是，如果光是學到 Scrum 的皮，而忽略 agile methods 的精神，那麼對於團隊而言可以獲益的地方就相對的比較有限。Teddy 聽某個採用 Scrum 的朋友說起他們實施 Scrum 的方式，一個 sprint 長達 6 周，而團隊實做 story 的方式，基本上還是由所謂的『架構師』設計系統架構，『分析師』負責系統分析，最後再把分析好的設計文件交給 該死的 programmers 去實做。不難想像，以這樣的分工方式，sprint 的長度顯然不可能太短。如果是一個剛開始採用 Scrum 的團隊先採用這種『過渡時期』的作法，倒也無可厚非。但是如果要儘量遵循 agile 的精神的話，日後還是要想辦法打破這種『你是架構師』，『他是分析師』，『我是 倒楣的 工程師』的這種分工方法才好。應該全部的人都是 倒楣的 工程師，要死大家一起死，這樣才有 投名狀 團隊精神啊...XD。

其次，請屏除什麼『打好 agile 專案地基』的這種想法。Agile methods 就是要『embrace change』，就是要 evolutionary design。『捧油』，誤人子弟所賺來的錢，花起來會心安嗎？敏捷開發，絕對，絕對不需要用 UML 或是其他類似的 formal notations 來上手。想學 Scrum 的鄉民們，Teddy 在這邊拜託各位，千萬不要去畫什麼 use case diagrams, 把寶貴的生命（時間）省下來。要看的話，還不如去看 Scrum and XP from the Trenches 就夠了。

再其次，做軟體，用的就是『人腦』。不管用什麼阿貓，阿狗的方法，團隊成員的素質還是最重要的。千萬不要想說，用便宜的價錢多找幾個人來開發軟體，反正人多好辦事啊。錯，應該是人多易誤事，三個和尚沒水喝才是。根據某本書的說法，好的 programmers 跟不好的 programmers，其生產力可以差 10 倍。Scrum 與 agile practices 不是萬靈藥，也不是什麼神秘的武功秘笈。想要知道關於軟體開發的知識，書上幾乎都有寫了。問題出在於『做事的人』有沒有辦法去落實這些招數。這一點 Teddy 多年來有很深刻的感受，為了讓自己晚上可以睡得安穩一點，還是要多花點時間和銀子，找到合適而且可以合作的人。

最後，對於台灣很多中小型軟體開發團隊而言，也許人力不夠，因此導致『一個人打全場』的窘境：Product Owner 要兼任 Scrum Master 甚至還要當 developer，做三份工卻只領一份薪水。亦或是團隊中沒有專屬的 testers / QA Team 一起配合。也有可能對於眾多的 agile practices （例如 unit test，continuous integration，refactoring，pair programming，shared code，等等等等等等...）不熟，或是一時無法落實。此時，請想起 Teddy 所說的『Scrum 之逆練九陰真經 』，但是也要切記不可搞成『同誰，九陰真經不是這樣子練滴 』。

***

這個 sprint 即將結束，明天就是 sprint demo 與 retrospective meeting 的日子，Teddy 在昨天就先把下個 sprint 所要做的 stories 先準備好。今天下午五點左右，同事要 Teddy 幫忙測試（驗收）某個功能。假設這個功能有 10 個可能的路徑，在 Teddy 測試之後發現同事只做了其中的 5 個路徑。和同事討論之後發現，原來另外 5 個路徑需要參考某個資料才可以『有效率』的完成（缺少該資料程式還是寫得出來，但是會效率不彰） 。了解這個狀況之後，Teddy 重新評估一下，認為提供這個資料的重要性提高了，因此就把提供該資料的 story 排入到下個 sprint 中，降低了另外一個 story 的重要性。

Teddy 可以買書，你可以買書，他可以買書，每個人都可以買書。有沒有『傻的願意相信』的精神，那就不一定了。

***

友藏內心獨白：救人啊，地基到底還要打幾集才會結束啊。