有时候，团队养成新习惯——编写单元测试、修复编译器警告、不破坏构建——会有些困难。我们该怎样帮助团队改掉习惯？ 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?
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论