.NET Walker

2015/11月底，微軟在Connect();大會，正式公布了大幅度改版的線上TFS，也就是變了新名字的VSTS(Visual Studio Team Services，從前叫VSO)。 VSTS可視為線上版的TFS，讓開發人員可以對軟體的生命週期做非常良好的管理，是一套ALM軟體服務。翻成白話一點，就是軟體專案的統籌管理軟體。 更新後的VSTS，除了原本的版控、自動化建置、測試，以及工作項目管理之外，加上了眾人期待已久的數位儀表板功能： 這個討喜的功能，讓團隊以及PM/PO可以一目了然的看到整個專案的整體狀況，當然，這個儀表板是可以客製化的，有各式各樣的組件，可供專案管理人員選擇應用，您也可以為專案建立多組儀表板，分門別類的以視覺化方式來呈現所有資訊。 我們接著就來看，如何客製化這個數位儀表板。 (等等，你竟然還沒申請免費的VSTS專案管理服務? 請參考 這裡 。) 如果你有管理員權限，現在，進入VSTS專案之後，你會看到overview頁面上，右下角有一個『+』符號： 按下上圖右下角的按鈕，會出現一堆的Widget供你選擇，你可以隨意用滑鼠選擇一個或多個，佈置在預設的數位儀表板上： 類似像上圖這樣，可以點選幾個widget(被點選的會打勾)，按下新增(add)之後，即可加入: 這很簡單，但重點是，這些圖表有何用途? 如果熟悉TFS/VSTS使用或和我們一樣採用Scrum開發框架的朋友們，應該很熟悉了，你可以在畫面上看到底下這些: 這些都是從library直接抓取出來的Widget，當然，你也可自行建立不同的查詢(Query)，以呈現想要的結果。 例如，我們可以在work底下的Queries中，建立一個Query: 我們查詢專案中所有的Backlogs，儲存完成後，移入Shared Queries： 接著，建立一個新的Chart: 有各種圖表可以選擇，我們選擇Pie圖，並設定Group by “state” 欄位: 我們設計好圖表之後，可以透過圖表右上角的選單，把圖表釘選到數位儀表板上: 我們看看: 成功的在數位儀表板上，把Backlogs的狀態顯示出來囉。如此一來，一目了然的呈現出整個專案的狀況，老闆、客戶和PM還能說專案不夠透明嗎? 不僅如此，還有個好玩的功能，Query Tile讓你可以針對某一個數字設定紅綠燈警示看板，你可以點選Q...

四月底，VSO又悄悄的更新了看板(board)功能: https://www.visualstudio.com/news/2015-apr-27-vso 這就是SaaS有趣的地方，每隔一段時間，你總是能夠優先(比起TFS Server)享受新的功能，讓用戶有著像是拿到新玩具的快感。 這次改版的集中在Kanban(看板、board)身上，坦白說，過去VSO的board雖然不算難用，但大概不會有人說它很優。主要是除了能夠顯示backlogs和tasks等workitem之外，也就只能夠讓work item在不同的status間移動來移動去，僅此而已。 不過隨著看板方法愈受重視，MS這次一口氣新增了不少功能。對於board的客製化作了不算小幅度的增強。 過去，我們比較習慣在Backlogs畫面新增Backlog，不僅僅是因為Board的編輯功能不是很完整，且網頁時常需要refresh也讓人覺得有點不好用。     這次改版之後，你大可直接在Board畫面輸入PBI(Product Backlog Items)或bug，整個AJAX操作更順了：     所有你需要的編輯功能這次估計都支援了，而且effort欄位還很貼心的給你下拉的費氏數列:    別以為只有1-13，如果你想更大或更寫，試著先選13(或是key一個數字)之後，再點下拉筐會出現更大或更小的數字。    如果你覺得Card上的欄位顯示得不夠完整，右上角的設定給他按下去，你會看到可以自訂顯示欄位:    Cards選項可以讓你自己決定那些欄位要顯示：     Columns選項則可以讓你自訂work items要區分那些Status，以及WIP(work in process)的限制警示數量設置:     當然，Sprint中的Board也支援類似的功能，可以新增、可以編輯、可以指派、可以設定remaining works:       甚至，還加上了 by People 做Group:   更一目...

  2015/4/2很高興今天有機會和大家介紹了如何透過Scrum與TFS進行團隊開發的一些心得分享。相關的資料可以參考底下網址:   https://www.mentortrust.com/History/Seminar2015 

再上一篇我們談過了Task的建立之後，接著，我們來看看延伸出的圖表。 在VS Online當中，有兩個比較關鍵的圖表，是與工作進度有關的。一個是先前提過的燃盡圖(BurnDown Chart)，另一個則是累計流量圖(Cumulative Flow Diagram)。 由於我們先前看過了燃盡圖，因此我們先來看一下累計流量圖。 累計流量圖(Cumulative Flow Diagram) 累計流量圖主要呈現出專案中每一個Backlog在時間軸上狀態的變化，外觀大致讓如下： 你會看到圖表右邊的四種狀態分別是New、Approved、Committed、與Done。如果你還記得，這四個狀態是Backlog的狀態，可以從Backlog的維護畫面中設定： 但更多的時候，其實我們比較喜歡在Backlog的看板(Board)當中用拖曳的方式來設置(改變)狀態： 一般來說，我讓PO/Scrum Master建立Backlog(剛建立的Backlog狀態為New)，但我只讓PO把Backlog從New改為Approved ，一但開發完成，Tester/QA測試無誤，則讓Scrum Master將該Backlog從Approved狀態改為Committed ，PO(或客戶)驗證無誤後，則由PO將Backlog從Committed改為done。 而你看到的累計流量圖，則是這個狀態在時間軸上的變化狀況。也就是說，從圖上看起來，如果綠色的done面積佔有的比例越來越大，則表示這個專案逐漸完成，反之如果灰色的New佔有的範圍越來越大，則表示這個專案的新需求持續增加。 從累計流量圖當中，很容易可以看出整個專案的健康程度，以及完成的比例。 燃盡圖(BurnDown Chart) 燃盡圖我們在前面討論『剩餘時數 與 燃盡圖』討論過，從燃盡圖上我們可以看到在Sprint中所有工作項目(Tasks)的完成度。 某種程度上來說，燃盡圖用以表現出特定Sprint的剩餘工作量(藉此預估是否能夠如期完成)，而累計流量圖則可以看出整個專案的整體工作進度(也包含了新需求的成長速度)。 透過這兩張圖表，PO或Scrum Master、Stakeholders可以很清楚的知道整個專案的健康狀況，也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的...

Task的建立與撰寫 Task 是 backlog 的子階，一般來說，我讓 PO 來建立 Backlog ，由 Team Member 或 Scrum Master 來展開 Backlog 建立 Task 。 Backlog 代表著是要待完成的功能 ( 任務 ) ，而 Task 則是具體展出來的開發工作。 Backlog 多半沒有技術的用詞，最好的寫法是以非技術的 term 來撰寫 ( 讓 stakeholders 也能看懂 ) ，而 Task 則是該功能 ( 任務 ) 的拆解開來的具體工作了，所以有一些技術的 term 並無不可。 將 PO 所撰寫好的 Backlogs 展開 ( 或拆解 ) 成 tasks ，是在 Scrum 的 Planning Meeting 中發生的， 所以一開始專案 Kick-off 前後，可能根本只有 Backlogs 而沒有 tasks 。   還記得嗎 ? Backlogs 中有一個 effort 欄位，寫的是預估時間。 在台灣，專案成案前，往往必須告訴客戶預估金額和時間，但 Tasks 都還沒有展開，能算出 100% 準確的預估時間嗎 ? 我不認為可能。依照 Backlogs 所估出的時程也僅僅為估算而已。專案團隊最好不要讓 PO 或 Sales 以為這是時程上的『承諾』。 而真正到了專案開始進行，把 Backlogs 展成 Tasks 之後， PO 和 team 才會慢慢了解 ( 認清 ) 專案的真相，一些被隱藏的工時才會慢慢出現，特別是 3-5 個 Sprint 之後，就可以清楚的知道自己的預估是否準確，從而進行修正。 也因此，落實到合約的簽訂，如果可以，最好在總時程和總金額尚保留一點空間。 ( 我承認在台灣很難 ) 在操作的實務上， Sale 依舊可以依照過去的報價方式 ( 把預估膨脹個幾倍 ) 來報價，但對於 PO 、 Scrum Master 、 Team( 甚至客戶 ) 來說，在運行 Scrum 之後，專案的透明度無疑地提高了。 ( 關於專案報價與成案問題，可以參考 飛機上的 27A - 談敏捷開發的成案問題 ) 如何 建立Task 在 Work 分類項目下，你可以看到 Backlog Items ，請留意當滑鼠移動到下圖...

先前我們在 這一篇 當中，曾經介紹過如何從Features展開Backlogs，但也有非常多的狀況是直接產生(建立)Backlogs，這時候我們就有可能需要重新連結(對應)Backlogs與Feature之間的關係。在這一篇當中，我們來看看這個部分。   前面說過，你可以從Features展出Backlogs，這部分實際上操作時很簡單，你只需要在Features畫面中，依照底下的方式，就可以透過『+』從Features以展開的方式來撰寫Backlogs了。   但如果你的Backlogs是獨立寫好的，或是先寫了Backlogs，後來想要讓它歸屬於某一個Features，或是調整Backlogs的Features，可以怎麼做呢?請參考下圖： 你可以先把Backlogs與Features的Mapping打開，即可拖曳特定Backlog到特定的Feature身上，以建立(或修改)兩者之間的關係。 此外，如果你觀察Product Backlogs的輸入畫面，會看到畫面右上部分，有一個forcase，可將其設為On，接著，會出現一個Forecasting Velocity讓你輸入調整（每個Sprint的工作量），設定後，即可看到如下圖的預估： 你會發現，系統已經參考了我們輸入的參考工作量，依照Backlogs的順序，計算出會大致落在哪一個Sprint ，這個功能非常的好用，能夠讓客戶一目了然的知道特定的Backlogs大約會何時開始開發。 但請留意一下這張圖，坦白說這張圖乍看之下不是很容易理解，所以我特別用藍底白字的箭頭，標註了一下Sprint。你會發現，編號1,2,3這三個Backlogs，是屬於Sprint 6進行開發的，而編號6,7,8,9則是屬於Sprint 8進行開發的。特別標註是因為，如果你把藍底白字的箭頭拿掉，你可能會以為編號3,4兩個backlog items是屬於Sprint 6，而編號5,6,7,8的backlog items是屬於Sprint 7，那可就誤會大了。 本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

每一個Backlog都有可能因著PO或Team Member的調整，而改變了狀態或內容，這個改變可能來自於團隊成員，也可能是擁有權限的任何人。但你不需要擔心，work item的每一個調整，哪怕只是上傳了一個檔案，或是在description中增加或減少了一個字，你都可以透過History看的一清二楚，因此不僅不用擔心被異動，也不會有資料經過修改後遺失了的問題。 要看到Backlog的History，可以開啟Backlog，接著點選 History：       進入到History之後，你可以更清楚的看到，該Backlog狀態的改變、以及Backlog的所有異動： Backlog和專案中的每一個工作項目(不管是Task/Features/Bugs…etc)都是開發團隊相當關注的部分。也因此，每當這些Work Items有異動的時候，老闆們(或是PO)可能都會想要知道。 因此，VS Online除了讓你可以從Backlogs/Task的History中看到變更之外，還可以透過訂閱的方式，來隨時掌握這些Work Items的異動。 你可以進入Project的首頁，在右上方有個『工具』的圖示： 點選該圖示後，會進入到管理畫面(請留意，必須具有管理權限才可以進入)。進入後請按下Alerts頁標籤，接著會看到底下畫面: 你可以從左方的選單處看到該專案所有的Alert，而右半部則可讓你建立或修改Alert。 當你點選New來新增Alert之後，會看到底下視窗：   你可以選擇Alert的範圍和類型，按下OK後即可新增。在底下的新增畫面中你可以看的出來，是依照剛才選擇的Alert範圍和類型所建立的。當然您也可以自行客製化調整，增加判斷條件，或是這個通知的發送對象。   按下OK鈕之後，這個Alert就建立好了，也同時間生效。此後，一旦Work Item有所變更，訂閱者將會收到類似底下這樣的email:   對於開發團隊來說，是相當好用的機制。   本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

在實務上，專案可以不寫Features，但不可能跳過Backlogs。 由於蒐集好Features之後，基本上Features只是客戶的Wish List，談不上是什麼規格，基本上只是針對系統需求的期待而已。因此，我們會讓PO稍微排一下優先順序(當然是參考客戶的意見)，接著，開始把Features展開成為Backlogs。實務上，你也可以把Features視為Backlogs的大項分類。如果系統不是很大，那只寫Backlogs不寫Features(或是用後面會提到的階層式Backlogs取代Features)也並無不可。 如果參考微軟MSDN網站上的翻譯，微軟把Backlogs稱為『待處理項目 』，類型上還分為三種。 不過我倒是覺得，我們可以從比較扼要的角度來看Backlogs(簡化可以降低工具和開發方法導入的困難度)。 在這邊，我們先簡單定義一下。我們將一開始建立好尚未放入Sprint中)的Backlogs，統稱之為Product Backlogs，至於進入Sprint之後，被放入特定Sprint中的Backlogs，我們稱之為Sprint Backlogs。因此，剛寫好的Backlogs，全都是Product Backlogs。 至於何時要將Product Backlogs放入特定Sprint(成為Sprint Backlogs)? 則是Planning Meeting要決定的事情了。(會在後面Planning Meeting中介紹) 此外，剛才前面有提到過，多個backlogs之間，也是可以有階層關係的，例如:   這個階層也可以視為Backlogs的分類，有點像是Features的意味。   Backlogs 的來源其實有很多種可能性，原則上大多是從 Features( 或是上一層的 Backlog) 展開，或是直接從系統分析後的規格書謄過來。   ===================================== 備註：         這邊要做一些說明，一般來說，我並不會希望團隊在run scrum的過程中，額外多一個撰寫系統分析說明書這一段。因此，我們一般是直接針對end-user做系統需求訪...

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