l

2014年1月16日 星期四

用故事地圖管理敏捷開發需求(下)

Jan. 13 14:52~15:58

螢幕快照 2014-01-10 下午6.48.13

 

上一集提到可以用故事地圖(Story Map)來協助開發團隊建立需求,並且可以取代標準列表式的Product Backlog。今天要談一下,如何透過Story Map來做釋出規劃(Release Plan)。

先複習一下上面這張圖不同顏色的意思,紫色代表User Activity(使用者活動),藍色稱為User Task(使用者工作),黃色稱為User Story(使用者故事)。在Scrum裡面最小施工需求單位是Story,建好Story Map之後,接下來有兩種不同的釋出規劃方式。

***

Time-Boxed方法

Time-Boxed(釋出時間固定)的規劃方式就是一般敏捷開發採用的方式:

  • 釋出時間固定:例如,六個月後要參加展覽,所以下一個版本一定要在六個月後釋出,如果錯失了展覽期限才釋出產品,就沒有意義了。
  • 知道團隊的Velocity:Velocity就是團隊每個開發週期(sprint或iteration)完成的每一個story的story point總和,也就是團隊的開發速度,或是生產力
  • 估算Story Point:為了要做釋出規劃,必須要針對Story Map裡面的story估算story point。

接下來就很簡單了,假設團隊的Velocity是30,sprint長度是兩周,公司希望每3三個月就要對外釋出一個版本。因此每一個release團隊可以完成30 * 3 * 2 = 180個story point。

接著團隊針對Story Map裡面的user story先依據優先順序(對客戶價值的高低)做排序,然後估算每一個user story的story point。把最重要的user story的story point相加,點數加起來在90點左右的那些最重要的user story就是第一個release所預計要完成的功能。依此類推,下圖規劃了三個版本的產品釋出。

螢幕快照 2014-01-13 下午3.16.33

***

Feature-Boxed方法

Feature-Boxed(釋出功能固定)的規劃方式是傳統的專案規劃方式,就是顧客或是老闆先列出他希望軟體具備哪些功能,然後再依據需要完成功能的多寡來決定釋出時間。

  • 釋出功能數量固定:例如,第一個版本要完成30個user story。
  • 知道團隊的Velocity:要做釋出計畫,團隊的velocity的是不可或缺的數據。
  • 估算Story Point:同樣需要知道Story Map裡面每一個user story的story point。

接著團隊先決定第一次釋出要完成哪些功能。傳統的習慣,老闆或客戶會希望釋出次數少,但是每次釋出完成的功能個數要多一點。如果鄉民們的專案或是公司型態是屬於「Lean Startup」這一派的,則可以將釋出計畫想像成定義「最小可行產品」(Minimal Viable Product;MVP)

選好了下次釋出所要開發的user story,就可以預估開發所需時間:story point總數 / velocity。例如,如下圖所示,第一次釋出的story point總和是130點,團隊的velocity是30,釋出時間約需要130/30=4.3個sprint,約需9~10周。

螢幕快照 2014-01-13 下午3.44.24

***

最後附帶說明一點,也有不需要估算story point就可以做釋出規劃。如果團隊可以將需求都切割成大家接近的user story,這樣團隊的velocity就可以用「每個sprint完成user story的個數」來表示。但問題是,要把每一個user story都切割成大小接近的功能,這也不是一件簡單的工作啊挑眉質疑

***

友藏內心獨白:有機會可以嘗試一下。

2 則留言:

  1. hi 版大 感謝您的分享
    另外想詢問一下 Velocity 的算法
    是怎麼評估出來的呢 !? 能轉換成常用的時間單位 或是 金錢嗎 ?!

    回覆刪除
    回覆
    1. 我的部落格和網路上都有相關資料,找一下就有答案了喔。

      刪除