读《持续交付2.0》
几年前看过《持续交付(发布可靠软件的系统方法)》,感触不是很深,最近看了这本书的译者乔梁编写的《持续交付2.0》,结合工作中的种种,又有一种相见恨晚的感觉。可见好书是需要经常翻阅的,每次都会带来新的收获和思考。
全书围绕着双环模型展开,介绍了持续交付,快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。
双环模型
- 第一个环被称为探索环,主要就是搞清楚客户背后真实的业务目的,不只是要实现什么,怎么实现,而是要了解背后真正的原因,才能给出更合理的解决方案,通过沟通讨论出一个最小的可验证方案,以便能快速验证可行性,探索环也是持续交付2.0中新增的一个环
- 第二个环被称为验证环,验证环的主要工作内容就是以最可靠的质量和最快的速度,将最小可行性解决方案从描述性语言转换成可运行的软件包,并将其部署到生产环境中运行。
信息偏差
即便是再熟悉,再有默契的人,沟通同一个事物的时候也会产生理解上的偏差。我觉得在探索环中需要做到信息的一致性,即便不能完全一致,后面的验证环也能快速出成果给客户确认,因为足够小,可以及时地调整方向,把风险降到最低。
信息偏差不止是客户和我们之间,在团队内部也经常会出现,我们在安排任务时不管是口头描述还是有详细的文档,总会出现结果和期望有偏差的情况。樊登讲过的日本企业交代任务的方式我觉得可以尝试一下:
- 1、交代清楚事项
- 2、让员工复述一遍(有的软件公司成为反向交底)
- 3、和员工讨论做此事的目的
- 4、让员工考虑有没有什么风险
- 5、要求员工提出个人见解
看似很麻烦,但可以确保双方的想法能达到一致,减少后续返工的风险,其实就是磨刀不误砍柴工。
开发软件的目的是创造客户价值,所以,我们不应该仅仅关注快速开发软件功能,还应该关注我们所交付的软件的功能正确性。
流水线工作方式
双环中有很多的步骤,每个步骤环环相扣,从探索环业务需求的输入到验证环产出可以运行到成果,这是一个闭环,这个闭环的周期越短风险就会越小。从输入到输出,整个流程像流水线一样运转时,效率是最高的。就像敏捷中的看板文化一样,随着时间的推移,一个个的用户故事从最左边逐步移动到最右边。如果中间某个环境出现堆积或者断层,都说明可能出现问题了,需要停下来解决。
最近一个项目中需要做数据迁移,由于数据量和迁移的范围非常大,项目经理召集了公司很多其他项目组成员进行协助,项目经理按照自己熟悉的技术规划了迁移方式,学习成本比较高,对于初级开发或测试人员来说,短时间内很难上手,导致进度缓慢。
后来我们领导提出了更合理的方式,就是将迁移任务根据技术的难易程度分解成了几个大的步骤,各种水平的人都有事可做,并可以很快上手,最终高效完成了任务,这就是流水线效率的体现。
聚焦
书中讲到了四大原则:
- 坚持少做
- 持续分解问题
- 坚持快速反馈
- 持续改进并衡量
四个原则概括下就是要「聚焦」,特别是在时间紧任务重的情况下,更是要聚焦,只有聚焦了,双环模型的周期才会缩短。
案例一
最近团队有几个同事在开发一个独立的类邮件模块,功能涉及到收发邮件、删除邮件、收藏等功能。客户第一阶段关注的是,先要有这样一个功能模块,功能可以后面完善。聚焦的做法就是,快速完成邮件的收发功能,在交付期前有多的时间再完善删除邮件、收藏等功能。到了交付期,删除和收藏功能没有完成,不影响我收发功能的发布。
如果一开始将收发、收藏、删除等同时并行在做,可能到了最后时间,每个功能点都完成了一部分,但却不能交付客户。
案例二
我们开发的产品是一个功能强大的快速搭建平台,最近一客户使用我们平台来搭建业务功能,上线时间非常紧迫,这时就应该聚焦有哪些必须(阻碍业务)的功能目前还不能实现,利用探索环提交到产品团队,讨论出最小可行解决方案,然后在验证环快速出成果交付客户验证。
这时如果客户关注点在平台的非核心功能(主业务无关),提出各种优化需求和新增需求,这样就本末倒置了,最终上线会有极大的风险。
安灯(Andon)系统
「Andon」是一个信号灯,丰田公司要求员工,在生产流水线上遇到麻烦,都可以拉这个信号灯,生产线会立即停下来,直到问题解决,流水线才恢复运行,不让问题流到下一个环节。
安灯系统最重要的是让每一个员工都有质量意识,软件开发团队的中的成员往往就缺少这种意识,为了能早点完成任务,常常忘记完成这些任务的最终目的。
在这里分享一个小故事:
说有一人在路边看见地里有两人,一个人在前面挖坑,后面的人又用土把挖的坑埋上,由于好奇和不解,上前询问,两人回答,他们在种树,只不过负责放树苗的人今天请假没来。
从本职工作来说两人都完成的挺好,但没有价值。仔细想想一想,我们有时候是不是就像上面挖坑的人或是填坑的人一样?所以团队的每个人都应该为结果负责,都要能在适当的时候勇敢地拉下这个信号灯。
工具
持续交付在实践过程中离不开自动化工具,大体可以分为自动化构建和自动化测试。
自动化构建
不同大小的公司,或者处于不同阶段的团队,会采取不同的工具,适合自己的才是最好的,之前写过的几篇文章可以给大家参考:
1、GitLab 配合 Jenkins 打造自动化部署
2、在团队中使用 Gitlab 中的 Merge Request 工作模式
3、在 CentOS7 中安装 GitLab
4、敏捷下的需求和代码分支管理
5、不断进化的分支和需求管理
在上面的文章中有介绍我们是采用 GitLab 的 Merge Request 模式,对应到书中的分支策略,就是是主干开发,主干发布,因为每一个 Merge Request 分支的周期非常短,最终还是合并到主分支进行构建发布。但这种方式有一个问题,当同时并行任务过多时,合并时容易混乱。后面会尝试主干开发,分支发布的方式。
自动化测试
自动化测试大体可以分为单元测试和端到端测试,单元测试对开发人员的要求比较高,要保证持续交付高质量的产品,单元测试非常重要,我们现在也在规划和完善。
端到端测试目前已经在使用中,在之前的文章《端到端测试实践:Jenkins 集成TestCafe 》有所介绍。
总结
持续集成2.0这本书中有很多的干货,本文我只是找了几个我认为比较重要的点进行了描述,总之就一个目的,我们要快速地、准确地、高质量地把任务完成,并交付客户。
![](https://images.cnblogs.com/cnblogs_com/oec2003/219566/o_qrcode_for_gh_1a8c0bee3c6c_344.jpg)
作者: oec2003
出处: http://oec2003.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接,否则 保留追究法律责任的权利。