用奖励制度改善团队习惯?

阅读数:334 2008 年 7 月 7 日

话题:敏捷持续集成文化 & 方法

有时候,团队养成新习惯——编写单元测试、修复编译器警告、不破坏构建——会有些困难。我们该怎样帮助团队改掉习惯?Clint Shank为此设计了一个游戏。

现在 Erik Ramfelt 已经给 Hudson 写了个“持续集成游戏插件”,它假定开发人员有时候需要被推动着做正确的事情:

我从前碰到过有人破坏构建的事情。为了避免这种事情发生,我曾经试过多种方法,比如拿一个“纳粹徽章”,谁破坏了构建就戴上它,或者每人每次罚款一英镑。但这都是消极应对。为什么不奖赏那些没有破坏构建的人呢?为什么不奖赏那些遵守了最佳实践,把工作分成小块完成,尽早检入,频繁检入的人呢?

Clint 在读过 Darin Cummins 的论文“开发游戏(The Development Game)"(于 Agile Development Conference 2004 上发表),就有了个念头,打算奖赏为构建带来好处的人,惩罚对构建造成不良影响的人。

在 Eric 的实现中,每个人的总积分由以下规则决定:

游戏的规则是:

  • 每次破坏构建扣 10 分
  • 破坏已经破坏的构建得 0 分
  • 成功构建得 1 分(不稳定的构建不得分)
  • 新的测试失败扣 1 分
  • 新的测试成功得 1 分

依赖于其他插件的规则:

  • PMD Plugin。添加 / 移除一个 HIGH 优先级的警告扣 / 得 5 分。添加 / 移除一个 MEDIUM 优先级的警告扣 / 得 3 分。添加 / 移除一个 LOW 优先级的警告扣 / 得 1 分。
  • Task Scanner Plugin。添加 / 移除一个 HIGH 优先级的任务扣 / 得 5 分。添加 / 移除一个 MEDIUM 优先级的任务扣 / 得 3 分。添加 / 移除一个 LOW 优先级的任务扣 / 得 1 分。
  • Warnings Plugin。添加 / 移除一个编译器警告扣 / 得 1 分。
  • ...

Clint 警告说,你必须要注意那些出千的(每小时检入一些细小琐碎的、无意义的东西),而且要常常重置积分,让每个人都有机会胜利。

Scrum Development讨论组中有一些其他想法。Graeme Matthew 指出,如果奖赏太重,那么开发人员可能就会把注意力放到提高积分上面,而不是给客户交付价值。Ilja Preuss 说:

另外一点要牢记的就是,外在动机常常都是跟内在动机严重冲突的。也就是说,如果你的团队已经具备了良好的内在驱动力,那么加上外部驱动只会让事情变得更糟。

最后 Pete Deemer 说到:

我觉得这种个体激励的复杂框架会鼓励大家多思考“自己”,进而对“整体”造成无意中的损害。它会在微观上进行优化,但这种结果从宏观上来看却是次优的;而且人们会精打细算,做很多形式上的工作,而不是为客户服务。

查看英文原文Rewards to Improve Team Habits?