在敏捷開發中, 需求是否要一開始就要齊全呢? 當然不是這樣的, 沒有人能一開始就可寫出所有事情的. 即使你想要這樣做, 所花費的時間可能也會超出你想像的久. 所以在 agile 中, 需求是逐步演進的.
這樣的想法, 我想大多數的人是可以接受的, 但是大家會問那要怎麼做呢? 讓我們一步步道來.
1. 需求產生階段
當 PM 有個想法, 或者是收到使用者有個困難時, 我們可以先把這個項目記錄起來, 並且可以加些敘述來說明. 這時候重點只是先記錄下來. 並且並沒有答應 PM 或是使用者說我們一定要做它.
2. 需求解法思考階段
在這個階段中, 我們開始對需求討論, 釐清他背後遇到的問題, 或是發生的情境為何, 也就是了解問題的 context.
然後我們接著會開始思考解決方法, 這裡我們並不是要細部的設計, 我們想要的是 high level 的設計. 這時候我們常用的手法會是 prototype, sketch, 來了解大致有哪些事情要處理, 系統外顯行為會怎樣運作.
有了這些之後, 我們會先跟 PM 或是使用者確認解法的正確性, 避免一開始方向就有很大的偏差. 如果沒有問題, 我們會開始評估時程(可能用 playing poker), 然後才跟 PM 或是使用者說我們大致什麼時候會交付.
3. 需求實作階段
因為要開工了, 所以一切都要很清楚. 當需求開始要實作時, 要重新再檢視解法, 確保所有細節都正確, 並且對於任何例外處理都需要談談.
這時候你才需要用力寫詳細的文件, 因為要記錄設計考量, 各種組合變化方式, 好讓開發人員可以照表操課, 也讓測試人員能有所本來驗收成果.
4. 需求發佈階段
這時候需求已經發佈了, 使用者會開始使用它, 好用, 就會接受它, 會接著要求你加強. 不好用, 要不之後不再用, 或是提出新的需求. 但是不管怎樣, 結果都是會有新的需求提出, 這時候就又回到第一步, 你也不用在這時候對這個新的需求用力討論.
從這四個階段, 大致上可以知道敏捷對需求的處理是漸進的, 從只是記錄開始, 然後勾勒出輪廓, 到實作階段才展開到最詳細.
那為什麼要這樣做呢? 主要可以帶來以下好處:
1. 延遲決定
有時候一開始的需求只是想法, 很多資訊還不充足, 如果那時候就說要做, 或者要什麼時候給客戶, 這樣的決定都太草率, 到時候只是你忽然發現有太多意外, 並且還讓客戶覺得你不守信用而已.
2. 避免浪費
一開始就寫很詳細的需求, 可是真的等到要做時, 可能是一個月或是半個月後, 那時候原先對的東西, 或許可能已經不正確. 或者是你也可能忘了那是什麼, 還要花時間再來溫習一次, 這些都是一種浪費.
3. 有機會集體討論
在解法思考階段, 可以讓要做這個功能的相關角色, 如 PM, 開發人員, 設計人員, 測試人員, 利用 design studio 等方式, 一起來對功能討論, 不但可以讓大家知道 spec 是什麼, 也避免思慮不周密.
所以, 以前 waterfall 處理需求是希望一刀斃命, 而敏捷是慢慢凌遲處死 (誤), 哈哈 ….
留言列表
