如何在「衝刺0」建立產品待辦清單（二）

在Scrum敏捷開發專案中，一開始在「衝刺0」階段，需要先建立產品待辦清單（Product Backlog）來確立專案開發時的工作項目，一般產品待辦清單的內容，除了「待辦項目」之外，還要列出「優先順序」、「初始估算」和「如何展示」的說明。上一回文章已經介紹過如何排列出待辦項目的優先順序，這一回，我們從「初始估算」開始介紹，這是用來描述每一個代辦項目預估需要耗費的工時。

初始估算
特別需要注意的是，Scrum敏捷開發對於「估算工時」一事，是交由整個團隊負責。在傳統的做法上，通常由專案經理負責估算工時，Scrum敏捷開發的做法，跟過去的做法非常不同。

當然，由真正負責工作的執行團隊來估算工時，是個很棒的方法，也可以預期得到更為準確的估算。但是，實務上，在專案剛成案初期，資源都還沒到位，所以開發團隊很可能根本還沒組織起來。所以，交由團隊負責初始估算一事，可能得在團隊已經成立的情況下，才能夠確切執行。

一般，估算可以採用「絕對值」或「相對值」，簡單說明如下：

● 絕對值：絕對值代表「實際的」估算數字。比方說，2個人要花掉4個工作天，才能做完的待辦項目，它的絕對值就可以設為8人日（Man-Day）。


● 相對值：顧名思義，會先有一個基數，然後其他的數字是基數的相對值。比方說，我們拿一個簡單的使用案例：變更定期定額設定，給它一個數值6當基數。這時，如果團隊認為「自動彙整基金交易」所需花費的時間是「變更定期定額設定」的2倍的話，那它的估算值就是12，如圖1所示。

單使用案例點估算法
前述的初始估算方法是Scrum敏捷開發中，十分常見的方式。不過，在我們的基金系統範例中，採用了另一種搭配使用案例技術使用的估算方法，稱為「使用案例點」（Use Case Point）。


使用案例點的技術是由Gustav Karner先生於1993年提出來的估算技術，它的估算公式如表1所示。我在之前出版的《寫給SA的UML/UseCase實務手冊》一書中，花了一整章的篇幅在談使用案例點估算，你若是有興趣，可以找這本書來看看。

由於，使用案例點的估算法有些複雜，所以我們簡化了它的用法，僅採用其中的「未調整使用案例點」（Unadjusted Use Case Point, UUCP）計算，如表2所示。簡單來說，未調整使用案例點就是沒把專案的技術複雜度和環境因子考慮進來，僅單純考慮使用案例本身的複雜度。


不過，未調整使用案例點的估算是以整個專案的方式進行估算。也就是說，以基金系統為例，未調整使用案例點算出來的是，4個參與者和18個使用案例的整體估算值。

但是，我們需要的是針對單一使用案例的相對估算值，所以我們再度簡化原先表2的估算公式，得出表3的估算公式。此處，為了與Gustav Karner先生所提出的使用案例點估算技術做區分，我們特別稱這個簡化後的使用案例點估算法為「單使用案例點」估算法，如表3所示。


至於，參與者權重和使用案例權重的概念，還是採用Gustav Karner先生的分級方式。此處，我們就直接引用《寫給SA的UML/UseCase實務手冊》書中，對於這兩個權重的說法，如表4、表5所示。

此外，簡化後的單使用案例點估算法，還可以用在團隊還未建立之前，只要得出初步的使用案例圖後，就可以由專案經理或資深分析師進行初始的估算了。當然，這裡得到的是相對值，所以等團隊真正組成後，就可以依照比例得出較貼近實際的估算值。

最後，我們挑選幾個使用案例初估它們的相對工時，如圖2與表6所示。以「查詢基金基本資料」為例，它是個簡單型使用案例（5）；不過它具有雙介面，所以會有兩個參與者：一個是需要圖形介面的複雜參與者：銀行行員（3），另一個是採用程式介面的簡單型參與者：網路銀行（1）。最後，我們加總5、3、1，得到單使用案例點估算值9。


如何展示
既然，Scrum敏捷開發強調，每個衝刺都要產出對客戶有增值的具體產出，當然就得簡單說明每一個待辦項目該如何展示（how to demo）。關於如何展示，有幾個要點如下：

● 時間：展示的時間點會安排在每一個衝刺期末。假設，我們以兩週為一個衝刺期，並且以週一為起始點的話，可以將展示的時間固定安排在第二個週五的上午或下午。

● 觀眾：原則上，這是個固定且非正式的展示。不過，團隊也可以廣發邀請帖，邀請其他同事、主管或者客戶來參加展示。

● 驗收：通過展示才能夠算是完成了該項待辦項目。

● 測試：雖然，這裡的展示說明很簡單，但是也算是個小巧簡單的測試案例，日後可以繼續延伸出更嚴謹的測試案例。

期初的產品待辦清單
產品負責人在撰寫期初產品待辦清單的細節時，再一次微調了基金系統的使用案例，如圖3所示，主要調整下列三個地方：



1. 合併使用案例：將原先基金公司伺服器所啟動的三個使用案例，合併在一起，並且重新命名為「更新基金交易結果」。

2. 自動改手動：還有，原先的「自動產生投資績效表」是由排程服務自動啟動的，現在改成由銀行行員手動啟動，因此更名為「產生投資績效表」。

3. 新增使用案例：此外，我們還新增了一個名為「查詢訂單交易明細」的使用案例，給銀行行員使用。

最後，我們先更新了基金系統的使用案例圖，如圖4所示。



然後，在進入衝刺1之前，我們還備妥了如表7和表8的基金系統期初產品待辦清單。




最後，關於如何展示待辦項目，我們有三個模擬機制，如下：

● 網路銀行：由於網銀客戶是經由網路銀行為入口，進行各項基金交易，但是展示時無法真的由網路銀行登入，所以開發團隊會寫一個簡單的測試網頁，模擬網路銀行。

● 銀行主機：基金系統和銀行主機之間，會有扣款之類的互動。所以展示時，開發團隊會寫一個簡單的銀行主機模擬系統。

● 基金公司伺服器：同上述，開發團隊也會寫一個簡單的基金公司伺服器模擬系統。

作者簡介：