對於不斷改變的需求敏捷可以幫上什麼？

需求會一直改變，是再正常不過的事情，因此如何在需求變動中求生存，是軟體開發中最重要的事情之一。

瀑布式的作法天生就不太適合這種情況，因為它一開始需求確認後，就不太會改變。或者要震動時，召開需求變更會議，然後再走一次分析、設計、開發、測試的流程，只是不切實際，而且反應也太慢。

那在敏捷之中，又是如何來應對需求變動或是不確定呢？

基本上，是有很多方法可以幫忙，可以緩和波動所帶來的影響，但是絕對不可能用敏捷後，需求不會在外匯走勢或豐盛且清晰，這是需要先說明的。

那敏捷會出什麼招呢？

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，確認對舊的功能沒有影響，如果有影響時，也能及時修正。

本文經由作者同意後轉載
作者：David Ko
出處：https://reurl.cc/pak1eb