最近開始在研究實例化需求(http://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084), 開始帶領團隊看書和練習. 我們志不在自動化, 而是確認如何落實這樣的觀念到專案中, 了解要如何實際應用, 並且確保是有效果的.
昨天進行了一場需求工作坊, 我把一些事情記錄下, 以供後面持續改進.
進行流程
1. 主持人講解規則, 和解釋今天要討論的需求項目是什麼
2. 請大家利用便利貼列出想到的需求
3. 大家在過程中適時將所列出來的項目分群
4. 主持人會逐一解釋大家所列出來的項目
5. 主持人總結今天結果和之後待辦事項
注意事項
1. 需要多次的討論
第一次通常是針對比較 high level 的範圍限訂定, 然後再逐漸對每個大項在進行逐一討論. 此外有些項目因為一開始不佳不見得都清楚, 因此需要有人負責研究來進一步列出細項.
2. 找到對的人來討論很重要
要找的人是需要對這個功能是有了解的, 如果大家都不太懂的話, 需要有另個會議來介紹一項背景知識.
3. 要找不同角色的人參加
需要找相關的 RD, QA, UI designer, architect 和經理來討論, 讓大家可以從不同的角度來思考, 以確保需求的完整性
4. 案例要具體化, 但是不需要列出所有細節的組合
實例化需求的想法就是想用範例和測試個案來描述需求, 以讓大家對於這個需求想要做什麼, 可以有很明確和很一致的看法.
這裡目前我們只能儘量列的比較明確, 至於多明確可能目前還沒有準則, 至少先確認大家同意並且有共同的了解. 打算在這個過程中, 逐漸把這個準則給整理出來.
5. 會有問題區等待會後釐清
有些項目可能在當下沒有主意要不要做, 必須要把這些項目先列出來, 不需要在這個會議中討論, 避免花時間討論太多不確定的事情.
6. 要有人整理待辦事項
在這個會議完後, 大家基本上認可這樣的會議, 因為在專案早期時需求是很不確定, 並且也無法一直等待上層主管把需求確定, 或許這是一種方法, 借由團隊的力量來界定出要做什麼, 並且是大家來有共識的狀況下達成.
留言列表
