软件工程发展史

瀑布软件开发方法

• 在1970年首次提出，它将软件开发过程定位为多个阶段，每个阶段均有严格的输入和输出标准
• 通过重计划、重流程、重文档的方式来解决软件危机
• 流程简述：系统需求、软件需求、分析、程序设计、编码、测试、部署运行

敏捷软件开发方法

• 于2001年由17位软件大师共同发表了“敏捷宣言”
• 敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件
• 软件开发实际上是一个不断迭代学习的过程，通过快速学习并理解领域知识，并将其转化为数字世界的表达形式，通过与业务专家的交流讨论来学习并持续迭代这个过程

DevOps运动

• 源于2008年敏捷大会的一个临时话题“敏捷基础设施”，在之后发起并组织了一个“DevOpsDays”的社区会议，并正式启用了“DevOps”这个术语
• DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈提倡对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致
• DevOps并非一个标准、一个模式或者一套固定的方法，而是一种IT组织管理的发展趋势，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快

持续交付1.0

于2006年首次提出“部署生成线”模式。可以通过一键创建、配置和部署新的环境，利用这种部署模式，可以将经过验证的代码快速部署到各个环境，一旦发生问题，就可以轻松的回退到以前的版本

• 指导原则

  每个构建阶段都应该交付和工作的软件，即中间产物的生成（例如搭建软件框架）不应该是一个单独的阶段
  
  用同一个制品项不同类型的环境部署，即将其与运行时配置分开管理
  
  自动化测试与部署，即根据测试目的，分成几个独立的质量关卡
  
  这个部署生产线设计也应该随着你的应用程序的发展而不断演进
  

• 持续部署

   “部署”是一种技术领域的操作，也就是说，从某处获取软件包，并按照预先设计的方案将其安装到计算节点上，并确保系统可以正常启动，但她并不一定意味着“必须包含业务功能的发布或交付”
  

• 持续交付

  “交付”是一个业务决策活动，通常也被称为“发布”，也就是说，如果将新构建的特性交付到客户（用户）手中，用户就可以看到并使用他们
  

持续交付2.0

双环模型

整体流程

探索环

• 提问，即定义问题

  通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然会有偏差，因此，在寻找答案前，应该先清晰的定义问题
  

• 锚定，即定义结果目标指示器

  针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果
  

• 共创，即共同探索和创造解决或验证该问题的多种具有可能性的解决方案

• 精炼，即对所有的可行实验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合

验证环

• 构建，即根据非数字化描述，将最新可行性解决方案准确地转换成符合质量要求的软件包
• 运行，是指将达到要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务
• 监测，是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式呈现出来
• 决策，是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向

核心原则

• 坚持少做，想办法对新创意尽早验证

• 持续分解问题

  在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。即便是很大的课题或大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断的尝试新想法，并各自独立发布给用户
  

• 坚持快速反馈

  通过快速反馈，尽早了解所完成工作的质量和效果，避免埋头苦干，忽视了对每项完成的工作的结果反馈
  

• 持续改进并衡量

  在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成
  

探索环分析

工作原则

• 分解并快速试错

  更多的使用低成本的快速实验方式，在成本有限的情况下，可以尝试更多的方法，尝试更多的次数，意味着可能会有更多的收益
  

• 一次只验证一点

  一次只验证一个需求假设。在执行整个实验方案过程中，不断的优化这些实验方案。时刻提醒自己，我们的目标是验证我们的假设，实验方案只是我们验证假设的手段，而不是我们的最终目标
  

• 允许失败

  产品的方案无法保证每个都会获得成功，但我们可以从所有方案中都学到很多新的知识，而这些收获无论是对产品的成功，还会团队人员的能力提升都具有非常重要的作用
  

共创与精炼的常用方法

• 装饰窗方法

  指为新功能预留一个“入口”，让用户能够看到，但实际上并没有真正实现其功能。其目的是利用最小成本，来验证用户是否喜欢某个功能，以及其紧迫程度，为是否研发后续更全面的解决方案提供数据支持
  

• 最小可行特性法

  指在产品从1到N的过程中，寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法，以尽可能少的成本快速增加或修改某个产品特性，让用户使用，收集真实反馈，专注于验证功能改进，同时也可以提升用户体验
  

• 特区法

  指在特定用户范围内进行试验，以验证某个新功能的有效性。这样即使新功能无效或者效果不好，也不会影响特区外的用户。
  

• 定向探索法

  针对具有某种特定行为的特定用户群体，依据该用户的具体行为模式，设计调查提供，有针对性地探索其行为背后的动机。这种定向探索法与一般的用户访谈的不同点在于：团队已经掌握了被访谈对象的具体行为，以事实为依据，进行定向式的探索发现，而非宽泛的通用提问
  

• 稻草人法

  指不开发任何真实的功能，只假装这个功能已经完成了，并向用户展示该功能的真实效果，从而得到用户的真实反馈。这种方法与装饰窗方法的区别在于它让用户真实地感受到了功能提供的结果，而事实上并没有开发这个功能
  

• 最小可行产品法

  指产品从0到1的过程中使用。它以尽可能少的成本快速开发产品的核心功能，并找到用户，收集真实反馈，验证真实的用户需求，以确定新产品方向和形态的方法，其目标是找到合适的产品形态
  

验证环分析

进入验证环的基本前提是“团队已达成共识，所选方案是当前所处环境下，验证或解决业务领域问题的最佳方式”。借助各种方法与工具，让质量可靠的解决方案以最快的速度到达客户手中，从而收集并分析真实的反馈

工作原则

• 质量内建

  指从生产过程的第一个环节开始，就要注重产出物的质量，并且在每个环节中都要开展质量保障活动，消除因质量问题导致的返工及次品率上升，以此降低最终的质量风险，保障进度
  

• 消除等待

  通过“拉动”让价值流动起来
  
  根据下游的生产能力来确定上游的生产速度，即下游环节拉动上游的需求。为达到流畅效果，需要将需求颗粒均匀化。即在构建环节，通过需求分解，将大需求分解成多个工作量相近的小需求，才能让工作变得平滑顺畅
  
  也可以利用开发环节暂时过剩的人力来建设工具平台，提升下游的基础能力，使得在不增加人力的清空下，永久提升团队整体产能。提升人员整体技能水平也能达到同样的目的
  

• 任务自助化

  通过运用先进的生产技术，使得环境部署、数据统计这一类事务性操作不再依赖“专家型”人才，而是让每个人在其需要时都能够“自助服务”
  

• 重复事务自动化

  将软件研发过程中重复性的工作，如搭建测试环境、回归测试、应用部署、发布等交给善于做这类重复性工作的机器，通过优化流程和自动化措施，有效降低这些固定的事务性成本，同时避免不必要的人为操作失误
  

• 监测一切

  通过全面的系统监测，并在第一时间发现异常，才能够及时应对，以确保业务可持续性
  

持续交付七巧板

• 业务需求协作管理
• 部署发布与监控管理
• 构建与环境管理
• 分支与配置管理
• 自动化验证管理
• 易测试性易部署性易拓展性易监控性
• 文化建设组织架构人员结构激励体系

涉及的团队

• 业务市场
• 产品
• 开发
• 测试
• 运维

组织文化

安全、信任与持续改善

持续交付强调“持续探索”与“快速验证”，而探索必然伴随着失败，失败会令人产生挫败感与不安全感，而学习与成长通常发生在失败之后。这就要求组织必须建立“安全、互相信任和持续改善”的组织文化

分析

• 失败是安全的

  一个组织对待“失败”的态度至关重要，无论是实验中的失败，还是组织改进中的失败。在探索环中识别了很多假设，为这些假设建立了衡量标准，并对验证环的结果进行了度量。这些实验结果不应该直接评判个人，否则会使组织成员在设计方案时倾向于“为了证真而设计”，而非“为了证伪”。这样很难从这种“持续成功”中学习更多的知识
  
  组织是一个复杂系统，它的改进更为复杂。如果组织成员发现，在组织中“犯错”是个很糟糕的事情，会受到惩罚，那么，为了避免出错受到惩罚，组织成员就会放弃做出有风险的决策
  
  如果无法让组织成员感到“失败是安全的”，那么组织成员的行为就会倾向于避免犯错，各扫门前雪，逃避责任，缺少合作
  

• 互相信任

  互相信任是高效合作的基础，也是组织凝聚力和成员士气的基础。成员之间的相互信任既包括对彼此个人品质的信任，同时也包含对专业能力的信任。这种信任是相互的，赢得他人信任的同时，也要信任他人，认可他人的个人品质与专业素养。如果组织成员之间缺乏信任，那么很容易出现互相猜忌、互相指责的现象，用不了多久，就会影响成员在组织内的安全感，降低工作效率
  

• 持续改善

  持续改善文化的特点是“人人参与”和“时时改善”。“人人参与”是指持续改善不应该只是组织中某个角色的责任，而应该是所有人的责任。“时时改善”是指持续改善应该是一项日常工作，而不应该只在特定时间或条件下才发生，例如只在事故反生之后才进行分析和改进
  

文化塑造四步法

行为决定文化

• 组织文化是一些列行为结果的展现，体现在人与人之间的日常工作交互中，因此我们无法直接改变“组织文化”。但是我们可以通过培训企业员工具备必要的能力，同时规范员工做事的方式，而达到塑造企业文化的目的

• 例如：谷歌的工程师质量文化

  定义想要做的事情
  提高代码质量，减少生产问题，减少手工测试工作量，快速发布软件
  
  定义期望的做事方法
  开发团队编写自动化测试
  主动运行自动化测试用例
  做代码评审
  
  提供相应的培训
  在公司范围内组织代码设计与自动化测试培训
  为每个团队指派自动化测试教练，帮助团队提高自动化测试技能
  
  做些比需要的事情来强化哪些行为
  建立团队测试认证机制
  建立自动化测试组
  建立代码评审资质证书
  代码合入版本仓库之前强制做代码审批
  代码评审之前，必须运行自动化测试用例，并提交报告给代码评审者
  

行动原则

• 价值导向

  我们做事情是，应该价值导向。当我们讨论“价值”时，应该限定于一定的业务上下文，避免离题太远。同时，在讨论时应该尽量提供完整的上下文，并聆听他人的方案与建议
  

• 快速验证

  在高度不确定的环境中，我们需要快速验证。通过快速实施，得到真实反馈，从而做出决策。在安全的工作环境中，只要能够主动拥抱“快速验证”原则，充分发挥员工的主观能动性，就可以找到很多快速实验的方案
  

• 持续学习

  我们无法保证每个决策都是正确的，团队应当将每一次反馈作为一次学习的机会，结合从中学习到的新知识，总结成功或失败教训。
  
  两种常见的方式，一是定期回顾，二是事件复盘机制
  定期回顾是指每隔一定周期，团队主动安排一次会议，共同探讨在过去的这个周期内，团队在协作过程中的优点和不足，并讨论相应的对策，以便在后续工作中能够保持优点，改进不足，持续取得进步
  复盘机制通常是指针对反生的问题进行分析，其目的是避免相同问题重复出现
  

度量原则

分析

• “如果不能度量，就无法改进”。（现代管理学之父曾说过“你无法管理你不能衡量的事情”）。除非成功被定义，并且被跟踪，否则你无法知道自己是否成功
• 软件度量是对软件开发过程及其产品运营进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善
• 度量的目标是改善。我们通过设法管理过程指标来改善我们的工作过程，并将最终的效果与我们期望的结果指标做对比，从而发现改善是否有效，并判断是否需要通过修改引导性指标来改变牵引方向，还是保持不变，持续向前
• “如果一项指标变成目标，它将不再是一个好指标”。当对一项政策有一定的预期，并以人为操作的手段去偏向化改变结果的时候，就会发生这种现象

度量指标的4类属性

• 引导性指标

  引导性指标是指那些对达成预定目标有着重要作用的指标。通常一个好的引导性指标有以下两个基本特点：第一，它具有预见性；第二，团队成员可以影响这些指标
  

• 结果性指标

  结果性指标是指那些为了达成最重要目标的跟踪性指标，如销售收入、利润率、市场份额、客户满意度等研究分析都属于结果性指标
  

• 可观测性指标

  可观测性指标是指可以被客观检测到，但无法通过直接行动来改变的指标
  

• 可行动性指标

  可行动性指标是指在能力可触达范围内，通过团队努力，可以设法直接改变的指标
  

度量应有行动决策

软件度量需要收集、清理和分析数据，在决定对软件过程与结果进行度量时，组织应该考虑其投入，并评估其可能的收益。如果收集到度量数据后，并不影响组织的任何决策，那么就不必进行度量

“改善套路”进行持续改进

• 明确方向

  管理者需要明白，企业必须始终以愿景为工作目标，并持续不断地改进。在前进的路上，必然会遇到问题。我们需要通过不断试验与迭代，才能达成目标
  

• 掌握当前状态

  团队掌握当前的状态，获得事实与数据，才能充分认识自己，以对下一步目标状态进行合理的描述
  

• 定义下一个目标状态

  目标状态就是确定团队希望达到的状态，设置期望达到该状态的日期，并定义可衡量的指标项
  

• 迭代改进

  遵循戴明环（又叫PDCA循环），通过不断试验，发现、实施、评估改善方案，直到达成目标状态