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