软件工程发展概述
软件工程发展史：瀑布–>敏捷–>DevOps–>持续交付1.0(从提交代码到产品发布))–>持续交付2.0（识别和消除一切浪费）
双环模型：科学探索–快速验证。通过快速试错，提升持续交付能力，进而发展现有业务，并快速开创新业务。
四个核心原则：
- 坚持少做：少做，先做简单的事情
- 持续分解问题
- 坚持快速反馈
- 持续改进并衡量
持续交付七巧板：
价值探索环
价值只能由企业外部的客户来定义。
产品开发中常见的风险假设：目标用户假设（潜在用户群体）、问题假设（用户痛点）、解决方案假设（解决方案可以解决问题，且比现有方案都有效且高效），任何一个不成立，都会导致事倍功半。
探索环的目标：
- 从业务问题出发，与团队一起共同找出这3类假设
- 确认最大的风险点，制定相关的衡量指标，找出相应的最小可行的验证方案（Minimum Viable Solution, MVS）
- 借助验证环高速运转，尽早获得反馈，并根据衡量指标验证这些风险点
1 提问
- 问题的提出方及解决方案提供方代表尽量到场，参与讨论
- 尽可能多问几个“为什么”
- 为什么要实现？实现什么？如何实现？
- 移情，站在客户或问题提出方的角度思考问题，还原客户问题的场景
- 尽可能收集数据信息，作为问题理解和分析的佐证
2 锚定
- 清晰的目标：客观、具体、可衡量（衡量指标维度容易收集和量化），有时间限定
- 识别价值指标，而非虚荣指标
3 共创
共创是在我们制订了想要达到的目标后，团队为设法验证或达成目标而找出多种可行性解决方案的过程。在理解问题和制定目标后进行，以免解决方案过于发散。
- 量化式影响地图
- 用户旅行地图
4 精炼
对共创环节得出的众多方案进行评估，筛选出团队认为最小可行性解决方案的过程。
我们相信，通过实现（xxx这样的最小功能集合），我们的指标可以达到(yyy的程度)的话，说明我们关于(zzz)的假设是成立的。
工作原则：分解并快速试错（快试错，慢失败）、一次只验证一个需求假设、允许失败
共创与精炼的常用方法：
- 装饰窗方法
- 最小可行特性法
- 特区法
- 定向探索法
- 稻草人法
- 最小可行产品法
实施注意事项：
- 多角色参与探索
- 存在往复过程
- 风险不是等价的
- 注意上帝视角的风险
- 不唯数字论，数字只代表现状，需要分析未来
- 蛇行效应
快速验证环
借助各种方法与工具，让质量可靠的解决方案以最快的速度到达客户手中，从而收集并分析真实的反馈。
质量和速度是验证环的关键。验证环的4个关键环节：
1 构建
- 时间盒管理
- 任务分解：需求拆分、开发任务拆分
- 持续验证：持续集成+自动化测试
2 运行
将软件包部署于生产环境，并让它对外提供服务。每次新版本部署均不影响用户的正常使用。
3 监测
收集数据，统计展现结果、及时发现生产系统问题以及业务指标的异常波动，并做出适当的反应。
4 决策
分析衡量指标，验证是否符合最初的预期。决策坚持原有产品方向，还是做出调整。
工作原则：质量内建（过程质量管理，降低最终质量风险）、消除等待（下游拉动、任务自动化）、尽量并行（重复事务自动化）、监测一切
持续交付2.0的组织文化
- 指导思想：目标驱动，从简单问题开始，持续改善
- 安全、信任与持续改善：失败是安全的、相互信任、持续改善
- 质量文化
- 定义想要做的事情
- 定义期望的做事方法
- 提供相应的培训
- 做些必需的事情来强化那些行为
- 行动原则：
- 价值导向
- 快速验证
- 持续学习（定期回顾、事件复盘：根因分析–>总结经验–>制定改进措施与计划并跟踪执行结果）
- 度量的目标是改善
- 度量指标的4类属性：引领性指标、滞后性指标、可观测性指标和可行动性指标
- 改善套路
持续交付的软件系统架构
持续交付架构要求：为测试、部署、监控、扩展和失效而设计
系统拆分原则：
- “大系统小做”
- 清晰职责，可独立修改和发布
- 高内聚、低耦合
- 易于构建与测试
- 团队成员之间沟通协作更顺畅
常见架构模式：微核架构、微服务架构、巨石应用
架构改造实施模式：
- 拆迁者模式：一次性替换旧系统
- 绞杀者模式：旧系统继续运行，新功能用新系统开发
- 修缮者模式：新旧系统共同运行，逐步替换旧系统功能，最终实现完全替代
业务需求协作管理
瀑布任务分解模式：
利于持续交付的需求拆分总原则：坚持以业务视角对需求进行分解
部署流水线原则与工具设计
持续交付1.0的核心模式。软件交付过程的一种可视化呈现方式：从代码提交、构建、部署、测试到发布的整个过程。
利于集成的分支策略
-Subversion
- Git
持续集成
- 主干开发，频繁提交代码
- 每次提交都是完整有意义的工作
- 提交构建阶段在10分钟之内完成
- 提交构建失败后，立即修复；且其他人不得在修复之前提交代码
- 应在10分钟内修复失败，否则回滚引起失败的代码
- 自动化构建成功后，团队对软件质量比较有信心
六步提交法：
1 检出最近成功的代码
2 修改代码
3 第一次个人构建（本地构建）
4 第二次个人构建（提交前，检出最近成功的代码后构建）
5 提交代码到主干
6 提交构建(持续集成服务器执行)
自动化测试策略与方法
测试四象限：
软件配置管理
软件配置管理的范围：
- 一切皆有版本
- 共享唯一受信源
- 标准化与自动化
低风险发布
高频发布是一种趋势。
降低发布风险的方法：
- 蓝绿部署
- 滚动发布
- 金丝雀发布与灰度发布
- 暗部署
监测与决策
资源监测、应用监测和业务监测
数据监测体系：
相对排序法
- 绝对估算：估算准确的工期
- 相对估算：适用于软件项目工作量规模较大时，在启动软件开发之前制定发布计划
- 通过用户故事之间的大小对比进行估算，估算后的结果没有时间单位
- 较难找到一个合适的用户故事作为基准
- 开发人员更关注绝对估算
- 估算所花费的时间较长（一整天、半天）
相对排序法操作过程
1 全体开发人员到场，待估算的所有用户故事写在卡片上（只写一句话需求，并确保所有人能看懂）
2 初步排序，按工作量增大的顺序从左到右排列，工作量大小相当的故事卡放在一起
3 讨论差异，深入讨论有异议的故事卡，直至一致认为它应该在哪一列为止
4 确定工作量大小刻度，如1, 2, 3, 5, 8, 13
5 归并调整列头上没有数字的列到现有数字
将每列的用户故事数量与列头数字相乘，得到的数字再相加，等于该项目的总体规模。
参考
版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆