DEC培训Day-1：导论和精益敏捷
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法
image.png
PATHS
image.png
DATA
image.png
RULES
image.png
SPKIES
使用MVP来探索用户的需求
-
需求估算方法
建议需求估算不要花费太多时间
统计各种SIZE需求花费的历史数据，可计算花费人天，适合中长期规划估算
理想人天：比较难以估准。
根据自己的团队文化进行估算 -
需求规划和发布
通过用户故事地图，按照场景和大功能进行需求归类，再从每个版本规划功能（产品经理的职责）
跨团队敏捷（Scrum of Scrum）
适用场景：团队需求耦合、团队技术架构耦合，且团队人数也较多的时候，需要拆分多个Scrum小团队，通过SoS方法进行协作
尽量不要走版本火车的模式，通过管理手段应该避免浪费，而不是增加浪费
产品经理团队制定愿景、对齐中长期目标、横向对齐需求优先级并驱动一起做计划
跨团队需求引入特性技术负责人，把控和对齐方案
社区沟通架构和技术演进和成长，促进人员能力提升和跨团队沟通
Sos扩展实践
- 产品经理团队内定期产品发布规划，关注整体目标
- 产品经理团队内主动对齐需求优先级和依赖
- PM联合技术负责人沟通和对齐方案
- 共享团队chengyuan
- 成立集成团队专注解决项目集成过程中各种问题
Sos扩展实践
- 从产品交付价值角度建立产品backlog，可分不同团队子视图
- 产品级是用户故事视图，研发级是用户故事拆分出的任务视图。
- 团队间协调实践
- 团队建设同步迭代解耦（迭代日历）
- 派代表参加SoS会议（定期解决协作问题）
- 扩展Sprint计划实践
- 产品经理和技术负责人提前沟通对齐
- 计划日错开
- 大房间（集中办公）
