需求會一直改變, 是再正常不過的事情, 因此如何在需求變動中求生存, 是軟體開發中最重要的事情之一.
waterfall 的作法天生不太適合這個狀況, 因為它一開始需求確認後, 就不太會變. 或者要變動時, 澳召開需求變更會議, 然後再走一次分析, 設計, 開發, 測試的流程. 不但不切實際, 並且反應也太慢.
那在敏捷之中, 又是如何來應對需求變動或是不確定呢?
基本上, 他是有很多方法可以幫忙, 可以緩和變動所帶來的影響, 但是絕對不可能用了敏捷後, 需求就不會不變動, 或是就不會完全很清楚. 這點是需要先說明的.
那敏捷會出什麼招呢?
(1) 客戶要全程參與
在敏捷開發中, Scrum 相關會議 (ex sprint review, sprint refinement) 都會邀請客戶參與. 如果團隊有任何跟需求有關問題, 團隊成員要能直接找客戶確認, 並且將結果和 Product Owner 對齊.
(2) 利用 story mapping 鳥瞰全局
利用 story mapping 知道需求的全貌為何. 哪些部分比較重要, 哪些部分需要先做. 這部分不是一開始訂了就不變, 而是讓客戶和開發有共同的想像. 在執行過程中, 會依實際狀況來調整, 並且相互通知.
(3) 週期性召開需求釐清會議 (refinement) 觀看未來的需求
會利用 refinement meeting, 來看下 1-2 個迭代要處理的需求的細節. 可以避免一次看太多, 可是後面改變導致浪費. 並且當有改變時, 也可以在這個會議中提出, 及時調整需求順序和內容
(4) 在迭代規劃會議專注目前的需求
在每次 sprint planning 中, 會專注這個迭代要處理的需求. 讓團隊成員的專注力, 不會去看太大的範圍. 萬一有急件插入, 也可以在這個會議中提出調整
(5) 利用範例及早確認需求的 驗收標準
在 sprint planning 和 refinement meeting 中, 會利用範例來描述要處理的需求是什麼, 這些範例會由客戶和開發雙方提出和確認, 以減低雙方對需求的誤解.
(6) 每日立會即時確認需求
在 daily scrum 中, 如果對於需求有任何問題, 可以即時反應. Product owner 可以幫忙回答, 或者及時去找戶確認.
(7) 在檢視會議中確認已完成的需求
當需求被完成時, 可以在 review meeting 中邀請客戶參與展示, 這時候客戶對於已完成的需求可以給回饋, 然後開發團隊可以在下個或是之後迭代調整.
(8) 利用持續整合確認舊有需求的正確性
敏捷團隊可以利用 continuous integration, 當有 code check-in 時, 利用 自動化的 smoke test, 確認對舊的功能沒有影響. 如果有影響時, 也能及時修正.
文章標籤
全站熱搜
留言列表
