有时候，团队养成新习惯——编写单元测试、修复编译器警告、不破坏构建——会有些困难。我们该怎样帮助团队改掉习惯？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说到：

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

分类： 项目管理 管理工具 软件工程