David Ko的學習之旅

前面談了不少什麼是實例化需求, 以及為什麼要實例化需求, 可是還沒有談要怎麼做. 以下是簡單的實施步驟:

1. 根據商業目標來了解系統範圍
每次做一個產品, 應該都有他的理念, 或者是要解決的問題主軸, 這些東西便會匡住產品的範圍. 像是 MVP(Minimum Viable Product) 等概念便會出現, 好讓你有聚焦, 而不是想包山包海. 這裡我們常用的工具會是像 user story mapping, 整理出要做的功能, 並且也描述哪個 milestone 要做哪些的事情.

範例:  線上購物系統一部分的 user story mapping
查詢貨物
    根據價格
    根據廠商
    根據分類
    全文檢索
購物車管理
    新增
    刪除
    修改
查詢購物記錄
    根據日期查詢
付款
    付款方式
        信用卡
        7-11 付錢
        劃撥
    折扣規則
        原價計算
        週年慶折扣
        VIP 特價
        免費送貨服務
退款
取貨
    7-11取貨
    快遞取貨

2. 一起利用關鍵的案例來具體化系統範圍
在列出要做的功能項目之後, 接下來便是要用一些範例來解釋這個東西要做什麼. 通常我們會舉行一個需求工作坊, 邀請不同角色的人來參加, 借由腦力激盪的過程, 一起思考這個功能到底是什麼, 到底要作到多少, 進而達成共識.

範例: 免費送貨服務
當 VIP客戶購買5本以上天下出版社的書籍, 就提供免費送貨
如果是非 VIP客戶,或是非購買天下出版社的書籍,就無法提供免費送貨

3. 不斷提煉來產生最後的案例
並非所有案例都是有用的, 因此需要加以選擇, 並且選擇的規則可能因時因地而異. 例如: 不需要加入 UI 操作流程, 不用產生所有排列組合, 由簡單到深入... 等等.  期待藉由每次討論, 不斷充實判斷的規則, 並且精進需求的案例.

 

4. 自動化需求的案例
當你有了案例後, 接下便要自動化它. 我們要求的是在不改變案例的格式, 逐步將它給自動化. 這樣可以確保文件和自動化是無縫銜接, 並且是同步確認彼此的正確性: 測試不過時, 就檢查是受測程式的問題, 還是文件已經過時了. 

5. 頻繁的執行
有了自動化後, 接下來最重要的事情便是不斷執行, 每天執行, 或是有修改後就執行. 因為自動化程式只要一段時間不執行, 那就會變成廢鐵, 會通通都不會通過, 因為受測程式可能已經全面翻修了.