2014年6月26日 星期四

[經驗分享]如何用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中要進行的幾個重要動作如下,包含:
  1. Planning Metting(Part 1,2)
  2. 每天的Daily Standup Meeting
  3. Backlog Refinement
  4. Demo/review Meeting
(備註:我知道還有一些其他的會議,但由於一些原因,我們只挑了幾個我們最在意的來進行,而省略了一部分,這些我會在後面說明原因,並做一些討論)
 
因此如果Sprint太短,可能Team Member會覺得會議很多。而且每周都在Demo,壓力相對會比較大,一般來說,只有開發團隊急於對客戶建立信任時,我們才會將sprint定在1周,因此前面說過,目前我們大部分的案子,Sprint都是2周(有沒有在專案進行的過程中,改變Sprint長度的狀況? 其實,是有的。特別是PO被釘的時候,很可能就會從原本的3,4周,把週期改成1,2周)。
 
而我們目前實務上,Scrum進行中會有哪些角色呢? 我扼要說明如下: 
  1. PO(Product Owner) :
    PO, 是產品(專案)的Owner,這個角色只能有一位(不能也不會是多人)。實務上,在大多數的狀況下,我們目前讓案子裡面我方的PM(Product Manager/Project Manager)擔任這樣的角色。他會決定開發的內容與順序,需要撰寫Product Backlog,需要有能力和客戶或老闆們(Stakeholders)溝通,確認規格和需求。整個Team,對PO負責,而PO則對客戶或老闆們(Stakeholders)負責。一個案子的成敗,我們交在PO手上。(所以我讓PO對SM和Team有人事權,因為他負責最終成敗)
  2. SM(Scrum Master) :
    SM負責確保項目依照Scrum方式進行,負責協調Team Members,負責召集和安排每一個會議。雖然,SM不應該也不一定是團隊中技術能力最強的人,但目前我們在大部分的案子裡,讓architect/Senior SD擔任這樣的角色。(SM和PO的立場常常有可能會有本質上的不同,因此我們至今持守著PO和SM不得為同一人的原則)
  3. Team Members (專案成員) :
    專案中所有的team Members 都算(QA, Programmer, Designer...etc),這應該不太需要解釋。
  4. 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。

Feature : 本系統能夠讀取Word, Excel...等MS-Office檔案,同時也支持Open Office格式。

那Backlog就會有:
  • 建立Word文件讀取/轉換機制
  • 建立Excel文件讀取/轉換機制
  • 建立Open Office Writer文件讀取/轉換機制
  • ....
然後上面這些Backlog,在確定要做的那個Planning Meeting中,會被展開成更細項的Tasks。

相信我,建立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)
 

沒有留言: