共计 4450 个字符，预计需要花费 12 分钟才能阅读完成。
咱们常常探讨什么是麻利、什么是精益、什么是 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 社区 冬哥
