[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (三) 帶領團隊走第一步 - Scrum中的角色與做法
請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。
坊間已經有不少介紹Scrum的相關書籍，其中也不乏很完整介紹整個Scrum的本土書籍，而讀者們也可以在網上找到不少介紹的資訊，因此，我並不打算很詳細的討論整個Scrum的每一個環節，而是希望在這篇文章中，著重在Scrum的實際執行經驗分享，以及如何搭配我們所採用的工具，也就是 Visual Studio Online。
這邊也稍微說明，讀者必須了解，要說Scrum是一個進行軟體專案方法(methodology)，不如說是軟體開發與專案管理的風格(Style)或框架(framework)，有趣的是，如果你用這幾個關鍵字上網google, 你會發現不少blog在說明Scrum到底是什麼? 有人說是方法、有人說是流程、有人認為不該說是流程，有人則認為是一個框架...然後又有一堆文章在討論敏捷開發(Agile)與Scrum的關係云云...
坦白說，我看了很久，但最後覺得，這些對我來說都不太重要，因為我在乎的只有一個，就是如何讓專案有好的結果，我只需要知道Scrum可以幫助我就可以了，至於其他的，等我開始實作了再說...
(所以我誠心建議，當你照著我或其他Scrum傳教士的介紹，準備開始在自己的團隊中實施某個動作時，請務必務必，要知道為何要這麼做...)
也因此，這篇文章就不討論Agile, Scrum之間的關係, 他們和CMMI以及waterfall開發方式之間的差異，以及到底是方法還是框架之類的話題...
我們直接來看, 採用Scrum的時候，會有那些程序(有別於傳統專案進行的SA, SD, Programming...階段...etc)。討論這個，用的當然就是底下這個比較動感圖:
由於Agile的精神之一，在於將一個較長的開發週期，細分切割為多個iteration, 在Scrum我們稱之為 Sprint。
建議的Sprint是1到4周，目前我們在實務上，大多都是採取2周作為一個Sprint。而Sprint的周期長短對專案有何影響呢?
由於一個Sprint Cycle中要進行的幾個重要動作如下，包含:
- Planning Metting(Part 1,2)
- 每天的Daily Standup Meeting
- Backlog Refinement
- Demo/review Meeting
(備註:我知道還有一些其他的會議，但由於一些原因，我們只挑了幾個我們最在意的來進行，而省略了一部分，這些我會在後面說明原因，並做一些討論)
因此如果Sprint太短，可能Team Member會覺得會議很多。而且每周都在Demo，壓力相對會比較大，一般來說，只有開發團隊急於對客戶建立信任時，我們才會將sprint定在1周，因此前面說過，目前我們大部分的案子，Sprint都是2周(有沒有在專案進行的過程中，改變Sprint長度的狀況? 其實，是有的。特別是PO被釘的時候，很可能就會從原本的3,4周，把週期改成1,2周)。
而我們目前實務上，Scrum進行中會有哪些角色呢? 我扼要說明如下:
- PO(Product Owner) :PO, 是產品(專案)的Owner，這個角色只能有一位(不能也不會是多人)。實務上，在大多數的狀況下，我們目前讓案子裡面我方的PM(Product Manager/Project Manager)擔任這樣的角色。他會決定開發的內容與順序，需要撰寫Product Backlog，需要有能力和客戶或老闆們(Stakeholders)溝通，確認規格和需求。整個Team，對PO負責，而PO則對客戶或老闆們(Stakeholders)負責。一個案子的成敗，我們交在PO手上。(所以我讓PO對SM和Team有人事權，因為他負責最終成敗)
- SM(Scrum Master) :SM負責確保項目依照Scrum方式進行，負責協調Team Members，負責召集和安排每一個會議。雖然，SM不應該也不一定是團隊中技術能力最強的人，但目前我們在大部分的案子裡，讓architect/Senior SD擔任這樣的角色。(SM和PO的立場常常有可能會有本質上的不同，因此我們至今持守著PO和SM不得為同一人的原則)
- Team Members (專案成員) :專案中所有的team Members 都算(QA, Programmer, Designer...etc)，這應該不太需要解釋。
- Stakeholders (利益相關者) :會特別列出來，就是這個角色常常出現，在產品和專案中，可能會有不同的Stakeholders，我方的主管、老闆、Sales、客戶端的承辦人、End-Users、客戶端承辦人的老闆(的老闆的老闆...)，都是Stakeholders。
好，知道了有這些角色之後，接著呢?
一般來說，在案子Kick-off之後，我們會先讓PO(甚至讓Stakeholders)，針對這個系統需要完成的功能，來撰寫Features，用的tool當然是VS Online。(這部分的具體做法，請參考後面"從feature開始(如何建立Feature? 注意事項?)"這篇文章)
底下是典型的Features List: (模糊的地方，是刻意的，以後這一系列的文章都是，因為要保護當事人... ^_^ )
Features描述了這個系統需要完成哪些功能， 基本上就是Wish List，一個願望清單，我們讓Stakeholders隨意把能想到的Wish List當放上Features，描述的方式很簡單，也不用任何的技術細節，甚至不用釐清作法或是能不能夠實現，就隨他們增加。
蒐集完所有Features之後，我們的PO要負責要求(是邀請)Stakeholders幫這些Features排出順序，並且讓PO開始將Features展開成Product Backlog。
如果說Features是願望清單(目標)，則Backlog就是如何實現這個願望的路徑(手段)。
在VS Online的Scrum Template當中，work items分為Feature/Backlog/Task三個Leval。我們對這幾個名詞的區分是...『如果Feature是目標，那backlog就是達成目標的手段，而task 則是這些手段的具體作法。』
Feature : 本系統能夠讀取Word, Excel...等MS-Office檔案，同時也支持Open Office格式。
那Backlog就會有:
- 建立Word文件讀取/轉換機制
- 建立Excel文件讀取/轉換機制
- 建立Open Office Writer文件讀取/轉換機制
- ....
相信我，建立Backlog確實是一門學問。
在教科書上，會告訴你建立backlog可以遵循一些法則(ex. as a type of user i want some goal so that some reason...)，並且backlog不應該出現技術字眼(而應該用一般人可以看得懂的方式描述)...這很正確，但真的很難，這對於PO來說是一個挑戰(後面有空的話我會分享一些實際的經驗)。
實務上來說，PO有能力可以把backlog寫出來，我們已經謝天謝地了。而且這過程中，我們的PO常常需要SM從旁協助，才能夠寫出像樣的backlog。有時候PO沒有技術背景，要寫出backlog很困難，有時候PO技術背景太深厚，要寫出沒有技術term的backlog也很困難。中間的拿捏需要一些分寸...
OK，有了Backlog之後，如同大家熟悉的Scrum一般，我們在每一個Strint的Planning Meeting中，由PO依照Prioirty把要進行的Backlog放入Sprint中(放入Sprint中的Backlogs，我們稱之為Sprint Backlogs)。接著，將Backlog細分(如果需要的話)，並展開成一個個具體的Tasks，並且指派給特定的Team member。
(Sprint開始後，team就應該focus在sprint backlog, SM要努力避免讓team被不正當或不正常的工作干擾)
在VS Online當中，我們可以清楚的看到從Features一路展到Task的畫面:
如此一來，專案的透明度大大的提升。
而在我們項目進行的過程中，隨時可以透過底下的燃盡圖，看到backlog或feature的完成度:
這對於PO(or PM or 老闆們)掌握整個專案的進行狀態非常有幫助。
(下一篇，我們就來看怎麼實際透過VS Online建立一個專案，並開始撰寫Features、Backlogs...etc)
本篇收錄自 - 『敏捷開發專案管理與架構設計實務』
留言