“迭代期内无变更”与研发心理学（承诺管理，MosCoW方法）

作者：陈勇

出处：blog.csdn.net/cheny_com

 

迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。

反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。

只在开发层面，这个问题无解。让我们站在研发心理学的高度来看这个问题。

 

先看看如果变更了，团队会有哪些不利的心理变化。

1. 咱们不要在开始承诺能完成，一旦变化承诺就落空了

2. 既然总是在变，每次我们都预留点估算余地吧

3. 别着急，你忙也完不成的，到最后一天还给你变

4. ……

再看看Product Owner，这个变更发起人居然也发生了变化：

1. 反正日后可以变，这次计划会我就不出席了，让他们自己挑几个重要需求先做着

2. 反正日后可以变，这次计划会就先做这几个需求吧，做到一半我看看砍掉哪个

3. ……

这些变化都让我们倾向于不在迭代期内进行变更。

 

但是如果一定要变呢？

在产品版本规划（参见《“迭代期内无变更”与产品版本规划》一文）中我们应该大致圈定产品路线图及每个版本要开发的内容，若这一点做好了，我们实际可能发生的变化不过是：

1. 这个功能原来由于技术依赖，需要提前开发

2. 这个功能不是这个样子的

3. 发现了一个更好的替代功能

4. ……

对1这类技术问题而言，开发人员比较好接受，他们甚至会主动提出来。

对2、3这类问题，它本身对产品价值有所提升，是大家所共同追求的（如果开发团队还在困于“完成Sprint Backlog中的功能”而非“交付设定的客户价值”就太原始了），这时应该砍掉某些功能来达成变更实现了而承诺也实现了的双赢。

 

具体操作有这样几个要点：

1. 即使是一个迭代内的Backlog，也要有优先级，最常见的就是MosCov分类：

Must：这个迭代一定要做的

Should：这个迭代应该要做的

Could：这个迭代可以完成的（就是最后最后才做，所以随时可以准备砍掉的）

Would Not：这个迭代不做的（只做警示性展示，防止有人镀金）

2. 对每个迭代出一个愿景

如“这个迭代我们要做一个能方便快捷地展示电子节目单的机顶盒软件”。

之所以做一个愿景，就是让开发人员把目光放在价值而非Backlog中具象化的任务上，从而从心理上拥抱变更。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》