2014年6月27日 星期五

[研討會] 2014 Microsoft ALM Day



很高興有機會和大家在2014 MS ALM Day中分享關於 Scrum/ALM以及VS Online和Azure的使用心得,相關的的內容和影片,我會陸續整理出來,如果您沒機會來現場,可以先參考底下幾篇blog:
[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (一)緣起
[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (二)讓我們來聊聊Scrum
[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (三) 帶領團隊走第一步 - Scrum中的角色與做法
[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (四) 開始使用VS Online與Scrum Template
[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (五) 從蒐集 Features 開始

還沒寫完,後面的我盡量努力找時間整理...(to be continued...)

hope it helps.

2014年6月26日 星期四

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (五) 從蒐集 Features 開始

VS Online/VS 2013針對Scrum的工作項目管理,是以下圖這樣的層級來區分的。從Features到Tasks是有著一對多的層級關係的,例如一項Features可能會有多個Backlogs,一個Backlogs可能會有多個Tasks這樣。跟Backlogs平行(層級)的還有Bugs,在一個Bugs底下也可以區分tasks,像是這樣:



一個軟體系統的一切從蒐集Features開始,你可以把Features看作Wish List,也就是這個系統、或是這個專案要有那些功能。

這邊有一個地方您可能需要注意。在台灣,實務上,不管在做的是一個專案(標案)或是產品,老闆(客戶)都會要你寫規格書,然後依照這個規格書來開發。這個規格書可能是SA與客戶(End-Users或IT部門專案的Internal Users)訪談後的結果,過去,我們花了很多時間在建立這個規格書上(然後再從這個規格書算出專案成本和工時)。

但我們前面說過過,在這個多變的時代,規格是一天到晚在改變的。也就是說,基本上傳統的規格書現在幾乎可以說是廢物。如果依照waterfall的開發方式,規格書應當要持續更新,要能夠隨時反應系統的現況,但這在現實情況下很多專案上幾乎不可行。

PM/SA不太會去更新規格書的內容(有的案子PM/SA根本是兼職的,分析完就閃人了),客戶對規格的變更也不會回頭寫在規格書上(甚至有時候是直接跟Developer用口頭講的、或發個mail了事),一個專案只要run了三個月下來,規格書基本上就等同於作廢了。

更荒謬的是,實務上規格變了,更但合約上的價格和時程卻不變更,專案的預計完成時間和逾時的罰則也不變,這樣的專案想不賠錢收場很難很難。

回頭談規格書,因此你會發現,不管是SOW或是SA後的Spec,在很多專案中,可以說是參考用的。坦白說,如果能參考也就罷了,很多時候是連參考都不行,有爭議時回頭翻規格書,才發現根本沒更新,或內容模糊不清太多細節沒有釐清(甚至為了成案或驗收之便,刻意保留模糊,保留空間以利各自解讀)。這樣的規格書大概只能用來在kick-off前後交差,對開發工作一點幫助都沒有。

因此,我們不寫規格書了。現在,我們只寫Features與Backlogs。(而且就儲存在VS Online中,不會另外弄個document,如果PO/PM想要跟老闆或stakeholders交差或報告,請PO/PM自行從VS Online中擷取)

所以Features和Backlog就是我們的產品規格書,也是開發的依據和驗收的條件。這樣一說,你就知道它的重要性了。

蒐集Features

所以接著,我們來看看怎麼蒐集Features。
這部分說起來似乎很簡單,但中間實在還是有些眉角。

做過幾年軟體專案,你一定知道,所謂的Wish List基本上就是天馬行空的亂想,好一點的客戶自己會收斂一下,比較沒禮貌的客戶想到的功能就會逼著你去實現(上面的客戶,在做的是軟體產品時,你也可以直接換成老闆)。

也因此,蒐集Features不是問題,列出重要性和區分商業價值,則是處理Features的重點。

我們交由PO(PM)進行這項工作,因此,撰寫Features時候,完全不需要使用任何技術的Term,就是用正常麻瓜都看得懂的文句來敘述即可。Features的來源可能是客戶、End-User、老闆、各別stakeholders。

別忘了,專案成本是PO的責任。並且,我們在進行開發的團隊,完全都是從這個Features清單展開的Backlogs來建立tasks,進而進行後續的開發工作,因此,這份Features對開發人員來說,就是我們的規格書,一個好的開始,往往關係著後續專案的成敗。

好,那實際上要怎麼將Features輸入VS Online呢?

首先,你必須注意一件事情,basic權限的用戶,是看不到features這項功能的!!! 沒錯,目前就是這樣,因此,只有具有advanced權限的人(我們給PO這權限)才能夠鍵入Features。不過這樣也好,我們跟著這樣的設計,在權限的區分上就簡單多了,因為PO對客戶、stakeholders負責,而team對PO負責。所以team不去看Features也好,Team Member只需要focus在Backlogs,而PO/SM把features展成backlogs給Team Member進行開發,這樣其實很符合在管理上的需要和精神。

建立Features

OK,那怎在VS Online中建立Features呢?

請進入專案的主畫面,接著點選Wrok,在出現的work items管理畫面中,點選Features:

(注意,如果用戶並非Advanced權限,會沒有這個功能)

接著在主畫面中,你就可以逐一輸入每一個蒐集到的Features,輸入完畢後按下[Add]鈕,即可儲存。

輸入時,每一個Features簡簡單單的一句話即可,然後把每一個Features輸入後,你可以在某個Feature上面double-click,會點開該Feature:
 
這邊就要說明一下了...

剛才我們輸入的Features只是標題,每一個Features都可以有一些描述,和參考欄位。(別忘了,這份Features是我們的規格書,是我們要開發的每一個功能的參考來源)

PO在蒐集這些Features,當然必須針對到底要開發什麼,做個簡單的說明。例如,上面這個『系統具備有計算BMI的功能』,實在太模糊了一點,所以我們需要針對這個做一些描述。PO可以在上圖中左下方的『Description』欄位中,針對要進行的功能做一些描述。而上圖右下方的Acceptance Criteria則是針對這個功能的驗收標準。

==============================
例如:

Description:
BMI是身體質量指數,計算方式是 BMI=體重(KG)/(身高(M) x 身高(M)) ,系統必須能夠在web或windows操作介面,都要能夠有能力計算出此數值。計算的小數點取兩位四捨五入即可。

Acceptance Criteria: 
身高輸入 170
體重輸入  70
計算後的結果是 24.11
==============================

這些Features是蒐集來自客戶端的最粗糙的功能需求描述,其中可能還需要經過細化或確認,在這些Freatures被轉為(展開成)Backlog前,PO還有機會更客戶持續溝通取得最完整和正確的功能需求,因此一開始輸入的時候不用太擔心。

而Features什麼時候會被轉為(展開成)Backlog呢? 這就看Priority了。

你會發現上圖中的視窗上半部有一些欄位,針對比較重要的欄位說明如下:
[Iteration] 也就是這個Features被放到哪一個Sprint,一開始建立不用太在意,我們後面會用拖曳的方式來調整它。
[Assigned To] 這個Features的負責人,我們都放PO。
[State] 這個Features的狀態,有New, In Progress ,Done, Removed。BJ4.

[Priority] 中可輸入表示項目相對優先順序的數字。數字越大,表示優先順序越低。

[Business Value] 中可輸入數字,表示項目的相對商業價值。(也就是出錢的人有多重視啦,這跟Priority可能不同喔)

[Target Date] 這個欄位則是這個Features希望完成日期(並非是預計,是希望)。

 
剛才提到的畫面下半部,還有一些很讚的功能:
 
Implelentation和Linkes有時候容易混淆,不過要區分並不困難,基本上Implelentation就是這個Features透過那些Backlogs來實現,而Links則是可以一股腦兒的把所有相關的work items都給關聯起來。
 
而history是一個挺不錯的功能,它以視覺化的方式,呈現出一個Work Items在生命週期中的每一個階段,發生的時間與進行此調整的人員。
 
這對於我們進行Features的管理與追蹤相當有幫助。
 
==========================================================
 
 VS Online中Features管理的功能,讓我們的PO/PM可以跟客戶把系統的基本功能大致上整理出個輪廓。不過要請留意,在這個Features List當中,完全沒有任何系統架構、資料庫、開發架構上的描述,因此目前只是很粗淺的SA階段(甚至連SA都沒做完,就只是需求的蒐集),而何時會進行SD呢? 我們是放在Backlog展開時,以及Planning Meeting的階段。
 
不過這顯然是不夠的,如果SD或架構設計的時間太壓縮,或是順便做做,對日後的延伸性、延展性或重用性恐怕會有影響,也會造成產品的品質低落。也無法規畫出適當的共用模組,或把系統作開發上的切割。
 
但敏捷開發又不希望我們過度的Over Design啊,這中間要如何拿捏呢? 是否要安排一個Sprint,就是做設計呢???
 
關於這個部份,我只能這麼說,我們在實務上每個案子的狀況不同,都曾經經歷過,也都有各自的利弊得失,身為PO/SM/Architect必須一起討論與溝通,找出對你手上這個案子最有利的方式。
 
但值得一提的是,幾個案子下來,我們採用了一種比較特殊的方式,來解決系統架構設計的問題。
 
和一般的開發團隊不同,我們一直都有自己的開發架構。我們並不允許開發人員拿起Visual Studio開了ASP.NET WebForm或是ASP.NET MVC專案就開始進行開發。而是所有的開發都是基於我們已經開發好的幾套架構為基礎,進行的功能搭建和延伸。
 
如此一來,我們可以巧妙地解決架構設計的問題,碰到不同類型的專案,我們只需要讓PO/SM/Architect針對這個專案的特性,在幾種不同的開發架構範本中,選擇最適合的一種即可。當然,這需要長時間的團隊經驗累積,才能夠往這個方向發展。
 
--------------------------------------------------------------
 
Features的部分先說到這邊,下一篇,我們來介紹Backlogs。
 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務
 

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (四) 開始使用VS Online與Scrum Template

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。
 
隨著專案的kick-off,我們會正式讓整個team開始使用VS online進行所有的工作與控管。
我大致說明一下我們在kick-off的前後所進行的工作。

(請讀者再次留意,我所分享的是我們自己在實務上的經驗和處理方式,所以不要留言來問我怎麼沒有依照某本書上說的Scrum方式來進行,因為我說過了,實務上我們必須依專案依團隊因時制宜,但你可以留言問我為何選擇這麼做而非那麼做,這部分則是很有討論和交換意見的價值)

首先,PO(Product Owner)是整個專案的負責人,我讓PO選擇自己的SM(Scrum Master),並且讓PO和SM選擇自己的team member。理由很簡單,PO負責案子的成敗,因此PO當然有人事權,PO和SM可以選擇自己喜歡的team member,身分就如同教練和領隊一樣。要打好球賽,有時候選擇的球員並非是能力高超的,而是跟我有默契的,或是配合度高的。有時候能力超強的高手,並不一定會是個好合作的team member。

因此,我讓 PO/SM決定自己要的球員是誰,而最後不論結果如何,PO都負責整個案子的成敗。畢竟,人是你選的,失敗了也不用有太多藉口。

順帶一題,有沒有一個team member太受歡迎必須同時軋很多team的情況? 有,如果是這樣,由PO自己決定接不接受,接受了,就必須承擔風險。有沒有team member找不到歸宿,沒有PO選他??? 也有...這表示...如果有天真要裁員,你大概知道可以從誰下手了。

OK,團隊成員決定後,我讓SM在VS Online開立一個Project。
如果你完全不曾使用過VS Online,你必須先建立一個VS Online站台,細節請參考這邊

VS Online站台建立好之後,你可以在上面建立無數個專案,建立一個專案的動作也請參考上述的文章,請注意在選專案類型時,請選擇Scrum Template(因為我們的專案整個走Scrum架構):

可以成功進入專案首頁之後,第一步,你必須做幾件事情,分別是:
  • 添加專案的成員(Developers、PM、PO、SM...etc)
  • 安排與設定專案的Iterations
  • 安排與設定專案的Team或Area
上述的每一個動作都有著各自的重要意義。底下分別說明如下,並且說明如何實際操作。

Step 1. 添加專案成員
  • 由於未來我們的Source code control、Work Items整個都在VS Online當中,包含bug tracking、document、unit test...等全都透過VS Online。因此,理論上所有與開發相關的人員,都必須添加進去成為專案的Member,我們可以提供這些人員basic類型的帳號。
  • 對於PO(PM)/SM,我則會建立Advanced類型的帳號。主要的原因是PO/SM必須要檢視Features,針對Stackholders傳送Feedback Request,查看各樣的圖表案工作項。
一般來說,在專案中添加人員只需要從該專案的主管理畫面上進行即可,請點選下圖中的Manage:

您會看到可以點選後出現底下畫面,接著按下Add:

你會發現可以新增一個User或Group:
 
請點選 Add user,接著請輸入任何一個Microsoft Account:
 
按下 Save Changes後,即可完成用戶的新增。
 
但需要留意的是,這樣新增的帳號,並未明確的指派該帳號的種類(Advanced? Basic? VS Online會很貼心的自動幫你用權限比較大,也就是比較貴的帳號 ^_^ ),因此,請點選左上角的VS Online Logo(這樣會回到站台主畫面):
 
 您會在主畫面看到 users 選項,點選後會進入帳戶管理畫面,您可以在這個畫面中,將每一個剛才加入的用戶配置成basic或advanced:

這樣,您就可以妥善的安排每一個用戶的權限,並且依照購買的數量來增減用戶以控制預算了。

備註: 至於您有多少個basic or advanced帳號可以配置,則是看你在Azure管理站台購買的數量(還記得這邊的介紹嗎?),一買最低就是一個月為單位,請留意。

Step 2. 安排與設定專案的Iterations

當專案啟動後,我們會用VS Online來管理專案中的每一個Features/work items,以及source code。

Source code管理的部分我們就暫且先不說了(如果以後有機會我再補齊),主要是因為有用過TFS的開發人員肯定知道怎麼用,而VS Online在版控上的操作完全相同,因此不需贅言。

這一系列文章我們先focus在work items和Features的處理。

回顧先前所提過的,敏捷開發的核心精神之一,就是把開發周期縮短成多個iterations,在Scrum中我們叫做Sprint。(其實想一想,我覺得不管是不是敏捷開發,只是要近代開發,都應該縮短週期)

前面曾經說過,這個Sprint可能是 1-4 周,一般來說我自己喜歡用2周。但這個長度完全取決於你希望專案有多透明,這個衝刺有多密集。

經驗上來說,2周是一個比較舒服愉快的周期,1周多半意味著開發人員和PO, Stakeholders都得要上緊發條;但 3 or 4周我自己覺得有些鬆散了,比較適合人數比較多的開發團隊。

要在VS Online當中設置iterations,請在專案(注意,不是整個站台,因為一個站台可以建立多個專案)畫面的右上角,找到設定的圖示:

點選設定圖示後,你會看到底下的畫面:

再次請注意,是從專案的首頁點選設定,才會看到上面的環境,才有iterations可以點選,如果是從VS Online的站台點進來,就只剩下兩個頁標籤,沒有上面的iterations了。

請點選iterations頁標籤,你會發現預設狀況下是Release包著Sprint,你可以設置每一個Sprint的週期,如同我們前面說的,可以是1-4周,而VS Online也很聰明,你設置完第一個之後,後面的Sprint在設置時,只需要設置開始時間就會幫你算出結束時間。

如同畫面上所看到的,我們未來在一個Sprint當中,會經歷Scrum的一個循環,包含Planning Meeting, Daily Scrum, Demo(review) Meeting...等。而連續幾個Sprint之後,我們會有產品(專案)的一個minor release。

因此,你可以透過上圖中的功能,來設置每一個Release與Sprint的時間,我自己喜歡至少每一個季就有一個Release,甚至每一個月就有一個Release,這完全依照你有多愛現(也就是你的產品有多喜歡曝光、或是頻繁更新對產品來說有多重要)來決定。一般來說,用戶熱愛新鮮感的行動裝置App的更新週期,比起用戶喜歡穩定的商業軟體更新周期來的高很多,這部分就看你自己的規畫了。

設置好了之後,回到專案(再一次,不是站台,是專案)主畫面之後,可以點選主選單的work,你會發現我們規劃好的Sprint已經出現在畫面當中了,接著我們就可以新增Backlog囉。

Step 3. 安排與設定專案的Team或Area

一般來說,如果開發團隊的人數不是很多,且Features蠻單一的,是不太需要理會team或area這個功能的。

該功能一樣是從專案的管理畫面進去,可以看到頁標籤中有一個Aresa頁簽,不過你可以先不要理他,因為直接建立一個team,系統也會幫你建立一個對應的Area:


主要原因是這樣的,當一個系統比較大時,我們常常會切割成兩三個team同時一起開發,但Source code版控的部分,還是統籌在一起管理(因為總是有共用模塊或是組件)。這時候,你只需要建立一個主專案,接著依照實際開發的團隊來切出子專案即可。

舉例來說,一套ERP可能會同時切出財物模塊、銷售模塊、庫存模塊...等,前面說過每一個模塊由不同的團隊來開發,但程式碼版控當然是放在一起。這時候,你就開一個ERP Project,然後為每一個模塊建立一個Area分開管理即可,例如finance、POS、HR...etc。

還有一個常用的情境是這樣...我們要開發一個APP,但這個APP有Win8, WP8, Android, iOS...等不同版本,也可以為這些不同的Client端各自建立一個Area。

當區分出Area之後,不同的Area底下,Features、Backlogs等Work Items是切分開來的,但source code和Sprint卻可以共用,這樣可以讓我們在專案管理上更加方便且符合實際情境。

OK,瞭解了概念之後,我們繼續。

剛才說到,Area部分可以不用理他,是因為其實你可以在Overview頁簽下,直接建立一個Team,在上圖中,按下『 New team』連結,即可建立:

您會發現,當您建立一個Team之後,VS Online預設會幫這個Team建立一個同名的Area:

建立好之後,要怎麼移到這個Area呢? 你可以先回到站台主(注意,不是專案,是站台)畫面,然後點選 Browse ,在出現的視窗中,展開你的專案名稱,會發現Area/Team出現在這個專案的下面:

點選它之後,按下右下角的Navigate按鈕,畫面就移動到這個Area中囉,您會發現,在原本的Project後面,多了Area(Team)的名稱,接著,請點選主選單中的Work:

您會看到,Backlog和Features也依照Area(Team)被分開顯示與管理了。但,Sprint的時間區段則是共用的。這樣,其實非常符合我們日常進行開發工作的習慣。

好啦,開始的準備動作做得差不多了,接下來,我們要開始進行專案開發了。

進行專案開發工作前,當然是清楚的掌握Features,也就是要完成(實現)的功能,下一篇,我們要來介紹如何撰寫 Features與Backlog...

底下的影片是在VS Online當中,建立專案以及規劃Iterations和Team的操作步驟,請自行參考:
 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務
 

[經驗分享]如何用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)
 

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (二)讓我們來聊聊Scrum

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。

Scrum和敏捷開發,在這幾年幾乎變成顯學。這很有趣,如果你深入觀察,會發現Scrum和過去的專案運行模式,有著"根本上"的差異。

而且確實,我對Scrum有些"自己的"看法。

在討論這些之前,首先,我必須先強調一件事情。我在團隊中導入Scrum,並不是為了要研究或驗證Scrum,也不是為了要遵循大師的腳蹤,更不是為了要體驗一下新的專案運行方式或是新的工具...都不是。

執行Scrum的理由只有一個,而且非常簡單,就是我們(專案團隊)希望讓案子成功。

會這樣說,是因為過去這十多年,在台灣,我們參與、執行、聽聞大大小小的案子,失敗不勝枚舉,幾乎沒有多少案子是在客戶和開發團隊都滿意的狀況下收尾的。專案不是延遲、就是超過預定的人天成本、再不然就是數不盡的客戶需求變更、或是解不完的Bugs和無法預測的未來、再加上客戶的預算和我們的成本看來永遠無法達到平衡。

經歷的案子越多,就越來越覺得這不是一個辦法。

客戶對於專案預算壓低又壓低、要我們提供報價卻不知道專案的範圍與具體內容、每一個案子的能見度都非常低,PM、開發人員、沒有人知道案子將會怎麼收場...

說真的,我們受夠了這樣的生活。

敏捷開發和Scrum的出現,讓我們『聽說』有一個更好的方式,讓客戶和專案團隊都過的開開心心。並且大家認真扎實的面對專案中的每一個問題,用合作與信任替代稽查、用溝通協調替代文件、用最簡單的工具和方法,讓整個專案回歸基本面。

由於我們是認真的開發團隊、有著相當資深的開發人員,我們不希望用哄抬的方式膨脹案子的預算,然後再打折來成交。我們的開發團隊真心喜歡編程,我們一點都不希望我們熱愛的工作在專案裡卻變成痛苦的來源。(真心話)

我們相信客戶想要一個真正能夠使用的軟體產品,而不只是想要結案交差,我們相信軟體可以有效的幫助企業實現利潤,而不只是畫一個美好卻遙不可及的大餅去騙客戶的錢。我們希望客戶真的使用我們所開發的軟體,讓我們的軟體創作與建設真正幫上客戶的忙。

所以,我們看到Scrum,我們開始覺得對未來有希望。
====================================================

因為上面提到的這些背景和原因,我開始讓團隊導入Scrum。(而原因只有一個,就是希望案子成功,專案中的每一個角色都快樂)

然而要談敏捷開發與Scrum的內涵,你必須知道幾件事情。這也是敏捷開發最主要的價值觀,對我來說,這幾乎可以說是Scrum實施的前提。

和進行傳統的專案不同,由於看到其他團隊累積的很多經驗,我們在啟動Scrum前,就有了底下的心理準備:
  1. 打從心底接受規格(需求)變更,而非期待客戶承諾出不可變更的規格。
  2. 著重產出可用的軟體成品,而非美美的文件或是結案報告。
  3. 與客戶的關係是基於合作與信任,而非一紙合約。

別小看上面這些。

上述的每一點,幾乎都顛覆了台灣現行的軟體專案開發的潛規則和行規...並且和現行的專案管理辦法可能南轅北轍、甚至完全不同,我們逐一扼要說明(後面幾篇會再詳細介紹與討論)。

第一點: 打從心底接受規格(需求)變更,而非期待客戶承諾出不可變更的規格

光是接受規格是可變動的,就是一個非常核心的不同。(以前我們在專案中一直在做的,則是拼命守住或鎖住規格)

有經驗的PM會立刻想到幾件事情,規格可以變動,那專案價格怎麼估算? 時程和人力怎麼安排? 如果客戶改了規格那我們要怎麼做? 不能擋? 都要吃下來???? 這個那個這個那個...一堆問題出現了...

不僅如此,這部分甚至整個影響了系統分析和設計,由於規格可能隨時改變,因此over design本身就會變成非常大的問題,這個原則很可能會改變的架構設計的實施方式。有時候,我們因此會採用漸進式設計(Progressive Design)的方式來取代一次到位的設計(對很多架構師來說,這很掙扎)。很多時候我們在每一個iteration之中,會允許不完美但可接受(重點是要可以用)的產出,這對很多Developer來說又是一個掙扎。(後來,我們採用架構範本來解決這個問題,不過這事後話了,以後有機會再跟大家分享)

接著,這可能會改變合約和時程預估...

因為規格可以變動(記得嗎? 我們真心歡迎規格變動!),所以開發團隊和案主必須能接受所謂的時程預估,就真的"只是預估",那既然是預估,就可能估不準。隨著預估的開發時間愈長,預估的準確度就愈差。例如,如果這個案子我們估計的時程是三個月,那也許正負誤差在兩周,但如果預估的時程是九個月,那正負誤差搞不好不只六周,而是12周了...

也因此,案主不能夠拿預估的時程,來計算這個案子的成本或預算,也就是說,合約上最好不要有固定的專案金額(因為規格根本還沒決定啊,甚至,規格是可以變的,那怎麼會有固定的金額呢?但如此一來,怎麼跟案主的老闆討論專案成本和預算? 這樣,這案子會不會根本無法成案? (專案團隊要怎麼面對這個問題呢???)

第二點: 著重產出可用的軟體成品,而非美美的文件或是結案報告。

軟體產品要可用,而且要時時可用,同時間我們要捨棄非常多的傳統紙本文件產出,讓開發團隊把時間都花在客戶真正要的"功能"上。那...交接怎麼辦? 開發時的依據和溝通怎麼辦?  難道不需要注意驗收條件? UAT和驗收不是才是專案的重頭戲嗎?

因為要著重產出可用的軟體成品,所以我們非常重視每一個iteration的Demo Meeting,每兩周或每一個月,我們會邀請案主(stakeholders)來看看我們的進度展示,及時提供反饋,如果案主不滿意,隨時可以暫停、甚至打掉重建,當然,案主必須和專案團隊一起承擔過程中的成本。

這意味著,案主不能再跟過去一樣,坐在自己家裡等著專案團隊來SA訪談,然後就沒事了。很可能,案主必須每個月參與軟體的測試,投入在整個案子的開發流程之中。再也不像過去,付了錢就等UAT時,再以上級指導員的角色,來指指點點。

但這樣,案主會願意嗎? (如果不願意,專案團隊怎麼辦?)

第三點: 與客戶的關係是基於合作與信任,而非一紙合約。

這點導致有一個和傳統軟體專案之間,非常非常巨大的差異。因為客戶要能夠和團隊一起承擔專案的風險,對開發團隊來說,最理想的合約當然是金額不固定的人月報價型的合約,但這樣案主就非常有可能擔心花了錢卻拿不到自己想要的軟件,卻又不能拿著合約和UAT的時程與罰則,來逼著專案團隊趕工或是吃下去各種需求變更。

這樣,對於案主來說會不會太虧了? (其實,實務上根本不會) 但這樣做,案主真的會接受嗎?
==============================================================

光是上面我刻意凸顯出來的這幾點,你就會發現這似乎跟台灣現在軟體專案的運行方式有著天大的差異,但實際上我們碰到的心理衝突遠遠不只如此(但讀者也不需要擔心,面對這些衝突,都有著不同的解決技巧),只是我挑了其中幾個和當前專案進行思路有著最大差異的部分,來凸顯敏捷開發和傳統開發的不同之處。

再說,寫這篇並不是為了研究Scrum,而是想將我們段時間以來,採用Scrum來開發專案所面對的問題與解決方式記錄下來。所以,我不能保證裡面每一個想法與作法都和坊間的書籍相符,因為專案管理,必須因時因地制宜,有時候團隊成員不同,採用或偏重的技巧就有所不同。

但我要強調的是,Scrum為我們帶來了一個面對專案新的可能性,並且讓團隊成員和PM對專案更加的有信心、有興趣、甚至有熱誠。光這一點...就讓我深深的覺得值回票價了!!!

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (一)緣起

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。

這一篇是先談談整件事情的緣起...

過去,Scrum並不是我主要的興趣,ALM一開始也和我沒有太密切的關聯,這麼多年來,我一向是務實主義者,工作上有用到的技術我才會多少涉獵一下。而過去這十幾年,我專注的大多都是.NET的軟體開發技術,而非ALM或是專案管理(雖然我小時候對管理就有著濃厚的興趣)。

因此,接觸Agile/Scrum,最早要說是因為李智樺(Ruddy)老師的關係。

其實Ruddy老師專研敏捷開發多年,但我一直沒有機會好好跟他聊聊這部分。然而有一次,在海外參與一場大型技術盛會,講的是架構設計,有幸我和Ruddy老師都是講員。

還記得,講完第一堂課之後,Ruddy老師中午吃飯時跟我說:『David,你整場內容都講的非常好...』聽到前輩的肯定,我正準備油然自得,但沒想到...Ruddy老師繼續說了:『但...中間有個地方我覺得不太對,不過你別擔心,我下午場會幫你跟學員說你哪裡講錯...』

OOXXOOXX...這怎麼得了,難得來海外上一次課,就要被Ruddy老師拆台?

因此,我當下就激起奮發之心,由於中午時間已經來不及,當晚拉就著Ruddy老師討論他覺得有爭議的部分...

OK,原來核心問題是對於專案管理和開發流程上的差異,我用傳統的開發流程和管理方法,來闡述架構設計,但Ruddy老師覺得,依照Agile敏捷開發的精神, 則應該是如何如何如何...

有台灣首屈一指的Scrum大師在旁,果然不同,當下如同醍醐灌頂,強灌了20年功力ㄧ般,真氣運行於腦幹與突觸之間,喜悅之情實在是無從言喻。

但,這都還只是別人的經驗,要能夠把別人的功力內化成自己的功力,得要實作才行。

當下我就覺得,接下來我要搞個案子來玩玩。

不玩還好,一玩下去不得了!!! 接下來我們公司所有的項目(專案),都被我從傳統的waterfall形式,整個改成了Scrum的架構。

累積了信心和經驗之後,接著,我就在我能夠掌握的相關團隊中,將整個流程比較有計畫的實施了起來。一實施下去,確實也發現,果然在台灣/大陸對於專案管理的實務操作上,會與國外的案子和教科書上所描述的略有不同。過程中,我們面對到不少的問題,當然也累積了些許的經驗。

由於我們和微軟一直以來都有著固定的合作,再加上我們的團隊分散於整個大中華區(包含台灣、大陸、和新加坡),因此我們需要的Scrum工具是一個可以讓遠端工作人員自由的協同運作、且足夠安全又穩定的工具。也因此,毫無疑問的,我們是透過大家熟悉的 Visual Studio Online(VS Online)來進行版控、需求與工作項管理、bug tracking與測試。

過程中VS Online也持續的在改版,從免費試用的測試階段,一路走向正式上市。隨著VS Online完整度越來越高,我們在項目的管理與Scrum的操作上也越趨便利與成熟。

如今,我們終於可以釐清,為何Scrum在這幾年一反常態的異軍突起,透過敏捷開發如何提高開發的質量,更重要的是,提升客戶的滿意度與信任,解決過去台灣(乃至於兩岸華人圈)軟體專案常常收不到尾款、虎頭蛇尾、或是失敗收場的悲劇。

所以,我想把這一年多以來的經驗順手記錄下來。由於網路上關於Scrum的分享已經太多了,所以我盡可能聚焦在透過VS Online的Scrum template來處理團隊開發的經驗以及搭配Microsoft Azure進行雲端開發與架構設計的部分。

不過,既然是經驗,就不一定是100%正確。你知道,鄉民常說:我的菜不一定是你的菜。同樣的,我的情境不可能完全等同於你的情境,我的團隊也不同於你的團隊。所以,您看了之後,在你的環境中,能夠使用多少,就存乎一心了。

為了降低大家閱讀的困難,也減少我打字的時間,因此我盡可能地將這一系列分享簡短,如果讀者有疑問,我再補充,目前規劃的內容大致上如下:

  1. 緣起 - 就是這篇
  2. 幾句話說說Scrum的精神 -  來聊聊我心裡的 Scrum
  3. 帶領團隊走第一步 - Scrum中的角色與做法
  4. 如何使用VS Online的Scrum Template來運行你的專案
    1. 如何建立帳號、專案、以及專案的參與成員(費用如何計費?)
    2. 專案的環境設定(Sprint, 日期, 團隊規劃...etc)
    3. 從feature開始(如何建立Feature? 注意事項?)
    4. 決定Backlog(如何建立Backlog? 注意事項?)
    5. 從Backlog到Task
  5. 關於工作進度、Backlog的life Cycel 與 cumulative flow
  6. 我最在乎的幾個Scrum週期性活動
    1. Planning Meeting
    2. Daily Scrum
    3. Demo Meeting
  7. 如何取得Stakeholders的Feedback
  8. 關於時程預估
  9. 如何面對專案型客戶傳統思維的衝突?
我會先寫上面這些,如果有時間或有需要,我再補其他的部分。

既然是經驗分享,就非常歡迎大家一起討論。你知道,每一種技術、方法,都不可能是放諸四海皆準,隨著應用情境和參與在其中的人,都必須適度的調整。所以你可能無法從這一系列的文章中學習到很標準的專案管理(我也不知道是不是真的有所謂的標準的專案管理技巧),但你可以參考我們實際發生的經驗,相信或多或少對你會有所幫助。

hope it helps.

2014年6月19日 星期四

如何申請與建立VS Online帳號、連結Windows Azure進行付費設定、開始團隊開發


VS Online是MS推出的超級好用的免費(有限制)團隊開發ALM(Application lifecycle management)工具,從程式碼版控、測試、取得反饋、Features管理、bug tracking...etc 一應俱全,這一篇,我們從頭介紹如何申請與建立VS Online的站台。
 
請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。
 
Step:首先,請用一個Microsoft Account登入(如果你已經申請有Windows Azure帳號,建議你用申請有Windows Azure帳號的Microsoft Account登入,便於未來付費方便),登入後,進入底下網址:
http://www.visualstudio.com/
 
看到下圖畫面後,請點選『免費開始使用』:
 


 

接著會看到底下畫面:

比較需要注意的是上述的 Account URL,因為以後你的專案都在這個網址的下面,所以一般來說,我們會建議你用公司(團隊)的名稱,例如 http://MyCompany.VisualStudio.com 這樣。

整個申請好了之後,未來你就可以透過輸入該URL進入到你公司(團隊)的VS Online站台了。而一個站台底下,可以建立多個專案,每一個專案則可以設置多個User(Developers, PM, SA/SD, PO, SM...etc),以及多組開發團隊(例如一個App專案,可能有Widnows Phone團隊、有Win8團隊、有iPad團隊...etc)。

=============關於付費(開始)============

注意:這邊要留意一個計費的問題,每一個站台(不是專案),允許五個免費的用戶,超過五個目前就要收費了,而這五個用戶,是以站台來計算的,也就是說,如果你在一個站台底下,建立了三個專案,這三個專案各自分別有5個用戶,則這個站台就會有15各用戶,除非這15個用戶中,有重複的人員,否則你就必須最少付出10個用戶(若不計折扣,目前是每一個basic用戶每月20元定價美金收費)的金額。此外,收費的方式是跟著windows azure帳號的,因此你必須先建立一個azure帳號,以處理付費問題。

如果你已經有了Windows Azure帳號,你可以進入該帳號的管理portal,會發現左方選單中有個Visual Studio,點選後,會看到底下畫面:

請選擇 『建立或連結到 VISUAL STUDIO ONLINE 帳戶』,接著會出現底下畫面:


你可以選擇『連結到現有的』,就會出現剛才我們建立的VS Online站台。

您大概也會發現,其實如果你原本就有Windows Azure帳號,但還沒建立VS Online站台,也可以在上述畫面中,直接選擇『快速建立』,會出現底下畫面,讓您直接用這個Windows Azure帳號來建立一個相關聯的VS Online站台:

連結或建立完成後,你會看到底下畫面:

你會發現azure已經跟VS Online關聯了,這時,你若點選進去該站台,會出現底下畫面:

若你要付錢買帳號(不付錢買帳號可以嗎?可以,但只能用五個帳號玩玩),請點選上述位置,接著會看到底下畫面:

 
你可以調整你要購買的License數量,調整完後按下『儲存』即可變更。你可以從這邊了解基本、專案、和進階三種用戶的權限差異。

一般來說我給developers基本帳號,而PO和SM則是Advanced帳號。

=============關於付費(完畢)============

接著,我們回到VS Online,你可以從主畫面中,點選下圖中的位置來建立一個專案:
 

點選後會出現底下畫面:

輸入專案相關資訊後,並選擇開發流程(Process template)範本後,按下『Create Project』後,即可建立一個專案。

專案建立完成後,你會看到底下畫面,點選『Navigate to project』,即可進入此專案的首頁:

進入首頁後的畫面如下:
 
接著,你就可以開始享用你的專案進行團隊開發了。
 
可以成功進入專案首頁之後,第一步,你必須做幾件事情,分別是:
  • 添加專案的成員(Developers、PM、PO、SM...etc)
  • 安排與設定專案的Iterations
  • 安排與設定專案的Team或Area
這部分我會在接下來的幾篇文章中介紹。
 
另外,有一個部份建議您先處理,也就是整個站台的時區設定。
請點選站台右上角的工具圖式:
 
接著會看到底下的Control panel畫面,請選擇Setting:
 
建議您先將上述的時區改成 +8 以配合台灣這邊的時區。您也會發現可以在這個畫面調整系統的Account Owner和URL。
 
請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。