游戏思维与敏捷开发

Agile 是一套敏捷开发，快速持续交付可用产品的产品开发思想。我们团队最近几个月在实践敏捷开发流程，希望可以得到产能的提升。

在理论和实践中我们发现待办事项（需求）的数量质量，产品负责人(PO)和 team member 的能力，各方面都会影响最终的产出。如何高质量地交付软件产品，是每个有追求的工程师都应该思考的问题。不管对于个人还是团队，敏捷开发思想确实是一套有力的武器。

每日站会

敏捷带来改变

就我们团队实施敏捷近三个月以来，相比之前的改变还是比较明显的。

• 每周的计划会议总结上个周期的Todo/ Inprogress/Done，明确下周任务
• 每周的产能提升，bugfix 的数量提升，fix 周期缩短
• 每天站会增进沟通，分工安排每天可以进行调整

相比之前每周一次的周会，现在每天的站会可以更快速地跟进每个团队成员的工作进展和难处。以前每周或者几天才会发现某个问题卡顿在哪里，集中解决，现在每天站会中就得到关注，问题解决更快。

最近一个例子是：某个产品原型的开发迭代加快，每周可以出版本，从最开始启动项目，到可用状态，只迭代了两周，每隔两天就要Demo。这个速度我们之前很难想象，团队有3个UI，1个全栈，2个UX设计。

得益于Agile看板，我们现在可视化地管理每个团队成员在不同项目里的任务状态，人力资源。虽然之前我们也有用过 icescrum 等其他Scrum 软件，但实际上没有每天的站会，没有专门的Scrum Master 去督促大家，团队还是很难自组织地执行敏捷开发流程。应该说与之前的敏捷，目前最大的区别就是有了 Scrum Master，每天不断地提醒产品负责人和团队成员需要遵循 Agile 的规则， 并且每天的站会真的有作用！！

游戏的启发

workflow in our team

在公司的Agile培训课程中，我观察到 Throughput 和 leadtime 的概念很有趣。在一个团队和工作流中，Throughput 指的是团队总体产能（单位时间制造良品的个数）， leadtime 指的是任意时间点团队中在制品还需要花掉多少时间去做完 。实际上在小组游戏环节中，我们也注意到想达成很小的 leadtime，实际上只取决于 WIP/Throughput ，只要提高TP或者减少WIP 就可以做到很小的在制品积压。对应到软件开发中，即：

• 减少无用的、低等级的需求（或者伪需求）
• 提高开发和 fix bug 效率

减少在制品的数量，即拒绝低等级的伪需求对于团队专心做好最重要的功能 非常关键。可以让团队更专注，把重要功能 打磨到最好用，易用，稳定的状态。功能多、杂，很多时候还不如功能小而美，精细化。

比如当一个大版本要发布的之前两周，不应该留存太多的WIP来去分散团队的精力，而要关注当下正在做的，或者已经实现的产品质量，做好这部分功能，对于大版本的稳定性有很大提升

提高生产效率在我看来涉及到几个方面：

• 提高单兵作战能力，即提升团队中个人能力
• 除了个人能力，结对编程、分工合作是非常关键的，重要性甚至超越了个人能力

不知道大家玩游戏的时候，会不会觉得自己一个人玩往往会卡在某个地方？时不时需要队友合作或者竞争机制才能激发灵感和潜能。对应于软件开发，适当的结对编程对于fix bug 和解决难题是有奇效的。这一点是竞技类游戏给我们的启发。

还有就是游戏中的排行榜和积分机制，也可以引入Agile 流程中。实际上就是需要一定的激励机制，去激发团队成员的活力和能动性。比如物质奖励或者团队活动啥的。

这就是我最近关于敏捷实践的一些思考和总结。