软件工程持续交付

软件工程持续交付

推动的DevOps

改进包括以下3部分

• 研发流程工具平台管理，包括项目管理平台、公司代码与版本管理平台，以及需求管理工具和持续集成工具
• 过程改进组，负责研究并引进业界先进的软件项目管理理念，并在公司试点推广，知道公司项目的过程改进工作，提升流程效率
• 知识管理，主要是建设用于知识沉淀的支撑平台

改进的关键点

改进方法论

“目标驱动，从简单问题开始，持续改善”是整个改进过程的指导思想

定义改进目标

各级负责人

• 部门负责人的期望。从项目管理上讲，我们面临的一个大问题是计划性非常差。并不是我们不做计划，而是经常有各种各样的情况发生，总会让项目变得不太可控
• 团队管理者的交付压力。我们非常希望能够快速交付，但我们对这类架构变动类的项目不知道怎么能做到，另外我们虽然在这个项目的需求范围和交付时间要求方面可以有一定的灵活性，但是其中一部分的需求一定要在指定时间内完成
• 项目负责人的烦恼。估算不准确、临时插入事情多、项目计划很难做；到了计划的测试时间点，开发人员还没联调完，无包可测试；当有软件包可测试的时候，测试人员却被调去测试其它项目了；好不容易有测试人员了，一测试就发现很多低级问题，可能都启动不了；没法继续测下去，还要打回给开发，继续修复；测试环境和测试数据的准备要耗费很长时间；测试时需要将线上环境的一些配置同步下来，因为那才是最可靠的环境；反复提测好几次，手工重复测试真的受不了；终于可以准备上线发布了，还要排队；当轮到自己的项目上线了，还要把前面已经上线的代码拉取合并，再测试；假如前面上线项目出了问题要回滚，我们还要把代码剥离出去，再打包测试；写了一堆上线文档，交给运维人员，运维人员说不符合运维规范，要重新修改；运维人员终于可以部署了，可是，刚部署上去，就出问题，原来把配置文件搞错了

阶段性改进的目标

• 短期目标
  • 项目近预期时间交付
  • 创建新的软件研发协作方式
  • 建立必要的基础设施，以支持后续的持续发布模式
• 中期目标
  • 缩短发布周期，可以快速上线
  • 不降低生产环境的质量
  • 降低测试人力总投入

做个靠谱的计划

需求拆分

• 每个需求实现少于3天
• 拆分要遵循INVEST原则
• 拆分过程中的权衡

采用相对估算法估算工作量

初始计划

1. 理想情况下，团队每周工作时间是多少？
   • 假设每个人每天工作8小时，减去每周架构组的团队例会需要1小时，再减去项目组每日站会10分钟，再减去每天未工作时间（按每天2小时计算，谁能每天8小时都在工作呢），那么实际在一周内每人的生产时间为28小时，即每人每天大约可以有5.5小时的开发工作
2. 理想情况下，每周能完成多少需求？
   • 在估算之前，提醒团队：每人每天只有5.5小时的生产时间。然后拿出一些需求，让团队成员进行评估，当日是否能完成，最后统计这些需求所需要耗费的点数，平均下来，每周可完成的点数为22点
3. 实际上每周最后可能开发完成多少需求？
   • 评估一下，处理不属于该项目的事务（线上异常、紧急的hotfix、与其他团队的临时沟通），平均每天大约会占用团队多长时间？该项目的结论是：两个资深人员大约50%，另外两个开发人员大约是30%。整体上算团队有40%时间在忙其他的事务。另外，我们在剩余的时间中，还可能需要一部分时间用于交流，例如和测试人员讨论需求细节、确认测试用例等，者可能会占去我们10%的时间。这么算下来，开发人员还有50%的时间可用。因此，每周可以完成的点数是22 X 50% = 11个点的需求
4. 如何处理整个项目开发过程中的线上需求变更？
   • 对于临时的紧急需求，在线上发布版本分支上单独拉分支（hotfix分支），快速修复线上问题或开发紧急需求，快速合并上线的策略
5. 系统测试的时间在哪里？
   • 使用测试左移的方针，通过“迭代开发，并且每个需求完成就进行集成测试”，通常这会大大减少在后期测试阶段发现缺陷的数量，并可以及时反馈开发质量
6. 其它类型的测试（如性能测试和压力测试）怎么办？
   • 对于性能测试，我们每周一次，得到结果数据，如果发布有问题，马上诊断修复，这样做，质量反馈会很快
7. 计划时还需要考虑依赖因素？
   • 在业务和技术两个方面，该项目与其它团队是否存在依赖关系
   • 在计划中，还需要考虑个人事假和病假、集体活动和法定假日
8. 项目计划在整体上要加一个缓冲时间，更符合实际？
   • 在项目计划中是需要考虑任何异常清空发生，并且还包含多个假设条件。例如：全力开发是2个点/周；被其它非本项目的事务打扰，占用40%；整个团队只有3天时间被非工作事务占用（法定假期、团队活动和团队临时休假）。以上3个主要假设都有可能不成立，需要密切关注。因此在项目整体周期上，再加入一个缓冲时间更合适
   • 在项目进行过程中，可以通过这个缓冲时间的消耗来作为项目风险转化指示器

开发阶段

迭代周期的选择

• “隐喻”，当湖面很高时，湖中的石块都被水所覆盖，此时即使有很大的岩石，也看不到。当水量减少，水位下降时，一些大石头就暴露出来了。随着湖面水位进一步降低，更小的石块也会逐步被人们发现。如果把水面的高度看作每个迭代的时间，那么，水中的岩石就可以看作日常工作中存在的问题

• 使用快速迭代开发模式后，交付时间周期变短，也相当于水位下降，问题就很容易暴露出来

团队协作流程

• 每个迭代的工作约定
  • 每天上午10:00进行晨会
  • 每个迭代的最后一周5下午，进行团队回顾和下一个迭代的开发计划
  • 每个迭代计划中包含开发完成计划和测试完成计划（即一共可以开发完成多少点需求，可以测试完成多少需求）
  • 以开发速做计划，以验证完成无缺陷为测试速度来检验我们的迭代计划
  • 不对已估算的需求进行再次估算
  • 对于新增需求，需要进行估算
• 对于单个需求的开发流程约定
  • 按照单个需求（用户故事）的生命周期进行开发提测
  • 规避“批量开发、批量提测”的习惯。采用“小批量交付”的方式

对过程质量的约束

• 如何能自觉遵守CI纪律
  • 通过提醒大家，像交通信号灯一样，提醒团队不要破坏团队协作文明，这是团队的质量准则
• 编译时间过长
  • 组建分布式编译集群
  • 使用云编译构建平台
• 开发人员无法运行自动化测试
  • 提供可以由开发人员运行自动化测试的环境，或者由测试人员提供脚本给开发人员，通过脚本调用自动化测试用例
• 自动化测试的策略
  • 自动化单元测试
  • 模块自动化测试
  • 服务接口自动化测试
  • 子服务系统自动化测试。是指本项目的服务模块进行整体端到端的自动化测试；这类测试主要覆盖服务的主要流程，确保各服务模块之间的运行正确
  • 大环自动化测试。是指本项目服务与外部系统的交互测试；由于成本最高，环境最复杂，依赖因素更多，这部分自动化测试用例最少
• 自动化测试所需的运行环境不足怎么办
  • 在资源有限的情况下，可以通过代码改造，将固定配置，改为可配置的方式，进行集中部署测试
• 如何确定一个需求可以提测
  • 测试人员在开发人员的机器上体验过该需求
  • 所有自动化测试都通过了（包括针对该需求新增加和修改后的自动化测试）
• 如何做性能和压力测试
  • 应对策略。1.使用部分关键用例，选择特定的指标维度，在较短时间内运行完成这些测试，再通过性能或压力曲线来判断性能和压力方面的风险；2.根据针对性的几个指标给定阈值，有异常就报警；3.定期进行人工对比，如果发现性能隐患，立即指定人员进行分析，并根据分析结果，共同决定修复的具体时间安排
  • 过程改进切入点。对开发人员的工作要求；团队的自我主动改进；不能修改最初估算的大小；燃烧图中的秘密

阶段性改进点

• 业务目标合理
• 项目计划透明度（过程透明与结果透明）
• 流程“自定义，自遵守”，团队确保高质量交付
• 定期主动回顾，而非事件驱动的回顾
• 通过细粒度需求组织开发流程
• 持续集成六步提交法
• 适当使用自动化测试，提高质量反馈效率

DevOps转型

• 与运维人员的“冲突”
  • 让运维人员参与团队的日常运作，增加透明度
  • 开发负责人为运维人员详细讲解目前使用的研发流程模式，让他了解现在的各种过程质量保障手段
  • 邀请运维人员参与到团队活动中，参与我们日常工作的一些讨论，同时参与团队迭代回顾会议
  • 将运维人员加入日常团队工作沟通群，以便他随时了解项目的运作状况
• 高频部署发布中的具体障碍
• 整体解决方案的设计
  • 自动化测试策略的调整
  • 自动化测试的便捷性
  • 测试代码的同源
  • 配置管理优化
  • 软件包管理
  • 部署与监控优化

DevOps阶段的团队改变

• 完整的跨功能团队，运维积极参与团队的日常工作和迭代会议
• 所有内容都做版本控制，包括原代码和测试代码、各类环境的配置项信息、相关的打包和安装脚本，以及一些数据
• 所有环境标准化管理，可以一键式准备好测试环境
• 建立完整的部署流水线，可以一键式发布到多类部署环境

研发组织效能提升的必经之路

知识工作者与熵增定律

“知识工作者是通过正规教育获得工作、职位和社会地位，主要利用知识和信息进行工作的人”，并指出“计算机技术员、软件设计者、医师、律师、会计师等都是典型的知识工作者”

• 每个工程师生产的都是非标品
  • 工业流水线生产出来的工件可以被看作具有高度一致性的复制品，然而，这些特征在软件中恰恰都不存在
• 软件工程的复杂性令研发效率降低
  • “熵增定律”指出，一个复杂系统在没有外力的作用时，会变得越来越混乱，直到无序。软件系统和生产软件的组织，恰恰就是复杂系统
  • 软件系统的主要问题不在于技术，而在于社会性因素。复杂的社会性因素带来的调整，远比技术上的要难处理得多
  • 技术可能是主要问题之一，但绝对不是唯一的问题，更大的问题在于：软件这种复杂系统，越多人参与协作，个体平均效率就越低

一致性是效能提升的必经之路

• 标准化是一致性的实施结果。对标准化的一个常见的错误理解是：标准化意味着管制、命令或控制。其实不然，标准化的真正价值是作为实验和优化的基础。例如，标准化本身作为比较的参照基础，也是改善的基准。如果有人对于做事方法有更好的想法，并且这个想法被提议后获得了批准，通过实验并和当前标准做对比、评估，这种新的做事方法很可能就会被推广
• 提升一致性并非为了消灭员工的创造性，而是为了让员工有更多创新实践
• 标准化作业并非强行如同机器人一般地统一每个人的工作，而是利用基础设施、系统性专业知识、指标体系和通查理来提升开发人员的工作流程的有效性和效率
• 开发新产品和新功能是一回事，让开发、测试、发布、监控等流程具有可拓展性、可靠性和高效性则完全是另一回事，它涉及研发过程中的三要素：流程、工具、个体

组织能力三要素

企业所展现的组织能力由3个基本要素组成，分别是流程机制、工具平台与个体能力

分析

• 流程机制
  • 是由整个产品研发、运营声明周期中的各个环节与工序、操作质量标准、上下游环节的衔接方式，以及交付质量标准共同组成
• 工具平台
  • 工具平台为流程的高质量和高效率提供了支撑，同时也是建立和维持一致性的一种手段
  • 当组织规模扩大以后，如果没有较好的一致性管理，会出现为解决统一问题而同时重复造多个“轮子”的问题，带来不别要的维护成本
• 个体能力
  • 为了达成一致性，减少因代码质量低而产生的隐性维护成本，团队也应该对参与代码评审的软件工程师有代码评审质量的一致性要求

目标与考量

• 在组织发展层面，必须在组织结构与管理机制上对这3个要素的协调向上发展有所支持，而不当的组织结构与管理机制会阻碍他们的发展
• 组织管理者需要持续思考的几个问题
  • 如何评估组织持续交付能力的当前状况
  • 如何识别组织存在的组织能力短板
  • 以什么样的方式和路径进行有效改善，才能够做到既不破坏现有能力的输出，又可以在预见的未来看到组织能力的进一步提升

胜任力评估

组织胜任力评估模型

过程维度

• 业务需求协作管理
• 配置管理
• 制品管理
• 分支管理
• 代码质量管理
• 测试管理
• 持续集成
• 自动化测试
• 环境管理
• 发布或运营
• 架构
• 数据觉察

结果维度

• 质量
  • 交付前的过程质量。创建与修复的缺陷分布情况；缺陷数量
  • 交付后的生产质量。单位时间内的故障数量；单位时间的运维时长
• 速度
  • 业务需求响应速度。业务需求前置时长；研发周期时间
  • 持续交付能力。集成发布周期时间；发布频率 & 变更失败率；生产问题从发现到修复的平均时长
• 吞吐率
  • 单位时间内的价值产出

个人胜任力培养体系

• 高层管理者（目标规划）
  • 理解目标，制定规划，引领转型
  • 必须具备组织转型的领导能力，了解转型过程中可能出现的问题，从而制定适合自身组织的转型规划，并做好应对偶然问题的准备工作
• 中层管理者（组织实施）
  • 掌握领导技能，指导和落实具体工作
  • 应该掌握其所在领域在转型过程中所需的知识与技能，同时还要深刻理解组织转型的战略意义，并有能力指导所在团队成员执行相应的转型计划与步骤
• 基层骨干（专项技能）
  • 掌握专项技能，并帮助同事学习进步
  • 应该了解所在领域的相关基础知识，同时理解在这种转型过程中组织对个体的要求，互相帮助，了解新知识，学习新技能，从而掌握先进流程与工具，最终实现组织整体能力的提升
• 基层员工（广泛知识）
  • 掌握通识与专项知识

组织健康度

• 组织健康度无法通过组织最高领导层的讲话或公司的规章制度来衡量，它需要通过全面的问卷调查以及科学分析才能够进行评估
• “组织上下同心追寻共同目标、遵循目标执行、持续创新和不断适应市场变动，并具备快于对手的变革能力”

相关内容

精益思想

• 精益思想是指导企业根据用户需求名，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除它
• 精益创业就是一个“开发-测量-认知”的验证学习过程。也就是说，把创意快速转化为产品，衡量顾客的反馈，然后再决定是改弦更张，还是坚守不移

问题分析方式

量化式影响地图

使用Why-Who-How-What的分析法，通过结构化的显示方式，让团队寻找达成业务目标的方法

从业务问题域触发，按“角色-影响-方案-量化”的顺序进行讨论

分析

• 角色。列出该问题域所涉及的人或角色
• 影响。针对每类人或角色，思考他们有哪些途径可以影响该问题的解决（积极的影响或者消极的影响）
• 方案。针对每一种途径，讨论并列所有可能影响该问题的解决方案
• 量化。尽肯能为每个解决方案定义一个可衡量的指标项

用户旅行地图

用户旅行地图（User Journey Map），是指以可视化方式，将用户与产品或服务之间的互动，按业务流分阶段呈现出来

制作用户旅行地图

• 定义用户。明确指定为某一类用户定义用户旅行地图
• 定义任务或阶段。在这些任务或阶段中，会有哪些不同事件发生
• 用户与服务接触点的互动行为。在不同事件发生时，用户如何操作，操作顺序如何
• 用户的动机。用户在每个操作背后会产生什么样的想法，有什么痛点
• 用户的心理。在每个操作中，用户心理会有哪些变化，情绪会如何起伏

工作量估算

相对估算

是指通过用户故事之间的大小对比进行估算，估算后的结果没有时间单位

分析

• 相对估算的难点
  • 当确定相对估算的基准单位“1”时，开发人员很难找到一个合适的用户故事做基准
  • 开发人员更关注讨论单个用户故事的点数是多少，而不是关注与其它用户故事比较的相对大小
  • 估算所花费的总时间较长（常常是整个下午，甚至一天）
• 相对估算方法的假设前提
  • 用户故事的客观工作量不会因为具体开发人员的差异而不同（尽管人员不同，花费的时间可能不同）
  • 由于软件项目的总用户故事数量较多，因此假设估计后的客观规模不会偏差太多
  • 开发人员是整个交付过程的瓶颈，因此仅有开发人员估算其开发规模，不包括用户故事的测试规模

排序法估算

这种方法有两个主张和4个前提

分析

• 2个主张
  • 这种方法将较多的需求放在一起比较时，结合上下文，更容易估算，而且能够降低因人员能力差异带来的估算偏差
  • 尽管单个需求自身规模并不一定准确，但在需求数量较多时，项目整体规模估计会相对准确
• 4个前提
  • 每个需求至少要有两人比较了解，而且可以完成（所需时间长短可能不同）
  • 不需要评估测试活动的工作量。其原因在于，我们假设测试不是流程瓶颈，能够及时完成测试，而开发环节才是整个系统的瓶颈。如果测试环境成为流程瓶颈的话，我们甚至可以认为“开发资源投入过多”
  • 所有需求已被分解，其规模大小不会相差太大
  • 需求的个数相对较多
• 补充
  • 当估算中出现相对工作量为“0”的现象时，我们可以将几个“0”点的需求合计为1点，即0+0+0+…+0=1

操作过程

• 准备工作
• 初步排序
• 讨论差异
• 确定工作量大小刻度
• 归并调整

操作过程中的注意事项

• 在估算之前，应该确保所有用户故事之间的规模差异不要过大。例如某个用户故事需要1小时完成，而另一个需要两周
• 如果各列卡片数量不符合正态分布，而是两头卡片多，中间卡片少，则说明用户故事粒度可能有问题，需要重新审视一下
• 如果在一列中有数个相关联且同样大小的故事，且先做完一个卡片，其它两个工作量会减少的情况下，可以将任意一个放在当前列，其它两个可以考虑放在比较小的一列中。但是具体情况还是要具体分析，因为实际情况较复杂。在整体审视环节中，这类分析和验证工作不可缺少
• 在讨论和移动卡片时，应该更多地与其它卡片进行对比，而不是直接说某个卡片属于哪一数字列。因为列上方的数字都是相对值，没有其它卡片的对比，这些数字没有意义
• 在讨论的过程中，会捕捉到一些之前没有发现的问题或信息，此时一定要及时记录下来。对于不清楚的问题，应该当场由业务人员给出结论
• 这种方法在那些没有尝试过相对估算的团队中首次使用时，最好由具有一定经验的人加以引导，对已排定的顺序进行适当验证

绝对估算

是指以绝对时间（如小时或天）为单位进行估算

制定项目计划时需要考虑PARID因素

• 优先级（Priority）
• 假设（Assumption）
• 风险（Risk）
• 问题（Issue）
• 依赖（Dependency）

敏捷宣言

和流程与工具相比，个体与交互更为重要

• 工具可以让很多重复的事情变得简单，但并不能解决一切问题，人与人之间的协作更为重要
• 各角色协作顺畅，才能让效率提升更多

敏捷开发十二条原则

• 尽早地持续交付有价值的软件，以便让客户满意，这是最高优先级的事情
• 即便在开发阶段后期，也欢迎需求变更。为了让客户获得业务竞争优势，利用敏捷过程来应对变化
• 频繁交付可工作的软件，建议采用较短的交付周期（通常是几周或一两个月）
• 在整个项目过程中，业务人员和开发人员每天能够一起工作一段时间
• 围绕积极的个体，建立项目团队。给他们需要的环境和支持，并相信他们能够完成工作
• 无论团队内外，传递信息效果最好和效率最高的方式是面对面地交谈
• 可工作的软件是项目进度的首要衡量标准
• 敏捷过程促进可持续发展。项目主要干系人、开发人员和用户应该能一直保持节奏
• 持续关注技术卓越和良好的设计，提高敏捷性
• 以简洁为本，它是极力减少不必要工作量的艺术
• 最好的架构、需求和设计会从组织团队中涌现
• 团队要定期地反思“如何变得更有成效？”，然后相应地调整自身行为

敏捷101模式

• 是指在瀑布开发框架模式下，对各个阶段内部进行迭代时间盒的划分，迭代周期通常是1~4周。其中开发阶段中的每个迭代周期内，都会发生需求分析、代码开发和测试活动。而且要在每个开发迭代结束时，做演示验收。但是，在进入开发阶段前，仍旧有需求收集、分析和计划的阶段，并且在开发阶段结束之后，也会安排一到两个迭代，作为系统测试迭代。最后可能会安排系统试运行阶段，然后再正式上线
• 敏捷101模式的特点是：瀑布开发模式中的几大阶段没有编号，只对各个阶段内部的活动进行适当调整。此模式通常应用与对持续交付理解不深、研发基础设施不完备，但希望改进的团队

大型互联网团队的FT化

FT是Feature Team，即全功能团队

特征

• 其任务是负责端到端的软件功能交付
• 具备交付该软件功能的所必备的所有能力
• 相对稳定的人员组成

“大规模生产”和“小批量交付”在软件行业

大规模生产

• 该方式是强调每个加工环节的效率，并且其前提是：每个环节的正品率都很高，甚至根本不会出错
• 存在的问题
  • 有可能存在需求考虑不充分的情况
  • 后期集成时发现的缺陷数量较多
  • 缺陷修复不及时，最终导致测试交付日期不可预期

小批量交付

• 遵循的质量原则是：“停止考检查来提高质量，取消大规模检查，而代之以在生产流水线的第一时间就建立质量保证”。通过“质量内建”原则，来约束每一个活动的过程质量