“迭代期內無變更”與研發心理學（承諾管理，MosCoW方法）

作者：陳勇

出處：blog.csdn.net/cheny_com

 

迭代期間無變更？支援派說：對，如果經常變，我們怎麼開發啊。

反對派說：不對，敏捷開發不能上來就確認了需求，要的就是在開發中逐步瞭解需求，怎麼可能不變呢。

只在開發層面，這個問題無解。讓我們站在研發心理學的高度來看這個問題。

 

先看看如果變更了，團隊會有哪些不利的心理變化。

1. 咱們不要在開始承諾能完成，一旦變化承諾就落空了

2. 既然總是在變，每次我們都預留點估算餘地吧

3. 別著急，你忙也完不成的，到最後一天還給你變

4. ……

再看看Product Owner，這個變更發起人居然也發生了變化：

1. 反正日後可以變，這次計劃會我就不出席了，讓他們自己挑幾個重要需求先做著

2. 反正日後可以變，這次計劃會就先做這幾個需求吧，做到一半我看看砍掉哪個

3. ……

這些變化都讓我們傾向於不在迭代期內進行變更。

 

但是如果一定要變呢？

在產品版本規劃（參見《“迭代期內無變更”與產品版本規劃》一文）中我們應該大致圈定產品路線圖及每個版本要開發的內容，若這一點做好了，我們實際可能發生的變化不過是：

1. 這個功能原來由於技術依賴，需要提前開發

2. 這個功能不是這個樣子的

3. 發現了一個更好的替代功能

4. ……

對1這類技術問題而言，開發人員比較好接受，他們甚至會主動提出來。

對2、3這類問題，它本身對產品價值有所提升，是大家所共同追求的（如果Team Dev還在困於“完成Sprint Backlog中的功能”而非“交付設定的客戶價值”就太原始了），這時應該砍掉某些功能來達成變更實現了而承諾也實現了的雙贏。

 

具體操作有這樣幾個要點：

1. 即使是一個迭代內的Backlog，也要有優先順序，最常見的就是MosCov分類：

Must：這個迭代一定要做的

Should：這個迭代應該要做的

Could：這個迭代可以完成的（就是最後最後才做，所以隨時可以準備砍掉的）

Would Not：這個迭代不做的（只做警示性展示，防止有人鍍金）

2. 對每個迭代出一個願景

如“這個迭代我們要做一個能方便快捷地展示電子節目單的機頂盒軟體”。

之所以做一個願景，就是讓開發人員把目光放在價值而非Backlog中具象化的任務上，從而從心理上擁抱變更。

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》