持续交付2.0读书笔记

发表于 |

第一章

VUCA，volatility(易变性)、uncertainty(不确定性)、complexity(复杂性)、ambiguity(模糊性)，源于军事用语，911后概念才被确定，该词用来描述混乱的和快速变化的商业环境。面对复杂易变的商业环境，那么在进行软件实践的时候就会遇到很多难题，问题从此就展开了。

软件工程

软件工程是软件危机的产物，是落后的软件生成方式无法满足计算机软件需求而产生的现象。人们视图将目光投向建筑工程，希冀找到一种工程式的方法来实现快速交付软件的愿望。

1. 瀑布软件开发方法

瀑布软件开发方法很像流水线，和现在的主流程其实也没有什么不同，不过该段流程很重，周期很长。重计划、重流程、重文档，一切都很慢。

2. 敏捷软件开发方法

敏捷不是压榨，敏捷也不是为了赶时间而时刻产生技术债务。scrum和极限编程，都是在该时间产生的软件开发方法。

3. DevOps

是一种理念，一种实践。包括了开发、运维和测试，使得从前比较独立的三方联系的更加紧密。

4.AIOps

目前比较新的一种理念，后续应该是发展的主流，DevOps加上AI的能力来重塑这个流程，使得流程更加的智能，更加的有效率。

5.持续交付1.0

提出了部署生产线概念，工业化最伟大的发明就是流水线，而持续交付1.0的核心就是能够以可持续方式，安全快速把代码变更部署到生产环境上，让用户使用，整个过程就像流水线一样高效。

持续交付涉及的角色有产品、设计、开发、测试、运维
敏捷涉及的角色有产品、设计、开发
CI涉及的角色有开发、测试
CD涉及的角色有测试、运维，这里的CD指持续交付
CD涉及的角色有运维，这里的CD指的是持续部署
DevOps涉及的角色有开发、测试和运维。

持续交付2.0

会发现持续交付1.0是单纯技术领域的活动，有时候交付的软件并没有什么价值，所以借鉴了《精益创业》的思想，最小产品化原则，也即是MVP，从业务增益的角度来考虑问题。所以结合精益创业+持续交付1.0的思想就产生了持续交付2.0.

持续交付2.0的四个核心原则

1. 坚持少做

少即是多，这个上升到了哲学的高度了。

2. 持续分解问题

3. 坚持快速反馈

4. 持续改进并衡量

持续交付七巧板

持续支付2.0涉及的组织和角色众多，如果要描述的话可以用一个七巧板图来描述。

第二章.价值探索环

敏捷开发十二原则第一条：最优先要做的事情就是通过尽早、持续地交付有价值的软件来使客户满意。什么是价值？价值只能由企业外部的客户来定义，企业内部只有成本，没有价值这一说。那么如何识别和发现用户需求呢？

2.1 探索环的意义

探索环就是要从业务问题出发，与团队一起找出三类假设：1. 用户假设，我们提供的产品服务是针对某类潜在用户人群的需求 2.问题假设，目标群体存在某些痛点需要解决 3.解决方案假设，我们提供的解决方案可以解决这些痛点，而且比现存的解决方案都有效且高效。1和2可以综合成人无我有，3可以理解为人有我优。

2.2 探索环的4个关键环节

1）提问，关键有4点：1.涉众尽量到场 2.多问几个为什么，可以使用苏格拉底式问法 3.尽可能收集数据信息 4.移情，同理心。
2）锚定，设定目标以及目标分解的讨论过程，目的是确定要达成的目标以及可以衡量它的指标，应该避免模糊不清的目标，这点非常重要。目标的选择应该遵循两点，其一是识别价值指标而不是虚假指标，其二是指标应该可衡量而且便于获取，易于直观对比。
3）共创，当我们制订了要达到的目标后，团队为之找出的多种可行性方案的过程。有两种方法，一种是量化式影响地图，第二种是用户旅行地图
4）精炼，就是对众多方案进行评估，选出最小可行性解决方案的过程，VUCA环境中，时间是最大的隐形成本。

2.3 工作原则

2.3.1

分解并快速试错

2.3.2

一次只验证一点

2.3.3

允许失败

2.4 共创与精炼常用方法

装饰窗、最小可行特性法、特区法、定向探索法、稻草人法、最小可行产品法

2.5 实施注意事项

多角色参与探索、存在往复过程、风险不是等价的、上帝视角、唯数字论、蛇行效应。

第三章.快速验证环

只有产品或者服务被用户消费，并且最终能够得到变现，才能证明其价值的存在。快速验证环的速度由两个因素决定，一个是探索环的最小可行性解决方案的大小和复杂性，另外一个是快速验证环本身的运转速度。

3.1 验证环的目标

验证环的目标是借助各种工具或者方法、让质量可靠的解决方案以最快的速度交付到用户手中，从而收集并分析真实的反馈。

3.2 验证环的4个关键环节

验证环有4个关键环节，即构建、运行、监测、决策。

3.2.1 构建

构建是将自然语言的描述转换为计算机可以执行的软件，即质量达标的软件包。这个环节涉众最多，时间盒管理、工作任务分解、持续验证是这个环节有效的手段。时间盒管理类似项目管理，包括截止时间、交付物与交付质量；工作任务分解包括需求分解和开发任务分解；持续验证依赖持续集成，而自动化测试是持续集成最重要的质量验证手段。

3.2.2 运行

该环节最主要的矛盾是在用户无感知的情况下完成版本的升级更新，该阶段手工操作最多，需要不遗余力的进行优化，将人从重复性的体力劳动中解放出来。

3.3.3 监测

监测环节收集数据并且展示统计结果

3.3.4 决策

决策是根据监测的数据来验证是否符合最初的预期，从而来选择是继续下一个实验方案还是开始新问题的探索。

3.3 工作原则

3.3.1 质量内建

质量内建就是从第一个环节开始就关注质量。

3.3.2 消除等待

3.3.3 任务自助化

3.3.4 监测一切

第四章.持续交付2.0的组织文化

4.1 安全、信任与持续改善

4.1.1 失败是安全的

按照2/8原则，做的事情80%是错的，也即是失败的，如果不能容忍失败或者对失败者给予严重的惩罚，那么组员会倾向避免犯错，从而逃避责任，缺少合作。

4.1.2 相互信任

信任是合作的基础，也是组织凝聚力和成员士气的基础。

4.1.3 持续改善

持续改善的文化是人人参与以及时时改善，不积跬步无以至千里，乘法效应，慢慢来比较快说的就是这个道理。

4.2 文化塑造四步法

4.2.1 行为决定文化

行动决定很多东西，很多东西是行动带来的。行为决定性格，性格决定命运。四步法是

  1. 定义想要做的事情
  2. 定义期望的做事方式
  3. 提供相应的培训
  4. 做些必需的事情来强化那些行为

4.3 行动原则

管理学上把公司定义为一个复杂系统，兼具简单系统和随机系统的特点。其内部有很多的子系统，子系统间相互合作、互相影响，可以共同进化。

4.3.1 价值导向

4.3.2 快速验证

4.3.3 持续学习

在业务领域中，除了深入了解和学习，还要保持对做事过程的学习与反思。有两种方法，一个是定期回顾，二个是事件复盘。

4.4 度量原则

不能度量的东西是无法管理的。

4.4.1 度量指标的4类属性

  1. 引领性指标与滞后性指标
  2. 可观测性指标与可行动性指标
    IT组织的4个度量项分别为发布频率、发布周期、MTBF/MTTR、吞吐量。

4.4.2 度量的目标是改善

4.5 改善套路进行持续改进

四步法

  1. 明确方向与挑战
  2. 掌握当前状态
  3. 定义下一个目标状态
  4. 迭代改进，PDCA戴明环

第五章.持续交付的软件系统架构

亚马逊从巨石应用到SOA服务的改变

  1. 服务接口的方式提供功能
  2. 团队间通过接口调用
  3. 不允许有非接口的获取方式
  4. 具体的实现不作规定
  5. 所有的接口，必须以可以公开为设计导向
  6. 不遵守上面的规定，就会被解雇。

5.1 大系统小做原则

大系统小做是海量服务之道1.0里面的内容

5.1.1 持续交付架构的要求

  1. 为测试而设计
  2. 为部署而设计
  3. 为监控而设计
  4. 为失效而设计

5.1.2 系统拆分原则

  1. 每个组件或者服务有清晰的业务职责，可以被独立修改
  2. 松耦合、高内聚，每个组件只知道尽可能少的信息，完成相对独立的单一功能
  3. 整个系统易于构建与测试
  4. 团队之间的沟通协作更加顺畅

5.2 常见的架构模式

5.2.1 微核架构也即是插件架构

5.2.2 微服务架构

5.2.3 巨石架构

5.3 架构改造实施模式

5.3.1 拆迁者模式

5.3.2 绞杀者模式

5.3.3 修缮者模式

5.3.4 数据库的拆分方法

第六章.业务需求协作管理

6.1 产品版本周期概述

6.1.1 准备期

核心任务是达成业务理解与目标的共识，也可以称作启动期或者迭代0.准备期的主要工作内容如下：

  1. 目标阐述与理解
  2. 业务领域角色与流程识别，及解决方案的探索
  3. 重大风险识别与验证
  4. 精炼并达成最小可行方案共识

6.1.2 交付期

6.2 需求拆分的利与弊

6.2.1 需求拆分的收益

  1. 建立共识，协调工作
  2. 小批量交付，加强价值流动
  3. 低成本拥抱变化
  4. 多次集成，及时反馈质量
  5. 鼓舞团队士气

6.2.2 需求拆分的成本

  1. 需求拆分的显式成本
  2. 分批开发、测试和部署的迭代成本

6.3 需求拆分方法

6.3.1 需求的来源

  • 业务需求
  • 技术指标性需求
  • 安全需求

6.3.2 技术债也是需求

6.3.3 参与需求拆分的角色

6.3.4 不平等的INVEST原则

6.3.5 五大拆分技法

  1. 路径拆分法
  2. 按接触点拆分
  3. 数据类型或者格式拆分
  4. 按规则拆分
  5. 按探索路径拆分

6.3.6 七大组成部分

用户故事的七大组成部分

  1. 编号
  2. 名称
  3. 描述
  4. 技术备忘
  5. 前提假设
  6. 依赖关系
  7. 验收条件

6.4 需求分析和管理工具集

6.4.1 用户故事地图

6.4.2 用户故事树

6.4.3 依赖关系图

6.4.4 需求管理数字化平台

6.5 团队协作管理工具

6.5.1 团队共享日历

一直觉得这个工具是很有必要的，需要有员工的休假计划表，然后就是领导的会议时间表，还有团队的集体活动表

6.5.2 团队回顾

6.5.3 可视化故事墙

6.5.4 明确“完成”的定义

6.5.5 持续集成

6.5.6 故事验证

第七章 部署流水线原则与工具设计

部署流水线是持续交付1.0的核心模式，流水线是工业时代最伟大的发明。

7.1 简单的部署流水线

7.1.1 简单的产品研发流程

7.1.2 初始部署流水线

7.1.3 流水线执行状态解析

7.2 部署流水线的设计与使用

7.1.2 流水线的设计原则

  1. 一次构建，多次使用
  2. 与业务逻辑松耦合
  3. 并行化原则
  4. 快速反馈优先
  5. 重要反馈优先

7.2.2 团队的协作纪律

  1. 立即暂停原则
  2. 安全审计原则
    传递的代码和软件包来着受控环境，受控环境是指对该环境的一切操作均被审计

7.3 部署流水线平台的构成

7.3.1 工具链总体架构

  1. 唯一受信源
  2. 部署流水线平台
  3. 基础支撑服务层
    测试部门管理多套测试环境，运维部门则控制生产环境

7.3.2 平台应当具备的基础能力

  1. 审计追踪
  2. 重现问题

7.3.3 工具链建设策略

7.4 基础支撑服务的云化

7.4.1 基础支撑服务的协作过程解析

  1. 环境准备
  2. 提交构建
  3. 次级构建
  4. 部署生产环境

7.4.2 编译构建管理服务

7.4.3 自动化测试管理服务

7.4.4 软件部署管理服务

7.4.5 基础环境管理服务

7.5 企业制品库的管理

7.5.1 制品库的分类

7.5.2 制品库的管理原则

7.6 多种多样的部署流水线

7.6.1 多组件的部署流水线

7.6.2 个人部署流水线

7.6.3 部署流水线的不断演进

7.7 为开发者构建自助式工具

  1. 基础的研发流程自助平台，比如环境
  2. 数据自助平台
  3. 实验测量平台
  4. 针对移动设备，建立用户触达平台