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。
 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務
 

沒有留言: