用故事地圖管理敏捷開發需求（下）

Jan. 13 14:52~15:58

 

上一集提到可以用故事地圖（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所預計要完成的功能。依此類推，下圖規劃了三個版本的產品釋出。

***

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周。

***

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

***

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