专家解读华为云端到端DevOps实施框架 | IDCF

我们经常讨论什么是敏捷、什么是精益、什么是DevOps，与其去讨论什么是，不如讨论为什么。精益、敏捷与DevOps为什么会产生？目的是为解决软件研发交付中遇到的各种问题。

软件研发的过程，是价值交付的过程。而价值交付，天生就是从客户来，到客户去，是端到端的。价值交付过程是一个系统工程，需要进行全局优化而非单点改良。割裂的去看价值交付价值流上的单点，亦或是阶段点之间的问题，例如业务到开发，开发到测试，开发到运维，都只能是局部改善。

华为HE2E（端到端）的DevOps实施框架，就是将整个软件价值交付过程完整展现出来，汇集业界先进实践的同时，也结合了华为自身30年研发经验，形成的一套可操作可落地的敏捷开发方法论，并基于华为云DevCloud工具链进行固化和承载。

下面让我们逐一解读HE2E DevOps实施框架的几个主要部分。

影响地图，回归商业的初心

简单的讲，影响地图是这样的一个思维逻辑和组织结构：为什么（Why）-->谁（Who）-->怎样（How）-->什么（What）

也就是：我们的目标是什么（Why），为了达成目标需要哪些人（Who）去怎样（How）影响，为此我们需要做什么（What）。影响地图通过构建产品和交付项目来产生实质影响，从而达到业务目标。

Why：

回答：我们为什么做这些？也就是我们要试图达成的目标。找到正确的问题，要比找到好的回答困难得多。

Who：

回答：谁能产生需要的效果？谁会阻碍它？谁是产品的消费者或用户？谁会被它影响？也就是那些会影响结果的角色。找对受众群体，是接下来最关键的问题，受众若是匹配错误，做出来的产品就是对牛弹琴。

How：

回答：考虑角色行为如何帮助或妨碍我们达成目标？我们期望见到的影响。

What：

回答：作为组织或交付团队，我们可以做什么来支持影响的实现？包含：交付内容，软件功能以及组织的活动。最后，才是我们要做的事情，也就是通常我们讲的产品功能。

往往我们做产品最容易犯的错误就是一上来就罗列一堆的功能，却没有想清楚我们为什么要做这些，有没有/有哪些人需要，需要这些功能干什么。

影响地图的价值正在于它将现实的商业逻辑用最清晰简洁的结构展现出来，以终为始，回归初心，从目的出发，推演出最终的产品功能。

影响地图可以帮助组织避免在构建产品和交付项目的过程中迷失方向。确保所有参与交付的人对目标、期望影响和关键假设理解一致。

影响地图可以有效地评估交付，作为质量反馈的标准之一：如果一个需求不能有效地支持期望的行为影响，那么即使在技术上正确，功能交付给用户了，也仍然是失败的。

用户故事地图，既见树木又见森林

由影响地图得到了What部分，也就是我们要做什么，是不是就可以当成用户故事User Story排进产品待办事项Product Backlog开始开发了呢？答案是还不可以。

用户故事是敏捷开发中普遍使用的实践，但常见的困惑是：产品负责人整理了一大堆的产品Backlog，还编排了优先级，过早地陷入到细节的讨论中，只见树木不见森林。

传统敏捷开发中，扁平的产品待办列表，存在很多问题：它很难解释产品是做什么的；对于一个新的系统，扁平化待办列表无法帮助我们确认是否已经识别出全部故事；同样的，扁平化待办列表也无法帮助制定发布计划，用户故事少则几十，多则上百，详细分析每一个用户故事并且做出是否采纳的决定是非常乏味并且低效的。

用户故事地图是一门在需求拆分过程中保持全景图的技术，目的是既见树木，又见森林，聚焦于故事的整体，而不是过早的纠缠于细节，在看到全景图的同时，逐层进行细节拆分。

采用用户故事地图，跳出了扁平化的产品待办列表，看到了产品的全景图，可以真正聚焦于目标用户以及产品最终的形态。产品待办列表只是一维的，而用户故事地图是三维的，这是高维与低维的比较，高维恒胜。

JeffPatton说，故事地图非常简单，事实也是如此。在Workshop游戏时，我们最短只需要15分钟讲解，30分钟演练，就可以完整地把用户故事地图弄懂。

用户故事地图基于简单的网格结构，规则是从左到右讲述故事，即叙事主线；自上向下的拆分，即由大到小的细节展现；其中最关键的部分是产品的构思框架，贯穿整个产品的发布地图，可以帮助团队以可视化方式展示依赖关系。此外，更多的背景信息可以摆放在地图的周边，例如产品目标，客户信息等；这几乎就是用户故事的全部了。短短几分钟的解释，所有的听众就能领悟到它的价值所在。这也恰好是用户故事地图的魅力所在，好的东西通常都很简单而有效。

Scrum与Kanban，相得益彰

有了需求的梳理和组织，接下来就是开发落地的过程，而这一过程中，最多使用的就是Scrum与看板的方法。

Scrum与看板，在江湖上是两个门派，采纳时是否需要泾渭分明，区分严格呢？笔者是一个实用主义者，并非唯方法论者，Scrum与看板事实上是可以很好结合的。Henrik Kniberg有一本书叫做《Scrum与Kanban相得益彰》，讲的就是如何兼容并蓄，将Scrum与Kanban的实践进行融合，相互借鉴，从而发挥两者的最大价值。

Scrum的好处是，它是一个框架，设定了角色、活动、过程产物，以及相关原则。

计划会议与每日站会，形成了时间维度上从大到小的拆分；Product Backlog与Sprint Backlog，形成计划层面从大到小的分解；而Epic-Feature-Story-Task的层级关系，形成了需求粒度上的划分。

迭代评审会议，是对迭代产物的沟通与反馈；回顾会议，是对迭代过程的审视与优化。

Scrum设定了严格的时间盒Timebox，对节奏的保持大有益处，Develop on Cadence，产品大的版本/批次，到小的迭代，再到每日的站会，就是一个很好的节奏把控过程。

Kanban最大的价值在于可视化，软件研发最大的问题就在于过程不可见。可视化意味着把价值流动，以及问题都显示化出来。暴露问题，而不是遮掩；解决问题，而不是追责。

WIP限制在制品，是看板方法中最难遵守的实践，却也是精益软件开发原则的精华体现。Stop Start，StartFinishing，停止开始，聚焦完成。笔者今天下午还在和同事聊，我们开发中最大的问题往往在于开始的事情太多，却没有及时的将一件事情打穿做完。为什么会这样？如何发现？答案是可视化，人们往往没有意识到自己同时在进行的工作到底有多少，一旦将并行工作可视化出来，加上WIP限制，才有可能解决并行在制品问题。

生产过程中的物料堆积被视为浪费，研发过程中的任务堆积如何解决？有了前面讲到的可视化，让过程以及产物看得见；有了WIP，让并行工作得到控制；但依然无法解决上下游产能不匹配可能造成的任务堆积问题；拉动式系统对比于传统的推动式系统，目的就在于解决这一问题。传统开发过程中任务是被上游推动，一旦下游产能低于上游，或者出现阻塞，就会出现下游的任务堆积；拉动式系统中，只有下游产能出现空余，才能从上游拉动任务，由于有WIP的限制，所以上游一旦超过WIP，而下游又没有产能可以拉动时，上游是不能继续开展工作的（Stop Starting），所以最好的办法是帮助下游尽快完成（Start Finishing），这也体现了Whole Team的精神。

可视化，WIP，拉动式系统，形成了看板的三要素。

我们刚刚介绍了HE2E大图的上半部分，通常被称为管理实践，也是传统敏捷开发所关注的部分。接下来我们看下半部分的工程实践，持续交付域。

持续交付

持续集成、持续测试、持续交付、持续部署、持续发布，会不会傻傻分不清楚？（如果真的分不清楚，可以查阅笔者早先的文章）

正如Jez Humble对持续交付的定义：“Theability to get changes—features, configuration changes, bug fixes,experiments—into production or into the hands of users safely and quicklyin a sustainable way.”

持续交付也好，DevOps也罢，终极目标是快速的交付价值。

如果说管理实践的目的是为了鉴别什么是正确的事情，以及正确的做事情；那么工程实践的目的，除了正确的做事情以外，还有就是高效的做事。

工程实践就像人体的肌肉，是强调执行力的，是大脑想到然后肌肉能够做到并且快速的做到。

每一丝的赘肉都会影响身体执行的速度，所以需要锻炼来消除。如何消除持续交付过程中的赘肉？和肌肉锻炼燃烧脂肪一样，痛苦的事情需要反复做，做十次一百次上千次，反复打磨，持续优化。

工程过程是需要高效、准确并且高度保持幂等性的，也就是说执行一次的结果，与执行一百次的结果应该是一样的，所以对一致性的要求极高，人工过程是无法满足高频度发布与部署，因此工程实践要求的就是尽可能的自动化。最大化的自动化，越是频繁做的事情越要自动化，越是需要尽快反馈的事情越要自动化。在自动化来保证一致性的同时，我们还要去消除阻塞，发现问题并进行疏通。

自动化与人工审核要有机结合，需要想清楚人工审核的目的是保障质量，而不是管控，更不是官本位的体现屁股所在。每一个存在人工审核的地方，先想一想是否一定需要，是否有自动化的方式，是否可以后移。

质量与速度能否兼得？答案是肯定的。

要持续识别并消除开发中的约束点，常见约束点以及相关建议有：

• 环境搭建的约束点，采用基础设施即代码的实践，应该让环境搭建与配置的过程自动化、版本化，提供自服务平台，使能开发者；
• 代码部署过程的约束点，采用自动化部署实践，利用容器化与编排技术，让应用部署与运行的过程呈幂等性；
• 测试准备和执行的约束，采纳自动化测试实践，分层分级的进行测试，针对不同的阶段，建立不同的测试环境，设置不同的测试目标，建立不同的反馈闭环；
• 设计，将重构等实践纳入日常的技术债务清理过程，演进式的采用服务化、微服务化的架构。

笔者喜欢长跑，教科书里说道：每一丝肌肉都对跑步成绩造成影响。工程过程也是如此，彼此之间会产生关联并彼此影响，因此我更喜欢将持续交付域作为一个整体来看待，而不是分裂的去看编译、构建、静态动态测试、集成、部署、发布等。工程过程更像是一个联动的机器，故而我们称之为持续交付流水线。良好配置的流水线，应该是分层分级，同时又不失整体的。

回到HE2E大图

• 持续交付是以代码配置管理为基础，目的除了传统意义的代码资产安全与管控，多人并行开发以及发版与基线管理以外，更重要的这体现了团队的协作与沟通。
• 代码检查即静态扫描，自动化的构建，拉起来的各阶段的自动化测试，以及相应的自动化部署过程，都被有机的串联在流水线上。
• 除了这些动态的阶段与活动，还有发布包的制品管理，以及各级的环境管理，包括开发环境、测试环境、准生产环境，以及生产环境。
• 持续交付流水线就是将整个持续交付中，都有哪些阶段，分别运行在什么环境，每个阶段执行什么活动，准入与准出的质量门禁，以及每个阶段的输入与输出的制品进行管理。

作者：IDCF社区 冬哥