2、尽早发现问题,解决问题

  “需求细分,及时开发,及时验证”——将需求拆分成端到端可测试的需求(即“用户故事”),这些需求一般可在3天内完成。在实现每个需求之前,开发人员与测试人员进行充分沟通,对需求与验收条件达成共识。每开发完成一个用户故事,进行测试,并用自动化测试进行覆盖。

  “主干开发,分支提测”——将原来的多个分支进行合并,统一在主干上开发,每周结束时拉出一个分支,进行提测,一旦发现问题,在主干上修复。

  “持续集成”——为了确保每次提交质量,对主干开发建立持续集成环境,开发人员和自动化测试人员都严格遵守持续集成纪律“Check-in Dance”。

  新的开发流程如下图所示。

  分支开发策略变更为Single Branch模式。

  五、小结

  通过以上改进措施,让团队的合作方式发生了重大变化,从“碉堡防御”走向了“战线统一”。

  原来,各角色仅关注于自己本身的工作,虽然大家都同处于一个项目中,但各自划分了“领地”,产品经理应该将MRD写得清清楚楚,如果开发人员认为不清楚,那回去再改。开发人员只管按照MRD上的内容进行开发,很少考虑可测性和易测性问题。测试人员只管按照MRD中内容来测试,有问题通过内部工作流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的“交付物”。

  现在,各角色都能够共同合作,以项目的终交付为目标,积极讨论需求,优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。开发人员耐心为产品经理解释技术实现,说明计划安排,测试人员与开发人员共同讨论验收条件,避免遗漏需求。开发人员让运维人员了解架构设计, 细心听取运维人员的建议,进行技术改造,使部署工作更快捷有效。

  通过这些活动,大家都认识到原有内部管理平台仅是个公文流转的支撑平台,要想提高工作效率,要将这种“办公自动化工具”进一步提升为“全面自动化工具”,使所有人更关注于端到端的价值,而非各角色之间的分界点。

  六、结束语

  百度刚刚开始敏捷之旅,还没人谈及“DevOps”运动,虽然还没有什么强大的工具支撑,但基于“提高效率”的朴素思想进行的过程改进也带来了“DevOps”效果。可见,DevOps听上去很神秘,但其实并不难。只要本着精益思想,聚焦于快速交付价值,不断发现并消除浪费,你也一定会有很大收获。

  本文出自:http://www.infoq.com/cn/articles/devops-not-legend/