“迭代期内无变更”与研发心理学(承诺管理,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中具象化的任务上,从而从心理上拥抱变更。

 

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

 

posted @ 2011-03-10 10:29  Java EE  阅读(185)  评论(0编辑  收藏  举报