精选 | DevOps 三十六计之精益敏捷与持续交付

前言：

“一册在手，DevOps我有”，这就是传说中的《DevOps 三十六计》，相信您读完也意犹未尽，小编就来和您说道说道我注解的《DevOps 三十六计》，今天先跟大家聊聊精益敏捷和持续交付，从中摘取何勉、杨晓俊、张乐三位老师的计策，跟聊聊您！

精益敏捷篇

精益产品开发（何勉）

1. 寻求在问题域将需求拆分成可流动和交付的子需求，避免过早在实现域拆分任务
   我们做产品研发时，最容易犯的错误就是需求还没有理解透彻就开始思考实现，具体怎么在问题域将需求拆分，需要你系统的阅读何老师的新书《精益产品开发 原则、方法与实施》。

2. 系统组织拆分后的需求。用户故事地图是组织和规划需求的好工具
   用户故事以用户的角度描述需求，替代原来的功能性描述，增加团队对用户、对价值的关注和理解。但是用户故事对于优先级、故事场景（线索）的体现并不好，所以发展出用户故事地图这样的实践与工具，帮助我们梳理将用户故事变成一本精彩的“小说”！

3. 可视化价值流动而非任务，以促进团队协作，并系统改进价值交付过程
   何老师将精益看板划分为三个层次：任务状态看板、价值流动看板、持续改进看板。看板最基础的价值就是满足我们可视化工作流的需求，然后看板要能帮助团队明确流程规则和限制在制品数量，这样的看板才算是真正的看板。
   在何老师的实践中，看板还需要追求更高级的目标：管理价值流动和帮助持续改进。

4. 控制在制品，减少同一时刻并行需求的数量，以加速价值交付，并暴露瓶颈和问题
   控制在制品，这是大多数实践看板的团队所面临的最大难关。既要转变工作不饱和的恐慌思维，又要切实控制住WIP。

PS，何老师出新书了，《精益产品开发 原则、方法与实施》不只有36条计策，更多精彩尽在其中

敏捷项目管理（杨晓俊）

1. 没有照本宣科的敏捷，只有最适合团队的实践
   敏捷的本质就是在实践中探寻更好的软件开发方法，所以实践敏捷需要我们去找到最适合自己的实践和方法。

2. 好的架构是演化出来的，而不是一开始就设计出来的
   这个在传统瀑布模式下最常见，总是花好几周的时间设计架构，考虑各自高可用、安全等场景，可惜往往很多项目都没有熬到上线就胎死腹中。架构师演化出来的，这是敏捷研发中的铁律。

3. 需求卡（Story Card）最好能够写明目标用户、用户的场景以及用户的目的或需求本质
   需求卡片，以用户故事的表达方式，清晰的告诉所有人团队成员（产品、开发、测试，甚至业务运维）需求的内容是什么。同时在需求卡片上写清楚验收条件也是非常好的实践。

持续交付篇

持续集成（张乐）

1. 开发人员每天至少向版本库提交一次代码
   在Martin Fowler的持续集成测试中，第一条就是“开发人员每天至少向版本库提交一次代码”。

   
   只有开发人员每天至少向版本库（主干）提交一次，才能避免出现复杂的合并与集成，主干的质量才能持续得到保障

2. 每次变更都执行构建，以便尽早发现缺陷
   持续集成解释就是持续地集成（构建），何为持续？原来我们都是DailyBuild，每天做一次。现在随着技术的发展，架构的解耦。每一次提交（变更）都能进行构建，这样才能保证代码始终处在可构建的状态。
   这里的构建至少包含了编译、单元测试。

3. 将DDL和DML脚本提交到版本库，以便使用脚本重建数据库和测试数据
   数据库的持续集成一直都是难题，使用版本控制系统管理DDL和DML是第一步，这样才能建立起应用和数据的版本关系，可以自动完成数据库重建和测试数据的生成。
   尤其是在搭建测试环境中，数据库搭建和数据导入往往需要花费测试工程师很多时间，自动化该过程并纳入到持续集成（持续交付）流程中，是非常好的实践

持续部署（张乐）

1. 避免手工部署软件

2. 避免手工对生产环境进行配置
   手工部署软件和手工配置生产环境是持续交付的典型反模式。这里可以尝试使用两个实践：基础设施即代码和不可变基础设施。
   基础设施即代码，在大家使用类似Ansible等自动化配置（部署）工具时将环境的配置（状态）都采用代码（比如YAML）的方式进行定义，由于自动化配置工具幂等性的特点，可以保障环境的状态和我们定义的状态保持一致。
   不可变基础设施，主要是在使用Docker时，不允许修改容器配置，每次部署都是重新启一个新容器。环境只可以被替换，不可以被修改，这和虚拟机的使用有很大的不同。

3. 避免开发完成之后才向类生产环境部署
   相信你已经听过或者说过：“在我机器上没问题啊，是你环境的问题吧！”，将DTAP环境（开发、测试、预发布、生产环境）都纳入到持续交付流程，才能保证代码能尽快在类生产环境中进行部署和验证，软件要运行，需要应用、应用配置、数据、环境及配置等都正确，尽快在类生产环境进行验证可以有效避免环境差异的问题。

4. 交付过程是每个程序员的责任
   DevOps非常强调文化和协作，在DevOps的文化模型中，责任共担是核心文化，交付过程是每个开发工程师、测试工程师、运维工程师的共同责任。
   

DevOps 三十六计除了精益敏捷和持续交付，还有安全篇、性能调优篇、开发架构篇、测试技术篇、技术运营篇，每一篇又分多个计策！
欲知详情，且听下回分解！

END

近期好文：

想 get 更多新技能？

你需要一本《DevOps 三十六计》

快来 DevOpsDays 上海站，V1.0版本的 《DevOps 三十六计》现场赠阅！

了解更多大会内容及抢票请进官网：

长按二维码 报名参会

购票咨询及团购优惠请联系主办方：

Tel：[phone]

点击阅读原文关注活动官网