使用DevOps强化敏捷（下）

做者 | Christopher Lee&Sean D. Mack

若是您曾经对敏捷或DevOps的历史、结构、原则或共性有过疑问，那么您将在这篇文里找到答案，本文被拆分两篇，上篇《使用DevOps强化敏捷（上）》主要介绍敏捷和DevOps的历史、差别和好处，本篇主要介绍敏捷和DevOps的几个共性。

敏捷和DevOps的目标是一致的，所以在实践过程当中会发现它们有所重叠。在许多方面，DevOps和敏捷的交叉关系到协做文化以及从这种文化中产生的现代技术实践和过程。

协做文化

敏捷和DevOps之间的核心共性之一是他们都强调打造协做文化。这两种方法都着眼于打破壁垒，增长成员共同责任感。经过打破隔离，DevOps和Agile减小了交接，提升了向客户交付的速度。DevOps将这种协做概念扩展到了运维团队中，而敏捷关注QA是否包含在内。

在敏捷中，咱们看到协做文化直接融入到了敏捷宣言的核心原则中。第一个定义“我的和交互重于流程和工具”明显地表达了合做的须要。此外，第三个原则，“客户协做重于合同谈判”，强调须要将这种协做扩展到开发团队以外，也扩展到客户当中。

敏捷教练Susan McIntosh在她的文章《敏捷心态究竟是什么》中提到，“敏捷心态是一种支持敏捷工做环境的态度。其中包括尊重、协做、改进和学习反馈、对归属的自豪感、专一于提供价值以及适应变化的能力。这种心态对于培养高绩效团队是必要的，而这些团队反过来又为客户带来了惊人的价值。”

在敏捷中有许多协做的例子，诸如结对编程、Mob编程和Swarming等实践都容许更大的团队合做开发软件，虽然这与开发的原概念相悖（开发本来是指由一个单独的程序员单独完成的任务）。此外，敏捷工做还将QA无缝连接到流程中，做为团队任务的一部分。RonLichty表示：“我将经过Scrum中的产品全部者角色将产品管理集成到团队中。PdMs向开发人员“越过墙”抛出需求的历史由来已久，这与开发人员向测试人员“越过墙”抛出代码的历史没有太大不一样！”RonJeffries写了他在极限编程中处理故事的方法。Atlassian建议经过使用单页仪表板缩小PRD（产品需求文档）来保持需求的精简。

DevOps的许多基本概念也是围绕协做的概念构建的。事实上，这个能够追溯到早先反对将开发、运维和QA分割之时。DevOps运动的基础之一，正是人们认识到开发、运维和QA彼此独立会致使利益冲突、增长交接成本。

Thoughtworks的首席科学家Martin Fowler指出协做在DevOps中扮演重要角色，他认为，“DevOps文化的主要特征是增长了开发和运维角色之间的协做……开发和运维之间不该该存在壁垒。”和从一开始就一块儿工做解决问题相比，切换周期和文档是一个糟糕的替代品。调整资源结构，使运维人员可以尽早参与到团队中来是颇有帮助的。

另外，创建协做文化的一个关键方法是在全部参与交付的团队之间制定共同的目标。使开发、运维和QA之间在明确的目标上保持一致，并将重点放在客户需求和最终交付上。

DevOps鼓励协做的另外一种方式是将运维活动集成到Sprint中。这能够经过在Sprint中加入运维团队成员来实现，甚至更好的方法是，将运维职责分给全部Sprint团队成员。

除了交付特性和“功能”以外，在高性能的DevOps组织中，一般还向交付产品的团队提供维护这些产品的职责。一旦系统的稳定性获得证实，它就会移交给另外一个团队进行维护。其余公司包括开发团队，做为操做问题的寻呼机轮换的一部分。这就产生了共同的责任，并增强了共同的目标和责任。

固然，DevOps不是一份工做，它不是一个角色，也不是任何一我的或团队的责任。DevOps的核心是协做，这与敏捷宣言中的原则保持一致。

小批量、短周期

小批量和短周期是敏捷化的关键。经过减小对系统的更改，敏捷能够更快地为客户带来价值。这种快速部署能带来快速反馈，客户或用户能够快速查看已开发的内容，团队能在必要时快速调整路线。这与瀑布式方法造成了鲜明的对比，在瀑布式方法中，客户可能要等上几个月甚至几年才能看到交付成果，只有到那时才能肯定产品是他们所想的仍是所要的。DevOps采用小批量的概念，并经过持续集成和持续部署（CI/CD）对其进行扩展。CI/CD提供的工具链加速团队对客户的价值，将周期从几周缩短到几天甚至几小时。

小批量是精益的关键。起源于20世纪30年代的精益为敏捷和开发人员提供了一些核心基础，它专一于消除浪费和减小批量，减小正在处理的工做量，从而减小等待下一个阶段处理的库存量。

这一律念与敏捷的核心原则相呼应，敏捷的核心原则规定“常常交付产品，从几周到几个月，优先选择较短的时间段。”小批量和较短的周期时间有不少好处。根据DonReinersen的说法，为了让产品开发增长价值，结果必然会有不肯定性。咱们不该该试图最小化失败，而应该接受可变性。咱们能够经过有效地学习和高效地生成信息来减小不肯定性。VirtualCTO官诺亚•坎特（Noah Cantor）强调了短反馈循环的影响，“有不少学术研究和行业研究代表，反馈周期越长，人们从中学习的知识就越少。反之亦然——反馈周期越短，人们能够从中学习的越多。”

有不少方法能够确保你在敏捷中拥有小批量和较短的周期时间。最基本的方法之一是将用户故事分割成适合迭代的片断。减小故事的规模不少，好比将功能拆分为单个用户故事或任务等。

当划分和拆分用户故事时，重要的是确保您不建立合成型团队，而是坚持使用功能团队。垂直而不是水平地拆分用户故事。也就是说，观察端到端的特性，而不是应用程序的特定层。

小批量和短周期也是DevOps的关键。DevOps的重点是从左到右增长产品流。经过使用精益的工具（如价值流图），能够识别瓶颈并消除它们，从而增长对客户的价值流。

此外，较短的循环时间是DevOps第二和第三种方法的关键。与敏捷同样，更短的周期意味着价值能更快地传递给客户，所以团队能够更快地得到反馈，以便能快速向客户发布特性或更改，并根据反馈快速调整。

DevOps中缩短循环时间和I迭代周期的关键之一是持续集成（CI）和持续部署（CD）。经过持续的集成，一些更改会不断地被合并和验证，从而使整个产品始终具备潜在的可交付性。而持续部署会确保产品始终处于可部署状态，容许随时向客户交付价值。这两个实践采用了敏捷方法中最初引入的快速开发和交付，并将其周期进一步减小到天天甚至每小时。

工做可视化

可视化是DevOps和敏捷中的另外一个关键元素。对于像Scrum和看板这样的敏捷实践，一般采用板的形式来共享信息。DevOps利用并进一步扩展了这些方法，来共享系统在某一特定时间内的执行状况，这能够经过大型可视仪表盘和共享仪表盘的形式等展示。

虽然敏捷宣言并无规定工做可视化的必要性，可是概念是实践的基础。宣言强调“我的和交互重于流程和工具”和“客户协做重于合同谈判”以及“响应变化重于遵循计划”，这三个方面都能经过工做可视化而获得增强。

敏捷促成了“信息辐射源”概念的发展，这是一种位于敏捷开发团队附近的大型图表，能显示整个开发周期的工做进展。Alistair Cockburn在2000年创造了“信息辐射源”这个术语，并在他2001年出版的《敏捷软件开发》一书中作了介绍。

工做可视化能直接暴露出时间的缺漏，以优化工做和流程。经过为团队提供可视化工做的方法，使团队可以一块儿工做更加方便，这些板还帮助快速识别瓶颈。

DevOps的第二种方法集中于加强反馈和共享操做信息，这是一种很好的方法。这能够包括Scrum板，也能够包括关于系统性能、用户体验以及代码和基础结构性能的实时数据。这些信息图表就像在整个建筑的战略位置张贴的大型监视器。

在DevOps手册中，做者还用了整整一章的篇幅来讨论遥测的问题。他们在他们的“建立遥测技术以发现和解决问题”一章中写道，“咱们的目标是将这些信息辐射到组织的其余部门，确保任何想要咱们正在运行的任何服务的信息的人都能得到这些信息……使价值流中的每一个人均可以实时共享信息和提出观点。”

Etsy是一家以DevOps思想领导能力闻名的工艺电子商务公司，在工做可视化的领域也作了不少工做。“若是Etsy的工程有宗教信仰，那就是图形教会。”Patrick McDonnell在DevOps手册中谈到了监控部署数据的好处，他说：“经过这样作，咱们能够更快地看到任何意外的部署反作用。咱们甚至开始在办公室周围安装电视屏幕，以便每一个人都能看到咱们的服务表现。”

持续学习

敏捷和开发人员的核心原则中都有持续学习。在敏捷中，这个概念是敏捷宣言的一部分，在DevOps中，它是DevOps的第三种方法的一部分。

敏捷宣言强调“响应变化而不是遵循计划”，所以，它构建了一个强调适应需求的原则。在这种适应性中，假设团队不断的反思和改进，在持续的敏捷短周期中，团队便可以审查事情的进展状况，并对他们交付的产品和交付过程进行快速调整。此外，“客户协做重于合同谈判”的宣言宗旨意味着严格的反馈循环、倾听和从客户反馈中学习。在敏捷中，产品团队能够快速地向客户交付功能，并快速地从实际反馈中学习和快速调整。

DevOps也强调持续学习，其第三种方法便聚焦于此。在IT革命网站上，Kim写道：“DevOps第三种方法是创造一种能促进两件事的文化：一是持续实践、冒险和从失败中学习；二是理解重复和实践是精通某件事的先决条件。”

同时，敏捷和DevOps都把不断学习和不断实验的精神付诸实践。在Scrum中，有被置于流程中的回顾会，用以确保团队花时间对每一次迭代进行反思、从错误中学习并总结成功的经验。回顾会是团队对前一次迭代进行反思并寻找改进的会议，小组成员会讨论哪些进展顺利，哪些进展不顺利，并列举须要改进的方面。

Sprint演示是敏捷流程中持续学习的另外一个很好的例子。许多敏捷团队会在每次迭代结束时对Sprint可交付成果进行演示，这样可让团队成员互相学习，更好地理解产品的全部部分。Sprint演示中还能加入项目涉众的快速反馈，为团队提供了一个互提意见和互相学习的机会，帮助你们继续成长。

在DevOps中，不断学习和不断实验的精神经过事故过后分析等行为获得了强调。JohnAllspaw帮助推出了过后无指责概念，以后这成为了如今DevOps实践的一个共识。他在博客中写道：“过后总结最重要的事情不是一系列能够采起的行动，而是组织学习。”

在Etsy，员工不只毫无责备地看待事件，甚至还庆祝失败。庆祝失败的缘由之一是犯错误的人其实是最好的工程师，这些人是那些为企业作出最大改变和推进创新的人。所以，重要的不只仅是限制责备，实际上还灌输了一种文化习惯，这种习惯将庆祝失败视为学习的机会。Etsy的CTO每一年会颁发一个颇有声望的奖项，以庆祝今年最大的失败。DevOps经过灌输诸如无指责过后分析和失败庆祝等习惯来鼓励一种开放讨论失败并不断学习和成长的文化。

『因为篇幅缘由，本文被拆分两篇，上篇主要介绍敏捷和DevOps的历史、差别和好处，点击蓝字便可阅读《使用DevOps强化敏捷（上）》。』

关于Choerodon猪齿鱼

Choerodon猪齿鱼是一个开源多云技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台经过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

Choerodon猪齿鱼已开通官方微信交流群，欢迎你们添加Choerodon猪齿鱼微信(ID:choerodon-c7n)入群

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：choerodon.io
• 论坛：forum.choerodon.io
• Github：github.com/choerodon
• 码云：gitee.com/choerodon