需求的大小

Sept. 30 14:42~16:15

 

在導入Scrum的時候，如何撰寫需求一直是一個困擾Product Owner的問題。之前Teddy已經談過好幾次關於Story撰寫格式的問題，今天想談一下需求大小。

一個需求如果太大，可能沒辦法在一個sprint（2~4週）之內開發完成，也就沒辦法快速得到客戶的回饋意見。假設有一個很大的需求開發完成之後已經過了三個月，這時候再拿給客戶看，萬一被被客戶打槍，這三個月的功夫可能都白費了。

但是，需求如果切得太小也會造成其他的困擾。例如，把一個新增、修改、查詢、刪除的功能切成四個Story，在某個sprint完成新增功能拿給客戶看，但是從客戶的角度來看，認為這個功能一定「新增、修改、查詢、刪除」一起使用，所以單獨讓客戶看新增功能對於客戶而言是浪費他的時間。再者，如果把所有的需求都切割成很小的user story然後丟到Product Backlog裡面，那麼在管理上只看到個別單一的user story，比較難看出user story之間的功能特性關係。

***

Dean Leffingwell在《Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise》這本書中，將需求的尺寸（size）由大到小分成四種：

• Investment Theme（投資主題）：企業對市場上的產品布局或產品線。例如，開發導航軟體的公司，在市場上可能會有「導航軟體」、「轉乘服務」、「修車服務」等產品線。或是一個開發App的公司可能會有「交通服務」、「股票服務」等不同的產品線。
• Epic（史詩）：Epic顧名思義就是「很長的敘述性詩篇」，翻成白話文就是比較抽象、high level的需求描述。以交通服務這個投資主題為例，可能包含「捷運資訊」、「公車資訊」、「停車資訊」等三個Epic。由於Epic太大、太抽象，所以軟體開發的時候不會直接拿Epic當成實作的需求，會把Epic切割為更小的Feature或Story，再進行開發的工作。
• Feature（特性）：Feature有點不太好解釋，有人說Feature是可供區別的軟體功能，這個字也經常拿來泛指功能。以公車資訊這個Epic為例子，可能包含「公車動態」與「班次時刻表」。簡單的想，Feature就是比Story還要大的需求單位。
• User Story（用戶故事）：User story相信鄉民們就很熟悉了，以公車動態這個Feature為例子，可能包含「即時動態查詢」與「出門提醒」這兩個user story。

***

Teddy自己的經驗，以前採用RUP的使用，用use case撰寫需求，才會把需求之間的關係用類似上圖的階層圖來表示。後來採用Scrum之後，Product Backlog裡面只放epic和user story這兩種東西。但是有些user story比較大，會被進一步的切割成更小的user story。

如果團隊的Product Owner是屬於比較有「計畫性」的那種人，也許可以參考這四種方式來規畫與管理需求，應該會有不錯的效果，而且有的老闆或是客戶也比較喜歡看這種階層式的系統需求圖。

***

友藏內心獨白：該不會還要搞什麼traceability吧。