2020年9月18日 DEC培训
一、Devops导论（董越）
概述
软件工程
核心思想：工程化。
为了解决软件危机，用工程化方法开发软件。要有严格的计划和周期。
敏捷——>精益：消除各种浪费
精益：定义工作目标，定义价值，识别价值流，流动，拉动，尽善尽美。
将关注点从自身转移到客户，关注价值流。
持续集成
- 为了避免独自前进太远
- 频繁测试，验证质量
通常狭义、不涉及SIT、UAT等
持续交付
软件可随时发布上线，交付测试。
持续交付是一种能力，能够让给各类变更（如新特性、配置变更、缺陷修复、尝试性内容等）以安全、快速、可持续的方式交付到生产环境或用户手上
架构和技术方面
结构化变成——>面向对象变成——>软件复用
实体机——>虚拟机——>容器——>函数服务
微服务、云原生
思路：尽量做到复用
DevOps诞生
原因：软件交付的形式的巨大变化：本地安装——>在线服务
部门墙：Dev团队与Ops团队
DevOps的目的是期待更顺畅的协作：Dev、QA、Ops
是“法”的维度
广义的DevOps
将Devops在本时代下的实践整合在一起
DevOps = 精益敏捷 + 持续交付 + 容器化 + 微服务
DevOps = Dev + QA + Sec + Ops
DevOps = 软件开发交付运营的最佳实践
DevOps的优化目标
产品定义侧
- CEO、产品经理
- 设计产品，探索和发现有用价值
- 多尝试，尽快反馈，迅速调整
产品实现侧
- 开发、测试、运维、安全
- 提供产品和服务，落地实现价值
——>在具体场景下的多快好省：更高产能、更快响应速度、适当的质量、合理的成本
不是所有项目都适合DevOps
DevOps的十个核心策略
细粒度低耦合
不仅仅是软件架构，也适用于组织架构
组织架构的考量：全栈团队更快速
集中办公的效率？
工具、环境、方法的优化，可以扩张团队的职能，让团队提高自服务的能力
小批量持续流动
瀑布——>Scrum——>以特性为颗粒度的交付（不再赶发布火车）
需求拆分
限制在制品数量
持续集成、持续交付
去掉发布窗口
综合手段保证质量和安全
扩展测试的定义
各阶段的综合保证：综合考虑测试的性质放在合适的位置
“便宜”的测试，尽量左移
"贵"的测试，进行右移
自动化与自助化
自动化好处：省时间、省成本、可重复、完备记录
单个活动的自动化+流程的自动化
自动化——>自助化
工具的稳定性
加速各项活动
硬件能力
并行
避免重复
只关注增量
缓存
关注各个过程活动中的加速
及时修复
涵盖范围：测试阶段、发布后
如何实现：及时通知、优先处置、修不如退、便捷排查
完备记录、充分展现
自动化不仅仅关注往前推动，还关注记录
- 工作项、sprint backlog、看板墙
- 流水线相关信息展现
- 版本控制&制品管理
- 对外来资产的管理
- 权限管理策略
- 组织内开源有利于协作
- 数据备份
保持一致性
内容涵盖：可重复性、标准化、组织级统一、运行环境一致性
实现方法：规范化、内化到工具、版本控制、代码化
有章可循的适度灵活
配置参数两类
- 随着系统演化的升级：类似源码的管理方法
- 对于每个具体环境的改变的变化：采用别的管理方式
协调完成整体功能
架构层面：接口定义、接口管理、兼容性
管理层面：SoS、SAFe、LeSS、DAD
工程层面：特性涉及多个部署单元的改动、集成、发布涉及多个部署单元、完整性、顺序、摘除与回退
基于度量的持续改进
组织结构与文化
1.1 关键思路：自主性
- 沟通、协调需要精力
- 协作带来排队和等待
特性团队：长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队
1.2 各职能之间的协作
- 每个团队都尽量是全功能的团队
- 工具&环境团队
- 方法&流程团队
- 其他情况
1.3 负责不同开发内容的团队的划分
长期团队
独立完成特性代码改动
运用康威定律：通过组织的改进，来推动产品的改进
有负责公共品的团队
层级：还是需要部分划分来进行层级管理
其他情况
1.4 团队规模
两个披萨原则：5-9人合适
自主 和 专注
DevOps文化
设置共同目标
尊重和信任
及时和充分的沟通
聚焦于解决问题并改进机制
鼓励学习和探索
其他
二、精益敏捷（丁晓娇）
基础
参考书
- 《精益思想》
- 《看板方法》
- 《Scrum敏捷软件开发》
五大原则：定义价值，识别价值流，流动，拉动，尽善尽美。
拉动：让客户按需求去拉动，而不是硬推给客户不想要的；只有被客户和下游拉动时，价值才流动
流动：从按“部门”和“批量”转化为“生产团队”和“连续流”
价值流中的浪费：
- 部分完成的工作（未被集成的代码）
- 额外过程
- 额外特性：最大化的做当下的需求，不要考虑额外的工作
- 任务调换：任务调整、切换时候的浪费
- 移动：针对强矩阵组织，打破部门墙。不需要协调资源去做事情。
- 缺陷：提前发现问题，成本可降低
- 等待：等待开发、等待测试、等待部署，都需要透明化，想办法去消除等待
- 管理活动：尽量自主去解决问题
为什么要精益敏捷开发
做到多快好省。通过强调价值、流动和人员，就可以提高质量，降低成本，加快交付速度
敏捷研发模型
Scrum：透明化、检查反馈、持续改进
长期：向团队同步价值、确定使命和目标
中期：制定需求和版本中期规划
迭代前：需求准备，优先级
迭代中：需求池、每日站会时间把握、暴露问题、sprint review还是需要的
两周一回顾
3355：3个角色、3个工件、5个活动、5个价值观
五大常见实践：
- 测试驱动开发
- 集体所有权：针对代码，所有人员可以看到整个工程的代码
- 风险和效能的权衡
- 持续集成
- 重构：优雅性的提升，每个迭代要解决部分技术债问题
- 结对编程：code review的进一步
看板方法
一种基于精益思想的软件开发方法，其五大实践：
- 透明化
- 规则显示化
- 限制在制品
- 管理流动
- 建立反馈，持续改进
透明化
针对不同公司、不同场景组织架构下，浪费的活动定义不一样
价值活动：需求分析、编码、……、部署
I型浪费：
- TO C场景下的编写文档
- 跨团队沟通
- 系统间联调
II型浪费：
- 协调团队排期
- 部署申请
限制在制品的价值、原则和方法
什么是在制品
又称WIP，“进行中”能交付客户价值的工作，包括待开发的需求，未被集成的代码，未测试的代码，未部署的制品等。
为什么？
- 精益思想之流动：小批量，让价值流动起来
- 在制品越多，切换和等待产生，反馈环被拖长
- 通过限制在制品，有效识别和消除浪费，加速流动
- 提高质量，减少复杂度，提高专注度
基本原则
- 限制在制品不是目的，改进才是；限制过程也是个改进过程
- 人员闲置或工作闲置
- 没有限制是不对的
- 更低比更高好，但不要使得组织压力过大，开始时设置大些，建立改进驱动力后，逐步调低
- 停止启动，聚焦完成
- 单件流"1"并不是答案
思路
限制在制品的过程就是发现问题和驱动改进的过程
方法
- 基于列的在制品限制（更倾向）
- 对于瓶颈处的处理方法——约束理论
- 挖掘策略：挖掘瓶颈处的问题，并解决它
- 保护策略：如设置缓冲区（比如开发->测试，中间增加“待测试”缓冲区）
- 服从策略：改善瓶颈效能所需要的变化通常不发生在瓶颈处，关注整体端到端（可调用其他资源协助）
- 突破策略：比如资源增加（最后再考虑这种策略）
- 对于瓶颈处的处理方法——约束理论
- 基于整个团队限制
- 按人员限制在制品
管理流动方法
管理并监控看板的工作流动
- 限制在制品
- 显示化等待列和实践，并缩短等待
- 消除阻塞，永远不要被阻塞——敏捷开发的最高指示
- 避免返工
- 打造跨职能团队
- 设定SLA或需求前置时间目标
- 通过每日站会及时发现和跟进阻碍流动的问题
- 识别和管理瓶颈
每个教练要定制适合自己团队的scrum+kanban研发模型
需求管理活动
用户故事 VS 工作故事
用户故事：AS...（角色），I WANT...（活动目标），SO I CAN...（价值原因）
工作故事：WHEN...（场景），I WANT...（活动目标），SO I CAN...（价值原因）
基本要素：标题、描述、验收条件(DoD)、优先级、大小
产品参与验收
六个特性：INVEST
从用户角度拆到最小可测试，可独立交付的最小用户功能
产品经理从用户价值角度拆，RD从独立负责人，风险可控角度去拆
要权衡管理成本，对于技术性团队，下太重管理成本可能做不下去。
需求拆分
需求拆分是后续所有过程的基础
- 面临的挑战
- 如何拆出既能体现进度又能在一个迭代内完成的故事
- 如何避免拆出瀑布型阶段任务
- 不会花费太多时间
- 不会迷失在网络上太多的拆分方法
需求拆分方法
复杂型故事：涉及基础架构型故事，无法拆分，占比较小
符合型故事：包含多个更小的故事，可以拆分，占比较大
针对业务人员，需要了解无法拆分的原因。SPIDR方法
5）. Spikes：刺入探索法。在不知道客户需求的情况下
2）. Paths：路径分析法。客户如何使用功能，客户路径。
1）. Interfaces：场景界面法。理清什么场景下客户的需求，通过什么样的功能来满足痛点。
4）. Data：数据因素法。与Rules类似，逐步将数据补充给用户。
3）. Rules：规则分析法。在Paths考虑的情况下，可通过迭代的方式逐步增加规则。
INTERFACE法
PATHS
DATA
RULES
SPKIES
使用MVP来探索用户的需求
需求估算方法
建议需求估算不要花费太多时间
统计各种SIZE需求花费的历史数据，可计算花费人天，适合中长期规划估算
理想人天：比较难以估准。
根据自己的团队文化进行估算需求规划和发布
通过用户故事地图，按照场景和大功能进行需求归类，再从每个版本规划功能（产品经理的职责）
跨团队敏捷（Scrum of Scrum）
适用场景：团队需求耦合、团队技术架构耦合，且团队人数也较多的时候，需要拆分多个Scrum小团队，通过SoS方法进行协作
尽量不要走版本火车的模式，通过管理手段应该避免浪费，而不是增加浪费
产品经理团队制定愿景、对齐中长期目标、横向对齐需求优先级并驱动一起做计划
跨团队需求引入特性技术负责人，把控和对齐方案
社区沟通架构和技术演进和成长，促进人员能力提升和跨团队沟通
Sos扩展实践
- 产品经理团队内定期产品发布规划，关注整体目标
- 产品经理团队内主动对齐需求优先级和依赖
- PM联合技术负责人沟通和对齐方案
- 共享团队chengyuan
- 成立集成团队专注解决项目集成过程中各种问题
Sos扩展实践
- 从产品交付价值角度建立产品backlog，可分不同团队子视图
- 产品级是用户故事视图，研发级是用户故事拆分出的任务视图。
- 团队间协调实践
- 团队建设同步迭代解耦（迭代日历）
- 派代表参加SoS会议（定期解决协作问题）
- 扩展Sprint计划实践
- 产品经理和技术负责人提前沟通对齐
- 计划日错开
- 大房间（集中办公）