這個月在新竹敏捷聚會時, 我們舉行了一個有關於用戶故事的撰寫工作坊, 介紹了什麼是用戶故事, 讓大家動手撰寫了一些用戶故事和驗收條件. 希望能讓參與的人, 對用戶故事有基本的認識.
在這次的聚會中, 有人提到在合約型的專案是否可以使用 user story, 那天因為時間不多, 我沒有解釋得很清楚, 所以我特地撰文整理了一下我的想法, 大家可以一起來討論討論.
首先, 產品的產生, 過程可分成探索和交付兩個階段. 在我的認知中, 如果是合約型的專案, 在開發之前, 需求應該是已經搞定. 所以很多人認為應該用不到用戶故事. 但是, 我認為以下狀況還是可以採用用戶故事的
(1) 和用戶訪談需求階段
在合約簽訂前後, 總是會有和用戶訪談的階段, 這時候你便可以使用 user story 和 user story mapping 方法, 來了解用戶要的是什麼.
User story 是一種視覺化的方式, 將需求呈現在卡片上; 而 story mapping 則是以流程方式, 將需求結構化整理下來. 這樣雙方在溝通時, 便可以透夠這些卡片來進行對話, 先聊聊客戶想要的是什麼, 什麼是比較重要. 不用等到先寫到 word 後, 時間都花了, 才知道這些東西是否需要.
用戶故事在這個階段是在促進對話, 延遲產生細節. 當雙方有共識後, 我們再把這些東西補到文件上面, 然後再進一步討論細節. 文件不能取代對話, 文件的重點在幫助大家回憶那時候談了什麼.
(2) 專案規劃實行階段
即使是合約型的專案, 我們也可以用迭代的方式來進行. 很多人誤會迭代的做法, 只適合在範圍不固定, 或者是新創的產品. 事實上, 在範圍固定的專案也是很合適的. 你想想如果每個迭代, 團隊都能交付一些功能, 這代表團隊每段時間都些進度, 總比一些 paper milestone 的檢查方法好多了.
如果要以迭代的方法來進行, 你將會面對以下問題
a. 要選擇什麼在這個迭代中執行
b. 每個功能要做多久
c. 要把大的功能拆解才能在一個迭代中完成
要回答這些問題, 傳統的需求文件是無法做到的. 因為傳統需求文件只紀錄我們要開發的系統是什麼. 可是 user story 就不同了. 他不但促進你了解系統的需求, 他還能輔助規劃, 評估和拆解的進行.
在 sprint planning 中, 你可以很方便指出哪些 user story 要做. 在 sprint refinement 中, 你也可以針對某張 story 去做拆解的討論. 在利用 dog point 評估時, story card 也很容易讓你進行得很快.
因此, 我不覺得 user story 無法用在傳統合約型的專案. 只要知道用戶故事的用途, 你便可以自己客製化應用到你的流程中.
全站熱搜
留言列表
