l

2013年10月2日 星期三

需求的大小

Sept. 30 14:42~16:15

螢幕快照 2013-09-30 下午4.13.16

 

在導入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。
螢幕快照 2013-09-30 下午3.09.59

***

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

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

***

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

沒有留言:

張貼留言