Liangshan

Inner peace.

精益敏捷开发

我们团队一直在实践 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,反馈。前面已经解释过了,有没有人来反馈问题。

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

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

« my 2018