繼昨天跟大家討論說如何讓 Member 多了解一些專案的願景以及多體驗一點 PO 的心酸
在這想跟諸君聊聊，何謂好的需求變更

回應變化重於遵循計劃

敏捷宣言 這個東西很神奇，雖然只有短短的不到十行字，但在不同階段回過頭來看時，
都會有不一樣的體悟與感觸

或許很多人會認為 敏捷式開發 就是要應付 user 的善變，所以很敏捷
但我認為回應變化不是等於全盤接受
要事出有因才行，在開發單位與需求單位中間取得平衡
以下舉幾個範例

1.開發到一半，忽然接到說要更改

我將此類型歸類為停止開發，等待下次 Sprint 再開發
因為通常遇到這類型的異動，也就證明當初規劃有誤，需要重新討論取得共識。
所以這時候就要請 Member 暫停下這張單的開發，先去領別張單
改由 PO 去釐清需求異動的幅度

根據過往經驗，要有良好的開發品質與體驗，這類型的單排到下次 Sprint 進行會好很多。

2.Review 會議上提出的小改動

字可以往上移一點嗎？再左邊一點點。多了多了再回來一點。好～停！

至於這種類型的異動，我比較習慣統稱為人情異動。
是否在上線前進行此調整，完全取決於提出這個的 stakeholder
他跟開發團隊的交情如何～
還不錯的話就幫忙改一改吧

這種類型的異動再導入設計圖後大幅降低頻率

3.Review 會議上提出的大改動

那不小的改動該如何處理呢？
在此我會秉持著最小可行性產品(MVP) 的概念來去說服使用者
不影響功能的前提下，先將可以使用的產品投入市場，進而收集市場反饋來持續優化

如果 stakeholder 還是不買單的情況
就交給市場來決定吧，配合一些 a/b test 的方式，來去驗證哪個方法比較好。

So Whose call now?
Stakeholder? Product Owner?

Data Louder! (Maybe CEO loudest)

也就是讓數據來說話

回應變化重於遵循計劃

在我眼裡，我該面對的是回應 市場 的變化。
借助 Stakeholder 在相關領域專業的力量，
一起維護我們大家的專案。
當今天能有這樣的共情與原則下，相信開發團隊也能擁抱變化

啊!忘記提到
面對交情不好的 stakeholder 所提出的那些小改動...
就直接上線吧，他們大概也不會發現那些字最後竟然沒有往左上移動一點

參考資料：

1. 敏捷軟體開發宣言_中文版