ScrumWizard 1.0 GA 釋出

1. 緣起
2009年10月, 我們辦了一場敏捷開發實戰經驗分享會, 在這之前也讀過一些文章, 書籍介紹敏捷開發, XP(extreme programming), 但是僅於閱讀與了解階段, 並沒有真正的去實踐過敏捷開發所談到的實踐,  聽完了講師分享了他們的Scrum與敏捷實踐, 讓我們內部開始思考, 如何透過公司代理的產品codeBeamer來做Scrum的管理與敏捷的實踐.

2.ScrumWizard專案開始
2010年3月, 我們正式開始開發ScrumWizard, ScrumWizard剛開始我們取名為ScrumShell, 我在2008年12月做了一個實驗, 使用GWT來做codeBeamer wiki外掛程式的View layer , 我們思考了很久, 為了讓使用者在網頁操作介面上可以如桌面程式一樣使用Drag & Drop, 勢必要採用許多Ajax的技術, 所以決定使用這個之前做過的實驗與技術在codeBeamer上實現Scrum的管理功能, 因為這等於是在codeBeamer既有的功能又延伸了附加功能, 所以才取名為ScrumShell, 但是這個名稱是以技術角度出發有它的含義, 對於客戶可能對於Shell這個字眼會感到有點奇怪, 所以去年10月到中國北京Agile China參展時就更改為ScrumWizard.

3.混亂
新的專案一開始免不了會有一陣子的混亂, 這些混亂起源於

• 範圍太大: Scrum管理功能涵蓋了Product Backlog, Sprint Plan, Release Plan , Burn down report etc, 但是要從何處先下手?? 參考一些網站, 有些只做Sprint Backlog管理, 有些只做Task Board管理, 當然也有些是從頭做到尾. 
• 沒有客戶: 辦完了分享會, 客戶開始詢問codeBeamer要如何支援Scrum?? 但是客戶可是要先看到有成品才願意買單, 所以這個專案一開始, 我們就要先假想有客戶需要codeBeamer+Scrum的功能. 
• 團隊成員角色不清: 我們之前的經驗都是接客製化軟體專案, 誰來扮演Product Owner?? 誰來扮演ScrumMaster ?? 
• 對於Product Backlog管理不熟: 定義出來的Product Backlog太大, 無法在一個Sprint中完成, 還有什麼Product Backlog要先做, 後做?? 因為沒有客戶, 什麼Product Backlog才是最重要的?? 沒有人代表客戶, 說也說不清楚. 
• 技術還不成熟: 雖然有做過實驗是可行的, 但是有許多細節到實作才一一浮現

4. 第一個Sprint結束

所以第一個Sprint就是在混亂中結束, 不過由於採用Scrum, 我們定義一個Sprint為3周, 在3周中ScrumTeam按照我先前做的實驗, 先完成了一個最基本的GWT Wiki插件程式, 可以與codeBeamer互動.  對於使用GWT來開發Wiki外掛程式算是比較有把握.

雖然我們在codeBeamer上完整記錄了ScrumWizard的開發過程, 與每個Sprint做了哪些事, 我可能無法一一交代每個Sprint發生了什麼事, 不過以我們Scrum初級班的程度, 確實是一直到Sprint4以後才慢慢上軌道. 主要原因有下

• 經過幾個混亂Sprint的磨合, 並對產品Scop要做哪些功能有較清楚的輪廓. 
• ScrumTeam掌握技術開發的難度後, 預估一個Sprint可完成哪些Product Backlog, 需要多少Effort比較精準.
• 一開始就導入使用Hudson/Jenkins做Continue Integration, 雖然還是採用傳統測試流程, 但是實施AutoBuild與Auto Deployment/Release,  測試人員的回饋時間變短了. 每天都可以回饋新的Build有哪些Bug, 並配合白板做Daily Standup Meeting, 對於進度有不錯的掌握度. 這個可以參考這份簡報, 裡面有描述我們的流程. 這個流程在我們導Scrum扮演一個很重要的角色. 
• Unit Test有發揮作用:  Unit Test配合Auto Build後, 必須Unit Test通過測試才交給測試人員測試. 所以至少測試人員不需要浪費在因為軟體工程師修改架構產生的錯誤回饋時間. 

5. 調整

      在還沒有ScrumWizard前, 我們是很確實執行Daily Standup meeting , 但是自從我們在ScrumWizard實作了白板功能, Daily Standup meeting確漸漸的減少. 原因是我們團隊已經習慣在ScrumWizard上的白板溝通. 有問題就馬上寫comment回報, 後來幾個Sprint證實並不會影響到專案的進行. 

6. 未來的挑戰. 

      到目前為止, ScrumWizard算是涵蓋了Scrum的管理功能, 以codeBeamer+ScrumWizard+Hudson/Jenkins這樣的整合性, 等於是提供了一個快速入門的框架, 但是 "精益" 的精神是不斷的改善求精求益. 並不能這樣就感到滿足. 以下是我們導入Scrum與Agile實踐覺得還有改善的空間

1. 在設計階段就要導入測試框架: 這一點坦白說, 我們還做的不是很好, 有做Unit test並不代表通過測試, 整合式的測試介面在導入Auto Test前, 這個基本功是需要的, 軟體設計沒有提供測試介面, 要做到自動測試只能說是空談. 但相對要做到, 也要考慮時間與成本
2. 從Subversion改採用DVCS(Git or Mercurial): 由於沒有強制工程師使用Branch, 雖然每個Sprint都會有Release, 但是每個Sprint 3周, 而且一直都在trunk修改程式, 要獲得穩定的版本,變成一項挑戰. DVCS的branch功能會是我們下一個專案的嘗試重點. 

如果您對ScrumWizard有興趣可以參考http://scrum.esast.com