DevOps 中的过程方法

过程概述

软件过程

软件过程就是为了实现一个或多个事先定义的目标而建立起来的、具有一定先后顺序的一组实践的集合，作为一个整体来实现目标。软件过程是软件开发的理论基石。软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

软件工程的两大视角

• 管理视角：如何获得成功？
• 技术视角：如何将问题解决地更好？

PSP/TSP 渊源和作用

• 过程改进运动
  • TQM
  • Humphrey 的早期工作
  • PSP/TSP
• PSP 作用
  • 个人级管理实践和过程估算和计划
  • 承诺和拒绝承诺
  • 理解和改进
  • 工业水准的过程和规范
  • 客观决策的数据

典型的 PSP 过程

个人软件过程（Personal Software Process，PSP）是一种可用于控制、管理和改进个人工作方式的自我持续改进过程。

典型的 PSP 过程

PSP 基本原理

• 软件系统的整体质量由质量最差的系统组件决定
• 软件组件的质量取决于开发这些组件的软件工程师
• 作为合格的软件工程师，应当自己度量、跟踪自己的工作，即自己管理软件组件的质量
• 作为合格的软件工程是，应当持续地建立自我改进机制，即将开发过程中的偏差和经验教训来整合到自己的开发实践中。

不同级别的 PSP

不同级别的 PSP

TSP 迭代式开发

TSP 与 PSP 相对，即团队软件过程，为开发软件产品的开发团队提供指导。TSP 一般满足几个人到几十人规模的开发团队，而大型的多团队过程的 TSP 最多为150人左右的规模。TSP 和 PSP 相互结合，帮助高绩效的工程师在一个团队中工作，来开发有质量保证的软件产品，并改进组织中的过程管理。

团队软件过程TSP基于以下4条基本原理：

• 应该遵循一个确定的、可重复的过程并迅速获得反馈，这样才能使学习和改革最有成效；
• 一个群组是否有效，是由明确的目标、有效的工作环境、有能力的教练和积极的领导这4方面因素的综合作用所确定的，因此应在这4个方面同时努力，而不能偏废其中任何—个方面；
• 应注意及时总结经验教训，当学员在项目中面临各种各样的实际问题并寻求有效的解决问题方案时，就会更深刻地体会到TSP的威力；
• 应注意借鉴前人和他人的经验，在可知利用的工程、科学和教学法经验的基础上来规定过程改进的指令。

在软件开发或维护过程中，首先需要按照群组软件过程框架定义—个过程。在设计TSP过程时，需要按照以下7条原则：

• 循序渐进的原则，首先在PSP的基础上提出一个简单的过程框架，然后逐步完善；
• 迭代开发的原则，选用增量式迭代开发方法，通过几个循环开发—个产品；
• 质量优先的原则，对按TSP开发的软件产品，建立质量和性能的度量标准；
• 目标明确的原则，对实施TSP的群组及其成员的工作效果提供准确的度量；
• 定期评审的原则，在TSP的实施过程中，对角色和群组进行定期的评价；
• 过程规范的原则，对每一个项目的TSP规定明确的过程规范；
• 指令明确的原则，对实施TSP中可能遇到的问题提供解决问题的指南。

挣值管理方法

项目的挣值管理方法（$\mathrm{EVM}$）是用来客观度量项目进度的一种项目管理方法。它的主要理念是将每项任务赋予一定的价值，如果 $100\mathrm{\%}$ 完成该任务，就获得相应的价值。$\mathrm{EVM}$ 采用进度计划、成本预算和实际成本作为相联系的三个维度，进行项目绩效测量。根据这些因素，我们可以衡量项目的挣值 $\mathrm{EV}$，通过它可以分析项目的进展状况。例如下图项目进展得就相对比较糟糕。

一个进度慢 并且暂时超出预算的项目

几种实现

简单实现：这种方式仅仅关注进度信息。在实现时，首先需要建立 WBS，定义工作范围；其次为 WBS 中每一项工作定义一个价值 $PV$；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为$0-100$ 规则和 $50-50$ 规则，前者只有当某项任务完成时，该任务的 $PV$ 值将转化成 $EV$ 值；后者只需要开始某项任务，即可以赋原 $PV$ 值的 $50\mathrm{\%}$ 作为 $EV$ 值，完成时，再加上另外的 $50$。而实际完成的工作所需成本 $AC$ 不对 $EV$ 值产生任何影响。

中级实现：在简单实现的基础上，加入日程偏差的计算。典型计算方式有：日程偏差 $SV=EV–PV$；日程偏差指数 $SPI=EV/PV$ 等等；

高级实现：在中级实现的基础上，还需要考察项目的实际成本、人员变动、需求变更等诸多复杂因素。

$\mathrm{EVM}$ 这种方式也有一定的局限性。例如，它一般不能应用软件项目的质量管理，并且需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制。此外，$\mathrm{EVM}$ 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。

极限编程

极限编程是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开发实践运用到极致。极限编程的一些有效实践如下：

• 客户代表：客户作为开发团队的成员
• 使用用户素材
• 短交付周期
• 验收测试
• 结对编程：结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
• 测试驱动开发：极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
• 开放的工作空间和隐喻
• 集体所有

极限编程起初具有一个完整的框架，但在实践的不断演化中只剩下了一些有效实践。不过，极限编程的实现催生了 Scrum 的出现，它们的框架高度相似。

SCRUM

Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。它既可以应用于管理软件开发项目，也可以用于运行软件维护团队。传统软件开发迭代速度慢，相当于寻求的是全局最优解；而敏捷开发则是寻求局部最优解，通过迭代的方式逐步优化。从企业的商业目标来看，并考虑到市场等因素的不断变化，敏捷开发的优势就显而易见了。

Scrum 的实践之一是燃尽图，它是用于表示剩余工作量的工作图表，由横轴 $X$ 和纵轴 $Y$ 组成，其中横轴表示时间，纵轴表示工作量。这种图表可以直观的预测何时工作将全部完成，常用于软件开发中的敏捷软件开发方式，也可以用于其他类型的工作流程监控。

SCRUM 燃尽图

移动互联网时代的软件开发

传统软件开发一般由需求、设计、开发和测试的阶段来组成。但这种瀑布模型已经不适用于当下移动互联网时代的开发需要。当下越来越强调交付的重要性，更早的交付往往意味着更多的价值。我们知道摩尔定律是指每过 18 个月，处理器的性能大约每两年翻一倍，同时价格下降为之前的一半。但如果我们以企业的视角重新理解这一定律，就相当于如果 18 个月之后还卖出同样的东西，那么可能收益会降低到原来的四分之一。因此，我们需要引入敏捷和精益的思想来进行软件开发，尽早尽快交付上线。

敏捷思想：更加灵活地响应变化，并更早地实现交付价值。

精益思想：从以资源效率到以流动效率为核心的演进。资源效率一般指各个资源的使用率，其关注点在局部的资源和职能；而流动效率指各个流动单元之间价值流动的速度，其关注点在于整个系统端到端的价值。