小攻城師的戰場筆記

ezScrum 是以 JAVA 開發的開放原始碼 Scrum 輔助工具。
由於現在的資通訊產業產品生命週期越來越短、需求變動頻仍，
為了能使產品更有競爭力，必須要能夠快速釋出產品，
並能夠控制架構 (architecture) 變異所帶來的衝擊。
在專案流程中採取 Scrum，就是希望能夠提高軟體開發時測試與控管的品質。

Scrum 就像它字義上的意義一樣，
我們在開發軟體時，要像橄欖球進攻時一樣，在有限的回合內進攻完畢。
在 Scrum 中，我們會把專案時程切割為多個衝刺期 (sprint)，
通常一個 sprint 約兩週左右，可以讓專案有多次得到回饋的機會，
以利隨時確認是否符合需求、修正方向。
（傳統的 Waterfall 只能在完成點收集回饋，一失足即成千古恨）



傳統的開發過程耗費太多時間在文件製作上面，
SA/SD 的工作包括了定義變數名稱、DB 欄位等等，
以至於到最後常發生「不如讓 SA/SD 自己把 code 也寫了」的情況，
也因為文件要寫得太細，所以遇到需求頻頻變動時，
往往也沒有時間可以維護這些冗長繁複的文件，導致文件與程式不同步。

在 Scrum 中，工作產品是程式本身、而非文件（除非把文件視為一種工作），
打破了過去「有分工、沒合作」的局面，減少大家自掃門前雪的狀況。

過去估計工時的工作由 PM 來處理，
在 Scrum 裡，讓 Programmer 自己決定工時。
Programmers 可以圍坐在一起拿撲克牌來計算工作點數，
共同討論各任務需要的時間、優先順序等等，
經過這樣的討論之後，得到的工時估計會更貼近現實。



在第二場 session 中，講者以過去協助導入的經驗建議：
初期導入 Scrum 只要先進行 sprint、讓團隊成員習慣 Scrum 節奏，
不要一口氣導入 pair programming, unit test……等等太多東西。
至少要先讀過 "Scrum and XP from the Trenches"，認識 Scrum 裡會出現的角色，
例如 Product owner 要負責時程控管、全掌專案成敗責任等。

Run Scrum 時，要先訂出 sprint，估計實際可用的人日
（把人員是否同時支援其他活動的專注度也列入考量），
接著選擇要進展的 story，估計 story point。

可是估計 story point 時，怎樣算是一點呢？
估計的方式可以依照團隊的習慣而訂，
第一種方式是將一個 point 視為一個理想工作天（5 小時可以完全專注的狀態）；
第二種方式是依照相對難度來訂，
先選一個 story 來當基準點、再來訂其他 story 相對的點數。



理想上，Scrum 團隊的成員應該要坐在一起比較好，
以製造最佳的溝通環境，不過成員若分散各地，也可以照著 Scrum 精神跑就好，
例如使用 skype 來取代面對面的 daily meeting。

如果只有兩個人的 team 怎麼 run scrum？
在權責部分，即使 Scrum master 和 member 可能是同一人，
仍然要盡可能區隔每個人的角色與責任；
另一方面，工作項目一定要想辦法區分出重要性來，
如果每個 task 都是 critical item，那這樣的 Scrum 一定會垮掉。

由於 ezScrum 不支援版本控制，
因此在建構管理可以另外使用其他版本控制系統，
再回到 ezScrum 增加一個建構管理的 story，讓流程完整。





當日的演講目前僅有第一個 session《Scrum與資通訊產業軟體開發》已釋出。
個人是很喜歡第二場的《實施Scrum的業界經驗分享》啦，
不過這場因為講者要求，所以錄影檔是確定不會釋出了，
想瞭解講者想法的人倒是可以 follow 一下他的 blog：Teddy Chen 搞笑談軟工，
對我個人來說這個 blog 的癒療效果不輸《Peopleware》呀，
譬如說加班後回家拖著疲累的身軀連上 internet，
看到《對症下藥》這一篇總是多少能讓治積鬱化內傷的。

第三場則是 ezScrum 的介紹與 Live Demo，
其實有興趣的人可以直接下載 ezScrum 來試玩看看。

Scrum 軟體開發工具與方法──系列講座（一）
軟體開發又快又好！
2010/03/11 (Thu.) P.M.1:30 - 4:30
台北科技大學綜合科館第二演講廳

Scrum與資通訊產業軟體開發
台北科技大學電子系榮譽教授王瑞材
台北科技大學資工系教授鄭有進
P.M.1:30 - 2:20

實施Scrum的業界經驗分享
Certified Scrum Master, 美超微專案經理陳建村
P.M.2:30 - 3:20

敏捷式開發專案的開放源碼工具：ezScrum
ezScrum團隊歐伯浩
P.M.3:30 - 4:20





延伸閱讀：David Ko 的學習之旅：《Scrum and XP的實戰經驗》系列文章