解读华为云CodeArts HE2E端到端DevOps实施框架

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

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

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

• Why：回答我们为什么做这些？也就是我们要试图达成的目标。找到正确的问题，要比找到好的回答困难得多。
• Who：回答谁能产生需要的效果？谁会阻碍它？谁是产品的消费者或用户？谁会被它影响？也就是那些会影响结果的角色。找对受众群体，是接下来最关键的问题，受众若是匹配错误，做出来的产品就是对牛弹琴。
• How：回答考虑角色行为如何帮助或妨碍我们达成目标？我们期望见到的影响。
• What：回答作为组织或交付团队，我们可以做什么来支持影响的实现？包含：交付内容，软件功能以及组织的活动。

最后，才是我们要做的事情，也就是通常我们讲的产品功能。

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

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

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

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

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

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

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

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

用户故事地图是一门在需求拆分过程中保持全景图的技术，目的是既见树木，又见森林，聚焦于故事的整体，而不是过早的纠缠于细节，在看到全景图的同时，逐层进行细节拆分。采用用户故事地图，跳出了扁平化的产品待办列表，看到了产品的全景图，可以真正聚焦于目标用户以及产品最终的形态。产品待办列表只是一维的，而用户故事地图是三维的，这是高维与低维的比较，高维恒胜。

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

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，Start Finishing，停止开始，聚焦完成。我们开发中最大的问题往往在于开始的事情太多，却没有及时的将一件事情打穿做完。为什么会这样？如何发现？答案是可视化，人们往往没有意识到自己同时在进行的工作到底有多少，一旦将并行工作可视化出来，加上WIP限制，才有可能解决并行在制品问题。

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

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

持续交付

正如Jez Humble对持续交付的定义：“The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way.”持续交付也好，DevOps也罢，最终目标是快速的交付价值。

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

工程实践就像人体的肌肉，是强调执行力的，是大脑想到然后肌肉能够做到并且快速的做到。每一丝的赘肉都会影响身体执行的速度，所以需要锻炼来消除。如何消除持续交付过程中的赘肉？和肌肉锻炼燃烧脂肪一样，痛苦的事情需要反复做，做十次一百次上千次，反复打磨，持续优化。

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

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

质量与速度能否兼得？答案是肯定的。要持续识别并消除开发中的约束点，常见约束点以及相关建议有：

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

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