使用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强化敏捷（上）》。』