[經驗分享]如何用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.
一個軟體系統的一切從蒐集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針對這個專案的特性，在幾種不同的開發架構範本中，選擇最適合的一種即可。當然，這需要長時間的團隊經驗累積，才能夠往這個方向發展。
--------------------------------------------------------------
留言