.NET Walker

很高興有機會和大家在 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.

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想要跟

請留意這篇文章是我配合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架構): 可以成功進入專案首頁之後，第一步，你必須做幾件事情，

請留意這篇文章是我配合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周作為一個Sp

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的 VS Online 標籤以閱讀更完整的前後文。 Scrum和敏捷開發，在這幾年幾乎變成顯學。這很有趣，如果你深入觀察，會發現Scrum和過去的專案運行模式，有著 "根本上" 的差異。 而且確實，我對Scrum有些 "自己的" 看法。 在討論這些之前，首先，我必須先強調一件事情。我在團隊中導入Scrum，並不是為了要研究或驗證Scrum，也不是為了要遵循大師的腳蹤，更不是為了要體驗一下新的專案運行方式或是新的工具...都不是。 執行Scrum的理由只有一個，而且非常簡單，就是我們(專案團隊)希望讓案子成功。 會這樣說，是因為過去這十多年，在台灣，我們參與、執行、聽聞大大小小的案子，失敗不勝枚舉，幾乎沒有多少案子是在客戶和開發團隊都滿意的狀況下收尾的。專案不是延遲、就是超過預定的人天成本、再不然就是數不盡的客戶需求變更、或是解不完的Bugs和無法預測的未來、再加上客戶的預算和我們的成本看來永遠無法達到平衡。 經歷的案子越多，就越來越覺得這不是一個辦法。 客戶對於專案預算壓低又壓低、要我們提供報價卻不知道專案的範圍與具體內容、每一個案子的能見度都非常低，PM、開發人員、沒有人知道案子將會怎麼收場... 說真的，我們受夠了這樣的生活。 敏捷開發和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的架構。 累積了信心和經驗之後，接著，我就在我能夠掌握的相關團隊中，將整個流程比較有計畫的實施了起來。一實施下去，確實也發現，果然在台灣

 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個用戶( 若不計折扣，目前是