我们团队一直在实践 Scrum，同时我对精益软件开发里面的一些思想又非常认可。 确切的说，精益软件开发是从敏捷开发思想中进一步发展而来，所以今天混在一起谈一下精益开发中的「消除浪费」和敏捷开发中的「回顾会议」。

Scrum 就不用多做介绍了，敏捷开发中非常流行的方法论之一。但是精益软件开发讨论的相对少一点，以下内容摘抄自维基百科：

精益软件开发是精益制造原则和实践在软件开发领域的变体。

和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：

• 消除浪费
• 增强学习
• 尽量延迟决定
• 尽快发布
• 下放权力
• 嵌入质量
• 全局优化

消除浪费

在我看来，精益开发除了认同敏捷开发的思想之外，最突出的就是强调了消除浪费。

为了消除浪费，首先必须能够识别、认识到浪费。如果某项活动可以被跳过或者取消也能达成最终的结果，那它就是浪费。在开发过程中作成但最终被废弃的代码是浪费；客户不经常使用的额外的处理和特性是浪费；令人员在多个任务间切换是浪费；等待其他任务是浪费；缺陷和低品质是浪费；不产生实际价值的、过度的管理也是浪费。

实际工作中这种情况其实很常见，并且往往是因为想要把事情做的更好，尤其是处于上升期的工程师。我自己也有这种阶段，恨不得把毕生所学都用在进行的项目上，却忘了团队还等着你交付产出。

这里尤其要注意的是，精益并没有将尽快发布和质量对立起来，相反的，精益强调在开发过程中就应该嵌入质量管理，认为缺陷和低品质是一种浪费。可能会有人有疑惑，快和好不是矛盾的吗？我对这一条有两层理解：第一，强调的质量是指在去掉那些浪费的功能和设计之后，提交的代码仍然应该是高质量；第二，我们允许临时用低品质的方法解决问题，但技术债要很快偿还。尤其是第二点，做到非常不容易，在我们团队尝试依靠敏捷开发来解决，每个 Sprint 都引入一个重构或优化的单子，尽早把低质量扼杀在摇篮里。一旦一个地方产生垃圾，那么大家都会往那里丢垃圾，这一点相信很多人都深有体会。

回顾会议

接下来重点谈一下让回顾会议变得更加高效的一套方法，我们称之为 Health Check Model。

回顾会议有两个非常难解决的问题，一个是大多数人都等着别人发言，很少贡献有价值的内容；另一个是每一期的话题很散，有时候重点讨论了流程却忽视了规范，有时候在一个系统的改进上讨论了很久却忘了我们这一个 Sprint 有很多单子没有完成，有很多值得改进的地方。我一直在找有什么办法可以把回顾会开的更有价值。直到有一天看到了别人在实践一套叫 Health Check Model 的方法，这个方法最早是由 Spotify 团队提出的，在我们团队实践之后感觉效果非常好，所以重点介绍一下我们目前的做法。

这套方法的流程就是提前准备好一系列要表决的内容，类似计划会打分的环节，针对每一项内容每个团队成员都要给出自己的选择。如果做的很好就给绿灯，反之就给红灯，一般就给黄灯，最后统计每种选择的数量来决定最后的结果，然后记录下来就是这样一个表格：

针对我们团队的情况，我做了几个改变。首先是把黄灯拿掉了，不给选一般的机会:D，然后通过红灯的比例来决定最终的结果，达到四分之一（包含）为黄，达到二分之一为红。另外把 Spotify 原始的几项内容做了改变，比如 Easy to Release，编写上线脚本集成到上线系统，这个是我们的基本要求，所以每周大家都给绿灯，就删掉了。但我额外增加了 Feedback，意思是有没有其他团队的人来找我们反馈问题，包括但不限于线上 Bug、数据质量、风控风险等等。

具体的每项定义如下：

• Fun，非常简单直接，自己工作的是否开心；
• Health of Codebase，代码质量，自己的或自己 Review 的；
• Learning，有没有保持学习，一般情况下敏捷开发是不关注这一项的，但我非常认可这一项。其实并不是要求大家每周都要学东西，毕竟工作不是上大学。但这一条提醒大家别忘了自己是工程师，需要不断学习保持竞争力，我们没有惩罚，但是会让小伙伴分享学到的内容。先小范围分享，如果大家觉得内容不错，会组织整个技术部再分享一次；
• Mission，是否清楚自己近期的主要任务。这很重要，没有目标每天就只有被任务推着走。我会给每个人安排和工作内容相关的，较为复杂的一个 Mission，需要自己花一个季度甚至更久来持续改进的项目；
• Pawns or Players，棋子或玩家。玩家就是说能站在需求方的角度思考问题，能主动想把事情做的更好；
• Speed，速度。不只是完成项目的速度，还包括给别人反馈的速度；
• Suitable Process，做事是否按照合适的流程。其实很多问题最后都是流程问题，比如上线的流程、开发的流程；
• Teamwork，团队合作。技术团队的合作主要是体现在 Review、技术文档等方面，所以这一项我们使用的标准是知不知道其他成员在做什么，有没有积极 Review 别人的代码；
• Feedback，反馈。前面已经解释过了，有没有人来反馈问题。

如果仔细思考一下，你会发现基本上技术团队日常工作的方方面面都考虑到了，每一项打完分该讨论的也都差不多了，如果还有没说到的问题，可以再经过一轮自由发言的补充。在这个过程中，如果有人给了和大多数人不同的颜色就必须要发言，通过这种形式也让每个人都能参与进来。

以上就是我们在实践中遇到的一些问题和对应的解决方法。