课程之外

DevOps

定义

开发运维一体化，是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。

  • 方法论基础是敏捷软件开发，精益思想以及Kanban方法
  • 以领域驱动设计为指导的微服务架构方式
  • 大量虚拟化技术的使用(开发、测试环境)
  • 一切皆服务XaaS的理念指导
  • 构建了强大的工具链，支持水平自动化

DevOps演化的三个阶段（Three Ways）

  • Systems Thinking 充分理解工作流，完成整体产品
  • Amplify Feedback Loops 快速持续反馈
  • Culture Of Continual Experimentation and Learning 培育不断尝试、重复和练习的文化

00 - 开始之前

  • 梳理如下的概念
    1. 软件项目管理
    2. 软件生命过程
    3. 软件过程
    4. 软件过程管理
    5. 敏捷软件开发
    6. CMM/CMMI
    7. 瀑布模型
  • 软件开发四大本质难题永远存在，不可能彻底解决，在不同时期凸显程度有差异。
  • 软件开发本质上是智力劳动，开发者心理方面的因素不可忽视
  • 项目管理是为了降低/减少各种无谓损耗来实现本该有的效能
  • 软件过程改进为了达到更好的效能，这其中质量（缺陷）是首要目标或限制

软件开发的本质难题

  • 复杂性：实体数量众多
  • 不可见性：软件项目是一个逻辑实体
  • 可变性
  • 一致性

严格来说，只有不可见才是真正的“本质”难题，其他三个因项目而异

本课程要回答的十大问题（重要）

  • 软件过程管理和软件项目管理是不是一回事？如果不是，两者差异是什么？
  • 完全是两件不同的事情，没有隶属关系。
  • 软件过程管理类似于流水线升级改造，关注过程本身，如开发工具是否适合。CMMI 主要指导软件过程管理
  • 软件项目管理针对特定的项目目标实现，成本质量（主要是指产品质量）工期等。
  • 管理视角的软件工程是要复制别人的成功。
  • 软件估算过程中，项目经验/历史数据的作用是什么？您的答案经得起细问吗？比如，能具体解释如何把项目经验/历史数据转变成估算结果？估算结果经得起时间考验吗？比如，隔了 3 个月，能保证估算结果一致？

估算要尽可能细地划分，提升对结果的信心；
用相对大小、抽象的描述；
历史数据应该为估算所用，通过适当的加工，提升对结果的信心。

  • 所以，估算究竟追求的目标是什么？

追求的是所有参与者对估算结果的认同，而不是简单追求估算结果客观的正确性，因为客观的正确性是达不到的。
估算本质上是相互讨论、妥协、达成一致的过程。
估算规模与实际规模相近，可以认为估算准确；估算时间与实际时间相近，不一定是估算准确，可能是因为只给了这么多时间。

  • 什么叫做 XX 管理？管理的要素有哪些？如何区分有管理（或者好的管理）还是没有管理（或者不好的管理）？这种判断如果只能事后从结果判断，有意义吗？

管理的三要素：目标、状态跟踪、纠偏措施；
质量管理最难的是状态跟踪。

  • 接上一问题，什么叫做软件质量？当您宣称做了质量管理，实际上真的对质量有管理吗？

绝大多数企业只有质量实践，没有质量管理。
质量路线图告诉我们如何追求高质量

说说敏捷吧。

  • 客户合作胜于合同谈判，您会不先签订合同或类似文件就正式开始项目吗？

  • 可以工作的代码胜过面面俱到的文档，试试二次开发？现如今，从头开始的软件项目还多吗？

  • 个体和互动胜过流程和工具，您试试跟 DevOps 全栈工程师谈谈？当需要服务数亿或者数千万用户的时候，敢脱离过程，甚至简化过程吗？

  • 响应变化胜过遵循计划，这究竟是甲方的想法还是您的想法？请仔细想一下！

  • 当然，我们大可说敏捷宣言并不否认右项价值，那么问题来了，您如何判断右项已经做的足够了所以您可以开始重视左项的价值？

孙子曰：以正合，以奇胜。
好的敏捷是在充分理解了右项之后，在思考计算之后选择了左项。

  • 从没有度量就没有管理/改进，到软件项目度量毫无意义，到包含 2200 多指标项的研发效能度量，到研发效能引发血案，这是想闹哪样？究竟要不要度量？

度量是没有争议的，一定要度量！
错误的做法：直接把别的项目的数据拿过来用。

  • 从极度反对 CMM 到自己搞开发运维一体化成熟度模型，所以，这是成熟度模型的问题？还是其他问题？

只要可以用过程描述的事情，从不成熟到成熟的路线图都是一样的。

  • 定量管理的本质是什么？用数据就是定量管理了？DevOps 模式下，还需要定量管理吗？

一是构造预测模型，二是用预测模型指导项目实践
DevOps 也需要定量管理，而且可以做得更好

  • 关于工程实践。需求分析究竟要解决什么问题？设计究竟要设计什么？测试的目的是什么？为实现这个目的，测试实践的重点应该是什么？

严格区分客户需求和产品需求，前者是问题，后者是解决方案
设计就是要把内部-外部、动态-静态四个象限内容填满。
测试不是提升质量水平的手段，而是帮助掌握质量状态的手段
掌握 Ver & Val：前者关注的是产品需求是否得到体现、从这个产品需求（即解决方案）设计出来，一直到解决方案的开发完成，整个过程当中有没有偏、解决方案有没有被正确地实现出来；后者更多关注的是你的这个客户需求有没有得到满足，简单来说就是客户期望解决的问题，有没有被解决。

软件危机：四大本质难题

软件危机

是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

主要体现有

  1. 软件开发费用和进度失控
  2. 软件可靠性差
  3. 生产出来的软件难以维护
  4. 用户对“已完成”系统不满意现象经常发现

软件工程

是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

两大视角

  1. 管理视角——能否复制成功？
  2. 技术视角——是否可以将问题解决得更好？

软件开发的本质难题

  • 复杂性：实体数量众多
  • 不可见性：软件项目是一个逻辑实体
  • 可变性
  • 一致性

四大本质难题之间的关系

  • 除了不可见性以外，其他三个本质难题因项目而异。
  • 四大本质难题互相促进。
  • 本质难题变化带动软件方法（过程）演变。

软件发展

软件发展的两个趋势

  1. 软件项目规模日益扩大：使得软件越来越难做。
  2. 软件在整个系统中的比重日益增加：将软件质量问题的影响上升到前所未有的高度。

软件发展的三大阶段

  • 软硬件一体化阶段：软件完全依附于硬件，软件作坊（50 年代到 70 年代）

    • 特点：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更
    • 主流开发方法：三思而后行；Code and Fix；编码 + 改错

  • 软件成为独立的产品（70 年代到 90 年代）

    • 特点：摆脱了硬件的束缚(操作系统)、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场的压力
    • 主流开发方法：形式化方法、结构化程序设计和瀑布模型，自顶向下，逐步求精。

  • 网络化和服务化（90 年代中期至今）

    • 特点：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化（SaaS）、进一步的服务化和网络化、盛行开源和共享文化
    • 主流开发方法：
      • 迭代式开发：迭代式（90 年代中后期）大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来交付。
      • 敏捷开发(XP、Scrum、Kanban)
      • 开源软件开发方式
      • DevOps

瀑布模型

1. 其特征是，基本上**顺序的开发流程**以及在每一个阶段采用**先尝试后展开**（即 buildittwice）的开发策略。
2. 每个阶段都**只执行一次**；在各个阶段之间**极少有反馈**。
3. 只有在**项目周期的后期才能看到结果**，所以风险往往至后期的测试阶段才显露，因此失去了及早的纠正过程。
4. 瀑布模型**不是单一模型，是一系列模型**，覆盖最简单场景（过程元素少）到最复杂的场景（过程元素多）
5. 软件项目应该结合实际情况选择合适过程元素的瀑布模型，基本原则是，项目面临困难和挑战越多，选择的模型应该越复杂
6. 软件项目团队往往低估项目的挑战，选择了过于简单的不适用的瀑布模型

alt text

alt text

迭代式模型

开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，迭代模型是类似小型的瀑布式项目(每次迭代中使用瀑布模型)。

  • 一次迭代过程包括了所有软件开发流程。
  • 每一次迭代均产生一个可发布的产品。
  • 该产品为最终产品的一个子集。

软件项目管理

软件项目管理概念（重要）

  • （质量）管理的三大关键要素
    • 目标
    • 状态：是在接近目标还是在远离目标
    • 纠偏
  • 软件项目管理
    • 典型的三大目标：成本、质量、工期
    • 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
    • 包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理，等等
    • 软件项目管理的对象是各类软件项目
    • 可以细分为两种管理视角：软件过程与生命周期模型
      • 软件过程：软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。
      • 生命周期模型：对软件过程的一种人为的划分

软件过程管理

广义软件过程

alt text

理论基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

广义软件过程包括技术、人员以及狭义过程

  • 广义软件过程的同义词：软件开发方法、软件开发过程

    • 净室 Cleanroom 方法、极限编程方法、SCRUM 方法、Gate 方法；Cleanroom 工程过程和 CMM 管理过程互为补充；Cleanroom 比 CMM 更注重质量，更偏向于使用一些数学工具
    • 而更一般的，敏捷软件过程/方法、轻量型过程/方法以及重型过程/方法等描述也是恰当的

  • 生命周期模型（与软件过程区别和联系）：典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等

    • 生命周期模型是对一个软件开发过程的人为划分
    • 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分
    • 生命周期模型往往不包括技术实践

软件过程管理

  • 管理对象是软件过程
  • 管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效（performance）
  • alt text
  • 左侧是软件开发部分，右侧是传统生产部分。
  • 敏捷和计划驱动：敏捷中也需要计划驱动
  • 管理视角的核心问题——能否复制成功？

软件过程管理与软件过程改进

两者意思接近：

  1. 软件过程管理参考模型 CMM/CMMI, SPICE 等
  2. 软件过程改进参考元模型 PDCA，IDEAL

软件过程改进模型

  1. 重点关注“过程质量”，强调“持续改进”
  2. 获得 ISO 9000 标准认证的企业应该具有 CMM 第 2~3 级的水平

软件过程管理/改进模型：CMM

  • 定义：CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
  • 级别：分为五个级别，一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
    alt text
    alt text

等级一：初始级 Initial

  1. 特点：处于该级别的组织基本上没有健全的软件工程管理制度。
    1. 每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理员和一个优秀的软件开发组来做，则可能是成功的。
    2. 大多数的行动知识应付危机，而非事先计划好的任务。通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。
    3. 软件过程完全取决于当前的人员配置，具有不可预测性。
  2. 要精确地预测产品的开发实践和费用之类重要的项目，是不可能的。

等级二：可重复级 Repeatable

  1. 特点：有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验。
    1. 采取了一些措施，这些措施是实现一个完备过程所必不可缺少的第一步。
      1. 典型措施包括：仔细地追踪费用和进度。
      2. 不像第一级那样，在危机状态下才行动，管理人员在问题出现时便可发现，并立即采取修正行动，防止它们变成危机。
    2. 关键一点：没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中财务的措施也可以为未来的项目拟定实现的期限和费用计划。

等级三：已定义级 Defined

  1. 特点：为软件生产的过程编制了完整的文档。
    1. 软件过程管理方面和技术方面已经做了明确的定义，并且按需要不断地改进过程。
    2. 采用评审的方法来保证软件的质量。
  2. 这个级别可以引用 CASE 环境来进一步提高质量和产生率。
  3. 在第一级的过程中，高技术会使得该危机驱动过程更加混乱。

等级四：已管理级 Managed

  1. 特点：公司对每个项目都设定质量和生产目标。
    1. 这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
    2. 利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离。
  2. 统计质量控制措施的一个简单例子：是每千行代码的错误率，相应的目标就是随时间推移减少这个量。

等级五：优化级 Optimizing

  1. 目标：连续地改进软件过程。
    1. 使用统计质量和过程控制技术作为指导。
    2. 从各方面获得的知识将被运用在以后的项目中，从而使软件过程融入正反馈循环，使生产率和质量得到稳步的改进。

软件过程管理/改进模型：CMMI

  • 刻画了软件团队/组织从不成熟到成熟的每个阶段的特征（也就是 roadmap)
  • 等级 2 和等级 3 关注的是当前状态
  • 等级 4 和等级 5 是根据结果（未来）来进行管理

高成熟度的质量管理和低成熟度的质量管理有什么区别？差别在于认定偏差的方式不一样：

2 级、3 级是基于当前已经发生的事实来认定偏差

4 级、5 级是基于模型来预测最终结果，最后根据这个结果来纠正偏差。

alt text

等级一：初始级 Initial

开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行

  1. 软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。
  2. 由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务，项目实施是否成功主要取决于实施人员。

等级二：已管理级 Managed

项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等。

  1. 软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
  2. 软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。
  3. 从 2 级升级到 3 级的原因：固化最佳实践，对小组而言是能够更快地学习其他的做法。

等级三：已定义级 Defined

公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内分享。

  1. 软件组织能够根据自己的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。
  2. 软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。
  3. 科学管理成为软件组织的一种文化，成为软件组织的财富。

等级四：定量管理级 Quantitatively Managed

构建预测模型，已统计过程控制的手段来管理过程

  1. 软件组织的项目管理实现了数字化。
  2. 通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
  3. 在这个级别我们希望能够看到一个预测模型。

等级五：优化级

继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

  1. 软件组织能够充分利用信息资料，对软件项目在项目实施的过程中可能出现的次品予以预防。
  2. 能够主动地改善流程，运用新技术，实现流程的优化。

CMMI好处

  1. 改进进度和预算的可预测性
  2. 改进开发周期
  3. 提高生产率
  4. 改进质量(质量缺陷)
  5. 增加客户的满意度
  6. 提高员工的士气
  7. 增加投资回报和低质量成本

软件过程改进模型：PDCA 模型

步骤：

  1. 分析现状，找出问题
  2. 分析影响质量的原因
  3. 找出措施
  4. 拟定措施计划
  5. 执行措施，执行计划
  6. 检查效果，发现问题
  7. 总结经验，纳入标准
  8. 遗留问题转入下期 PDCA 循环
    alt text

软件过程改进模型：IDEAL 模型

IDEAL 模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL 是代表这五个阶段的单词的首字母。

  • I: Initiating 初始
  • D: Diagnosing 诊断
  • E: Establishing 建立
  • A: Acting 执行
  • L: Leveraging 调整
    alt text

软件过程管理模型：ISO/IEC 1504【SPICE】

  1. 也叫 SPICE（Software Process Improvement and Capability Determination）
  2. 过程类别共有五种，分别是
    1. 客户-供应商（CUS)过程
    2. 工程（ENG）过程
    3. 支持（SUP）过程
    4. 管理（MAN）过程
    5. 组织（ORG）过程

软件过程框架：RUP

  1. Rational 统一过程（Rational Unified Process）
  2. 最佳实践
    1. 迭代式开发
    2. 管理需求
    3. 使用基于构件的体系结构
    4. 可视化建模
    5. 验证软件质量
    6. 控制软件变更
  3. RUP 软件开发生命周期
    1. 初始阶段：建立业务模型，定义最终产品视图，并且确定项目的范围
    2. 精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需
    3. 构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能
    4. 移交阶段：把开发的产品提交给用户使用

软件质量大师的主要观点和贡献、工作

Shewhart

  1. 最早将统计控制的思想引入质量管理，是质量改进奠基人;
  2. 提出 **PDS 模型（计划执行检查 Plan-Do-See)**，后被戴明进一步发展为 PDCA。

Humphrey 软件过程之父

  1. 采用 Crosby 的成熟度度量，提出了软件能力成熟度模型（CMM) ，对于软件过程管理与改进具有建设性作用。
  2. 将上述的理论和实践引入软件过程。

软件开发实践

敏捷软件开发

敏捷中也有计划驱动

敏捷目的

为了使软件开发团队具有高效工作和快速响应变化的能力

敏捷原则

  • 最重要的是通过尽早和不断交付有价值的软件满足客户需要
  • 欢迎需求的变化
  • 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好
  • 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
  • 最好的信息传达方式是面对面的交谈

敏捷宣言

  1. 个体和互动 胜过 流程和工具
  2. 可以工作的软件 胜过 详尽的文档
  3. 客户合作 胜过 合同谈判
  4. 响应变化 胜过 遵循计划
  5. 尽管右项有价值，但是我们更重视左项的价值

敏捷软件开发方法

极限编程 XP

eXtreme Programming，极限的含义是指把好的开发实践运用到极致

  • 极限编程的有效实践
    1. 客户作为开发团队的成员 —— 客户代表
    2. 使用用户素材
    3. 短交付周期
    4. 验收测试
    5. 结对编程——结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
    6. 测试驱动开发——极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
    7. 集体所有
    8. 持续集成
    9. 可持续的开发速度 <=40h/week
    10. 开放的工作空间
    11. 重构
    12. 使用隐喻

Scrum

迭代式增量软件开发过程：
alt text

  • Scrum 中的文档
    1. 产品订单（product backlog)：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
    2. 冲刺订单（sprint backlog)：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
      1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
      2. 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog)，这意味着在一个冲刺中需求是被冻结的。
      3. 任务被分解成以小时为单位的任务，每一个任务不超过16h，否则将被进一步分解。
      4. 任务不是由主管分配，而是由团队成员签名认领。
    3. 燃尽图（burn down chart)：公开展示的图表
      1. 显示当前冲刺中未完成的任务数目，或者在冲刺订单上未完成的订单项的数目。
  • Scrum 中角色
    1. 产品负责人，代表利益所有者
      1. 产品负责人的职责是将开发团队开发的产品价值最大化。
      2. 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
        1. 清晰地表述产品待办列表项；
        2. 对产品待办列表项进行排序，使其最好地实现目标和使命；
        3. 优化开发团队所执行工作的价值；
        4. 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
        5. 确保开发团队对产品待办列表项有足够深的了解。
    2. Scrum Master，类似于项目经理，负责维护过程和任务
      1. 促进和支持 SCRUM
      2. 帮助每个人理解 SCRUM 理论、实践、规则和价值
      3. SCRUM Master 是一位服务型领导。
        1. 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的
        2. 改变 SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团队所创造的价值。
      4. Scrum Master 服务于产品负责人，包括：
        1. 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
        2. 找到有效管理产品待办列表的技巧；
        3. 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
        4. 理解在经验主义的环境中的产品规划；
        5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
        6. 理解并实践敏捷性；
        7. 以及，当被请求或需要时，引导 Scrum 事件。
      5. Scrum Master 以各种方式服务于开发团队，包括
        1. 作为教练在自组织和跨职能方面给予开发团队以指导；
        2. 帮助开发团队创造高价值的产品；
        3. 移除开发团队工作进展中的障碍；
        4. 按被请求或需要时，引导 Scrum 事件；以及，
        5. 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
      6. Scrum Master 以各种方式服务于组织，包括：
        1. 带领并作为教练指导组织采纳 Scrum；
        2. 在组织范围内规划 Scrum 的实施；
        3. 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
        4. 引发能够提升 Scrum 团队生产率的改变；以及，
        5. 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
    3. 开发团队
      1. 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
      2. 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：
        1. 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
        2. 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
        3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
        4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
        5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
  • Scrum常见活动
    • Sprint Planning Meeting 冲刺计划会议：在每个冲刺之初，由产品负责人讲解需求，每日开发团队进行估算
    • Daily standup meeting 每日站立会议：一般只有15min
    • review meeting 评审会议：冲刺结束前，给产品负责人演示并接受评价的会议
    • retrospective meeting 回顾会议：冲刺结束后召开的关于自我改进的会议。
    • sprint 冲刺：周期通常 2~4 周。
  • Scrum VS. XP
    1. 迭代周期不同。XP 迭代周期为 12 周，而 Scrum 迭代周期为 24 周
    2. 迭代中是否允许需求变更。XP 中只要变更需求与原需求所需时间资源相等即可变更，而 Scrum 在迭代中需求被冻结
    3. 迭代中，需求是否严格按照优先级来实现。XP 中务必遵守优先级别，Scrum 中则比较灵活，原因是可能有需求依赖问题
    4. 过程工程化。Scrum 开发过程并未工程化，要求开发者自觉保证，但 XP 则对开发流程定义严格，例如 TDD，结对编程，重构等

看板方法

  • 精益生产（丰田制造法）的具体实现
  • 可视化工作流、限定 WIP（Work In Progress）、管理周期时间
  • 马丁提出了微服务架构

TSP团队软件过程

团队动力学

自主团队

自主团队定义：一个团队必须包括至少两个成员，他们为了共同的目标和愿景而努力工作，他们每个人都有明确的角色和相应的职责定义，任务的完成需要团队成员互相依赖和支持。

具备如下特点：

  • 自行定义项目的目标
  • 自行决定团队组成形式以及成员的角色
  • 自行决定项目的开发策略
  • 自行决定项目的开发过程
  • 自行制定项目的开发计划
  • 自行度量、管理和控制项目工作

自主团队的必要性：

  • 自主团队可以形成“胶冻态团队”。在这样的团队中存在一种神奇的力量，这种神奇力量弥漫于该团队做的所有工作
  • 团队成员互相支持，更为重要的是，团队成员在任何时刻都知道应该以怎样的方式帮助别人;团队成员相互信任，有强烈的归属感
  • 团队在适当的知道会聚集在一起，研究现状，讨论策略。

自主团队的形成：

  • 自主团队不是偶然形成的。
  • 大部分情况下，在团队建立之初，团队成员往往有着不同的目标;缺乏清晰的角色定义和职责安排。对于待开发的产品只有模糊的概念;团队成员也有着不同的工作习惯和工作方法。
  • 经过一段时间的协同工作，团队成员可以慢慢培养团队协作方式，从而逐渐演化成自主团队。

自主团队的外部环境：

  • 项目启动阶段获得管理层的支持
    1. 项目小组应当表现出已经尽最大的可能在满足管理层的需求的工作态度。
    2. 项目小组应当在计划中体现定期需要向管理层报告的内容。
    3. 项目小组应当向管理层证明他们所制定的工作计划是合理的。
    4. 项目小组应当在项目中体现为了追求高质量而开展的工作。
    5. 项目小组应当在工作计划中允许必要的项目变更。
    6. 项目小组应当向管理层寻求必要的帮助。
  • 在项目进展过程中获得管理层的支持
    1. 项目小组应当严格遵循定义好的开发过程开展项目开发过程。
    2. 项目小组应当维护和更新项目成员的个人计划和团队计划。
    3. 项目小组应当对产品质量进行管理。
    4. 项目小组应当跟踪项目进展，并定期向管理层报告。
    5. 项目小组应当持续地向管理层展现优异的项目表现。

激励方式

  • 威逼：完全依靠不同角色的等级关系，通常是上级强制要求下属必须完成某些工作。
  • 利诱：通过许诺一定的好处来吸引下属努力工作
  • 鼓励承诺：
    1. 建立承诺文化，利用软件工程师希望得到别人尊重的心理，鼓励他们合理承诺并努力满足承诺，从而得到别人的尊重。
    2. 位于马斯洛需求理论的 4 级以上，应当是主要的方式，并且最好以团队为单位做出承诺
交易型领导方式
  • 承诺奖励激励
  • 人们通常能找到新的方式来获得奖励，同时少做工作。
  • 威逼和利诱属于交易型领导方式。
转变型领导方式
  • 用成就激励
  • 鼓励承诺属于转变型领导方式。
  • 由于交易型领导方式很少能产生成功并且有创造性的团队，因此转变型领导方式是首选。

维持激励水平

维持激励需要及时的绩效反馈。这些反馈包括：

  • 根据一个详细计划衡量进度

  • 当前计划不准确时重做计划。

  • 为漫长而富有挑战性的项目提供中间反馈，即里程碑。

    【编写代码时：执行单元测试前，阅读代码查找错误，可以保证错误更少，总体消除缺陷的代价更低。】

    【有反馈的更容易愿意加班。】

激励水平的重要影响因素：

  • 回报：回报越大，激励水平越高
  • 期望：完成这件事情的把握多大，把握越大，激励水平越高

承诺文化的建立与团队激励

  • 在个人级别，承诺有很大差异

    1. 有些人对承诺非常认真
    2. 有些人对承诺非常轻率。

  • 在满足以下条件下，团队承诺比个人承诺的激励作用更大

    1. 所有团队成员共同参与作出承诺。
    2. 团队依赖于每一位成员履行自己的承诺。
    3. 如果有计划在支撑承诺，那么就更为可信

  • 软件开发团队在制定承诺时

    1. 需要保证承诺是自愿的、公开的、可信（行）的，向团队做出承诺。
    2. 承诺需要有详细计划支撑
    3. 开发者需要参与承诺的协商和设计。

  • 除了以团队形式作出承诺以外，承诺文化的建立还要求在项目进行过程中维持承诺水平。

    1. 及时提供各种反馈信息是维持承诺的有效手段。
    2. 反馈信息包括项目进度、更新后的项目计划以及里程碑实现情况等。

leader 和 manager 的区别

alt text

  • 知识工作者的管理需要的是领导者而不是经理。领导者需要具有的品质和特点：
    • 诚实（Honest）：领导者应该信守承诺，言行一致，让团队成员感到信任和尊重。
    • 能力（Competent）：领导者必须展现出卓越的能力和广泛的知识。
    • 远见（Visionary）：知识工作者倾向于寻求发展和创新。领导者需要能够超越眼前的挑战和任务，具备明确和可信的未来愿景。这种远见不仅包括对技术和行业趋势的理解，还包括对组织发展方向的清晰认识。
    • 激励（Inspirational）： 优秀的知识工作者领导者应该能够激励团队，传播积极、充满热情和能量的未来愿景。

马斯洛的需求层次理论

alt text

  • 共有五个层次：

    • 自我实现（Self-Actualization)
    • 获得尊敬（Esteem)
    • 爱和归属感（social)
    • 安全感（Safety)
    • 生理需求（Physiological)

  • 注意：

    • 自我实现是最高的层次。
    • 激励来自为没有满足的需求而努力奋斗。
    • 低层次的需求必须在高层次需求满足之前得到充分满足。
    • 满足高层次的需求的途径比满足低层次的途径更为广泛。

  • 威逼利诱比较低层，鼓励承诺在 4-5 层，效果比较好

海兹伯格的激励理论

  • 激励因素（内在因素）：成就感、责任感、晋升、被赏识、认可。
  • 保健因素（外在因素）：工作环境、薪金、工作关系、安全等。

麦克勒格的 X、Y－理论

麦克勒格的 X－理论：人性本恶，独裁式的管理风格

  • 不喜欢他们的工作并努力逃避工作
  • 缺乏进取心，没有解决问题与创造的能力
  • 更喜欢经常的指导，避免承担责任，缺乏主动性
  • 自我中心，对组织需求反应淡漠，反对变革
  • 用马斯洛的底层需求（生理和安全）进行激励

麦克勒格的 Y-理论：人性本善，民主式的管理风格

  • 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
  • 具有创造力，想象力，雄心和信心来实现组织目标
  • 能够自我约束，自我导向与控制，渴望承担责任
  • 用马斯洛的高层需求（自尊和自我实现）进行激励

期望理论 Expectancy Theory

  • 人们在下列情况下能够收到激励并且产生出大量成果 M = V × E
    1. 相信他们的努力很可能会产生成功的结果（V）
    2. 相信自己因为成功而得到相应的回报（E）
  • Motivation = Valence × Expectancy(Instrumentality)，即激发力量 = 效价 × 期望值
    1. M 表示激发力量，是指调动一个人的积极性，激发人内部潜力的强度。
    2. V 表示目标价值（效价），这是一个心理学概念，是指达到目标对于满足他个人需要的价值。同一目标，由于各个人所处的环境不同，需求不同，其需要的目标价值也就不同。同一个目标对每一个人可能有三种效价：正、零、负。效价越高，激励力量就越大
    3. E 是期望值，是人们根据过去经验判断自己达到某种目标的可能性是大还是小，即能够达到目标的概率。目标价值大小直接反映人的需要动机强弱，期望概率反映人实现需要和动机的信心强弱。

提高成功把握的两种方法

  • 现实扭曲力场（乔布斯传）
    • 现实扭曲力场是指乔布斯和他的团队常常利用一种积极、强大的影响力来推动和实现他们的愿景和目标。这种方法的核心在于改变周围人们的看法和期望【激励团队和合作伙伴】，以便实现看似不可能的事情。
  • 数据

TSP对自主团队的支持

alt text
alt text

TSP的经典角色

项目组长

项目组长的目标和衡量指标

  • 项目组长应当建设和维持高效率的团队。
  • 项目组长应当激励团队成员积极工作。
  • 项目组长应当合理处理团队成员的问题。
  • 项目组长应当向管理层提供项目进度相关的完整信息。
  • 项目组长应当充当合格的会议组织者和协调者。

【典型技能】

  • 你是天生的领导者
  • 你有能力识别问题的关键并且做出客观的决策
  • 你不介意偶尔充当“恶人”
  • 你尊敬你的团队成员

【工作内容】

  • 激励团队成员努力工作
  • 主持项目周例会
  • 每周汇报项目状态
  • 分配工作任务
  • 维护项目资料
  • 组织项目总结
计划经理

  • 开发完整的、准确的团队计划和个人计划

  • 每周准确的报告项目小组状态

【典型技能】

  • 最为重要的一点是，你做事有条理和逻辑
  • 你对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前状况
  • 你认为计划非常重要，也愿意要求团队成员跟踪和度量他们的工作

【工作内容】

  • 带领项目小组开发项目计划
  • 带领项目小组平衡计划
  • 跟踪项目进度
  • 参与项目总结
开发经理
  • 开发优秀的软件产品
  • 充分利用团队成员的技能

【典型技能】

  • 你喜欢创造事物
  • 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作
  • 你具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作
  • 你熟悉主流的设计工具
  • 你愿意倾听和接受其他人的设计思想

【工作内容】

  • 带领团队制定开发策略。
  • 带领团队开展产品规模估算和所需时间资源的估算。
  • 带领团队开发需求规格说明。
  • 带领团队开发高层设计。
  • 带领团队开发设计规格说明。
  • 带领团队实现软件产品。
  • 带领团队开展集成测试和系统测试。
  • 带领团队开发用户支持文档。
  • 参与项目总结
质量经理
  • 项目团队严格按照质量计划开展工作，开发出高质量的软件产品
  • 所有的小组评审工作都正常开展，并且都形成了评审报告

【典型技能】

  • 你关注软件产品的质量
  • 你有评审方面的经验，熟悉各种评审方法
  • 你有协调组织有效评审的能力

【工作内容】

  • 带领团队开发和跟踪质量计划
  • 向项目组长警示质量问题
  • 软件产品提交配置管理之前，对其进行评审，以消除质量问题
  • 项目小组评审的组织者和协调者
  • 参与项目总结
过程经理
  • 所有团队成员准确的记录、报告和跟踪过程数据。
  • 所有的团队会议都有相应会议记录。

【典型技能】

  • 你对过程定义、过程度量非常感兴趣
  • 你对过程改进非常感兴趣

【工作内容】

  • 带领团队定义和记录开发过程并且支持过程改进。
  • 建立和维护团队的开发标准。
  • 记录和维护项目的会议记录。
  • 参与项目总结。
支持经理
  • 项目小组在整个开发过程中都有合适的工具和环境。
  • 对于基线产品，不存在非授权的变更。
  • 项目小组的风险和问题得到跟踪。
  • 项目小组在开发过程中满足复用目标。

【典型技能】

  • 你对于各种开发工具很感兴趣，熟悉各类工具的适用场合。
  • 你对版本控制工具很熟悉，也熟悉配置管理流程。
  • 对于本项目所有工具而言，你都是专家。

【工作内容】

  • 带领团队识别开发过程中所需要的各类工具和设施。
  • 主持配置管理委员会，管理配置管理系统。
  • 维护软件项目的词汇表。
  • 维护项目风险和问题跟踪系统。
  • 支持软件开发过程中复用策略的应用。
  • 参与项目总结。
开发人员

估算

PSP 和 PROBE

  • 规模度量/估算的困境
  • 以 LOC VS. FP 为例
    1. 精确度量方式往往不便于早期规划/估算；
    2. 有助于早期规划/估算的度量往往难以产生精确度量结果；
  • PROBE（PROxy Based Estimation）的作用：精确度量和早期规划之间的桥梁

PROBE估算流程

alt text

基本原理

  • 设立合理的代理作为精确度量和早期规划需要的度量之间的桥梁

  • 相对大小，而非绝对大小

概要设计

  • 估算的第一步是做出一个概要设计：

    1. 概要设计不是真实设计
    2. 与已有产品/组件 相关联
    3. 定义能够产生期望功能的产品元素
    4. 估算你计划构造之物的规模

  • 对于大多数的项目，概要设计都应相对较快地完成：例如，1000LOC 以内程序，试着将概要设计时间限制在 10 到 20 分钟之内

  • 为了做出概要设计，需要确定产品功能，以及产生这些功能所需的程序组件/模块：“如果我有以下这些部件，我可以构造这个产品。”

  • 然后，将这些程序组件/模块与你以前写的程序相比较，估算它们的规模

  • 最后，将程序组件/模块估算综合给出总规模

代理识别

代理识别是指根据概要设计的结果，为每一块“积木”指定合适的类型，定义合适的相对大小，从而确定其规模。为了完成该工作，首先得选择一个合适的代理作为估算的基础。这样的代理需要满足：

  • 与软件开发所需资源有着很好的相关性；
  • 在项目的早期便于估算者建立直观的概念。

整合多个估算结果

整合一个开发人员做的多个估算：

  • 累积各个部分的估算
  • 进行一次线性回归计算
  • 计算一个预测区间

多个开发人员可以整合独立进行的估算，通过以下方式：

  1. 进行单独的线性回归预测
  2. 将计划的规模或者时间相加
  3. 将个人范围的平方相加，再对其计算平方根获得预测区间

估算误差：示例

  • 对于一项估算精度为 ± 50%的 1000 小时的工作，估算范围就是从 500 到 1500 小时。
  • 如果估算被分成独立的 25 个部件，每个存在 50%的误差，那么
    1. 总时间会和前面一样是 1000 小时
    2. 估算范围会是从 900 到 1100 小时
  • 当估算多个部件时，总的误差会比各个部件误差的总和要小。
    1. 误差趋于抵消了
    2. 假设没有共同的偏差
  • 估算要点之一：尽可能划分详细一些

SCRUM 中的 Story point

度量实现一个故事（Story）需要付出的工作量，估计实现一个或多个用户故事的复杂度。

  • 抽象的：混合了对于开发特性（feature）所要付出的努力、开发复杂度、个中风险以及类似东西
  • 相对的：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
    1. Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
    2. 拆分
  • 估算要点之二：建立对结果的信心
  • 估算要点之三：依赖数据

故事点的数值采用斐波那契数：为了避免过度精细化的估算，团队可以更轻松地识别差异并定义每个故事点的复杂性。当使用相近的数字估算时，不容易区分，会增加团队达成共识的成本。

关于估算方法的反思

估算的目标：规模估算 VS. 时间估算——估算结果重要吗？

  • 估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

怎么做估算？

  • 达成共识
  • 建立信心
    1. 足够详细
    2. 依赖数据
    3. 最好的猜测（注意检验猜测所依据的假设）

估算的要点

  • 估算要点之一：尽可能划分详细一些
  • 估算要点之二：建立对结果的信心
  • 估算要点之三：依赖数据
  • 估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

历史数据的获取——度量

关于度量的争议：度量体现着决策者对试图要实现的目标的关切程度

GQM 和 GQM+度量体系构建：GQM 是对应三个部分

PSP 基本度项：

  • 规模
  • 时间
  • 缺陷
  • 日程（TSP）

用户和高层关心的问题：什么时候完成、质量怎么样、成本怎么样

PSP 时间度量（时间日志）

alt text

PSP 缺陷度量（缺陷日志）

alt text

历史数据的处理

  • 简单方法：计算简单，但是，不稳定
    • 选择最小值作为 VS；
    • 选择最大值作为 VL；
    • 选择中值作为 M；
    • 选择 VS 与 M 的均值作为 S；
    • 选择 VL 与 M 的均值作为 L。
  • 正态分布法：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵
    • 选择所有数据的均值作为 M，计算所有数据的标准差 σ。
    • 那么 S = M-σ ，VS = M-2σ ，L = M+σ ，VL=M+2σ
  • 对数正态分布：更加符合人们对于程序的规模的直观感觉
    • 以 e 为底计算所有数据的自然对数；
    • 计算取对数之后的值的均值作为 M，计算相应标准差 σ。
    • 那么 S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ 。
    • 取反对数；

相关性

  • PROBE 方法依赖历史数据，但是实际历史数据有可能

    1. 历史数据少于 3 个数据点；
    2. 有足够的历史数据，但是数据的质量不高

  • 相关性描述的是两组变化的数据之间相互关联的程度;

  • 一般情况下，为确保估算质量，对于历史数据的相关性要求 r≥0.7。
    alt text

  • 显著性

    1. 它描述的是上述两组数据的相关关系出现的偶然性
    2. 因此，显著性越小越好。软件工程很多场合下要求显著性 s≤0.05（即所谓 p 值）

计划和跟踪

工作分解结构（Work Breakdown Structure，WBS）

WBS 定义：

  • WBS 作用
  • 范围基线
  • 提供整体观
  • 不遗漏可交付物
  • 明确各个角色的责任
  • 工作包定义
  • 估算和计划的基础
  • 理解工作，分析风险

WBS 示例：
alt text

创建 WBS 方法

  • 识别和分析可交付成果及相关工作；
  • 确定工作分解结构的结构与编排方法；
  • 自上而下逐层细化分解；
  • 为工作分解结构组成部分制定和分配标志编码；
  • 核实工作分解的程度是必要且充分的。

开发策略与计划

开发策略是在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略。

注意事项：

  • WBS 的使用
  • 产品组件开发顺序的考虑
  • 产品组件获得方式的考虑

过程架构-生命周期模型

alt text

通用计划框架

alt text

  • 上述框架中，那些步骤必须人为的干预

    1. 定义需求
    2. 概要设计：划分由人为开始，规模划分好之后估算是自动产生的
    3. 日程计划

  • 这会带来什么的好处？比较容易扛住别人的质疑。

    1. 攻击点：资源和时间是否被高估了
    2. 解决：估算没有代码行 PROBE 只有功能点是大中小。

  • PROBE方法是基础

规模估算

参考历史数据库中的规模数据或者估算者所能做的最好猜测，估算待开发产品的规模。在估算的时候要注意使用合适的方法。

资源估算

这里的资源主要指人力资源，视待开发产品的规模以及历史数据库中生产效率数据的内容，往往用人月、人天或者人时这样的单位。

开发产品

开发产品的具体方法视项目不同有显著的差别。这里需要讨论的是在开发过程中的数据记录。在这个计划框架中，规模的历史数据和时间的历史数据是支持PROBE方法的基础。这些数据既可以作为历史数据供参考，同时也是进行项目跟踪与管理决策的依据。

日程计划原理和方法

将资源需求映射到一个实际的日常计划上来。

制定任务计划和日程计划：前者描述项目所有的任务清单，任务之间的先后顺序、以及每个任务所需时间资
源，后者描述了各个任务在日程上的安排，哪天开始哪天结束;

  • 任务计划和日程计划
  • 典型计划流程回顾
    1. 估算规模
    2. 估算资源
    3. 规划日程
  • 考虑假期的影响：时间计划和工作计划并存。
任务清单
任务需要时间资源（小时）累计时间资源（小时）
A22
B35
C38
D412
E618
F220
G727
资料清单
日期（第 X 天）时间资源（小时）累计时间资源（小时）
144
248
3412
4416
5420
6424
7428
日程计划
任务需要时间资源（小时）累计时间资源（小时）完成时间（第 X 天）
A221
B352
C382
D4123
E6185
F2205
G7277

质量计划原理和方法

  • 项目的质量计划中应当确定需要开展的质量保证活动。
  • 典型的质量保证活动包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等。
  • 在质量计划中需要解决的关键的问题是该开展哪些活动，以及这些活动开展的程度，如时间、人数和目标分别是什么。

风险计划

  • 风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。
  • 风险管理大致分成两部分，即风险识别和风险应对。
风险识别

风险：没有发生，有一定概率发生，发生后有一定影响，才是风险。

问题：已经发生的，比如人员调动等

  • 识别与成本、进度及绩效相关的风险
  • 审查可能影响项目的环境因素
  • 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑
  • 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑
  • 记录风险的内容、条件及可能的结果
  • 识别每一风险相关的干系人
  • 利用已定义的风险参数，评估已识别的风险
  • 依照定义的风险类别，将风险分类并分组
  • 排列降低风险的优先级
  • 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭
  • [P（可能性）, I（影响程度）, T（阈值）]
风险应对

识别风险之后，就应当制定相应的风险管理策略，以应对各类风险。

典型的策略包括：

  1. 风险转嫁
  2. 风险解决
  3. 风险缓解
计划评审和各方承诺

项目各项计划完成之后，需要与各类计划的相关干系人开展评审工作，解决计划中相互矛盾与不一致的地方，并获得参与项目的各方对项目计划的承诺。

  1. 识别每一项计划所需支持，并与相关干系人协商承诺。
  2. 记录所有的承诺，包括完整的承诺和临时的承诺，并确保由适当层次的人员签署。
  3. 适时与资深管理人员一起审查承诺。

项目跟踪意义

  • 在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施。
  • 项目进度滞后与否需要参照物，即项目计划。
  • 项目跟踪需要管理针对偏差而采取的纠偏措施。

挣值管理方法 EVM

  • 项目的挣值管理方法（Earned Value Management，简称 EVM）是用来客观度量项目进度的一种项目管理方法。

    • 每项任务实现附以一定价值（credit）

    • 100% 完成该项任务，就获得相应价值

  • EVM 采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。

  • EVM 只进行进度和成本管理，与质量无关。

这套方法直接应用到软件项目中会存在问题。

在软件项目中，计划投入的时间作为挣值比较合适。

EVM 的三种实现

  • 简单实现：这种方式仅仅关注进度信息。在实现时，
    • 首先需要建立 WBS，定义工作范围；
    • 其次为 WBS 中每一项工作定义一个价值（PV）；
    • 最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为 0-100 规则和 50-50 规则，前者只有当某项任务完成时，该任务的 PV 值将转化成 EV 值；后者只需要开始某项任务，即可以赋原 PV 值的 50%作为 EV 值，完成时，再加上另外的 50%。而实际完成的工作所需成本 AC 不对 EV 值产生任何影响。
  • 中等实现：在简单实现的基础上，加入日程偏差的计算。典型计算方式有：
    • 日程偏差 SV = EV – PV；
    • 日程偏差指数 SPI = EV/PV；
  • 高级实现：在中级实现的基础上，还需要考察项目的实际成本。

EVM 图示

alt text

  • 上面的线是为了获取这些挣值付出的实际代价，这个线和挣值之间的差异是成本差异。
  • 中间的线是预算（每天需要完成多少挣值）BAC，理想情况下是一条直线。
  • 下面的线是挣值（实际的进展情况）（EV），和 owner value 有关，对应 plan value
  • 实际获取挣值和预计获取挣值的差异是进度差异。【SV = EV - PV】

例子：

  1. 一共 100 个值（计划投入时间），第一天需要完成 50 个值，第二天需要完成 20 个值，第三天需要完成 30 个值。
  2. BAC：第一天 50，第二天 70，第三天 100.
  3. 超期情况，EV：第二天 50 值，AC：第二天 100 值。
    1. 这就意味这这两天投入了 100 个值完成了原计划用 50 个值完成的工作，这就对应着进度落后，成本超支。
    2. CV = 50，SV = 20
  4. 有可能出现第二天用户说，任务 B 和任务 C 不做了（项目进度落后变为了项目进度正常）
  • 挣值管理会带来什么好处？可以很好的适应项目的动态变化。

常用的 EVM 度量

  • BAC 表示按照 PV 值的曲线，当项目完成的时候所需预算或者时间
  • 成本差异 CV = EV-AC
  • 成本差异指数 CPI = EV/AC
  • 日程偏差 SV = EV–PV
  • 日程偏差指数 SPI = EV/PV
  • 预计完成成本 EAC = AC + (BAC - EV) / CPI = BAC / CPI，如果同时考虑日程偏差指数：EAC = [AC + (BAC - EV) / (CPI × SPI)]

EVM 应用示例（讨论）

alt text

  • Plan（计划投入时间），Actual（实际投入时间）
  • 虽然现在没有落后，但是暴露了隐患

另外一种 EVM 的变形——燃尽图

alt text

  • 燃尽图是简单的挣值管理的变形。
  • 他是剩下的工作占的百分比。

EVM 的局限性

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

质量管理

质量策略

质量概念

  • 软件质量为“与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体”。
  • 软件质量为内外两部分的特性：其外部质量特性面向软件产品的最终用户，其内部质量特性则不直接面向最终用户。
  • 软件质量为软件产品可以改变世界，使世界更加美好的程度。从用户的角度考察软件质量，用户满意度是最为重要的判断标准。
  • 软件质量为对人（用户）的价值。这一定义强调了质量的主观性，即对同一款软件而言，不同的用户对其质量有不同的体验。

质量管理的挑战：三要素

  • 目标
  • 状态：是在接近目标还是在远离目标
  • 纠偏

面向用户的质量观

PSP 中也采用了面向用户的视图，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：

  • 用户究竟是谁？
  • 用户需求的优先级是什么？
  • 这种用户的优先级对软件产品的开发过程产生什么样的影响？
  • 怎样来度量这种质量观下的质量水平？

典型用户质量期望

  • 这款软件产品必须能够工作
  • 这款软件产品最好有较快的执行速度
  • 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异；

个人软件过程（PSP）质量策略

  • 用缺陷管理来替代质量管理；
  • 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷；
  • 各个组件的高质量是通过高质量评审来实现的；
    • PSP 质量策略主要解决的是外部质量，而非内部质量；PSP 使用面向用户的视图，主要解决外部质量。

不同缺陷消除方式消除缺陷的效率

编译是最高效的缺陷消除手段

alt text

测试消除缺陷的典型流程

  • 发现待测程序的一个异常行为；
  • 理解程序的工作方式；
  • 调试程序，找出出错的位置，确定出错原因；
  • 确定修改方案，修改缺陷；
  • 回归测试，以确认修改有效；

评审发现缺陷典型流程

  • 遵循评审者的逻辑来理解程序流程；
  • 发现缺陷的同时，也知道了缺陷的位置和原因；
  • 修正缺陷；
  • 重要的缺陷关注：注入阶段、消除阶段和根本原因。

PSP 评审过程质量 评审检查表

  • 质量控制指标
  • 其他因素
    1. 环境
    2. 评审时机
    3. 个人评审和小组评审
    4. 缺陷预防
  • 个人级别：单元测试和 code review，code review 优先
    1. 通过评审消除错误所需要的时间更少一些。
    2. 如果测试完成后再进行评审可能就没有那么认真进行评审。

评审的其他考虑因素

打印后评审往往效果更好：

  1. 单个屏幕可以展现的内容比较有限
  2. 评审人员的注意力

评审时机选择：编译（UT）之前 VS. 之后

个人评审和小组评审：

  1. 小组评审意义
  2. 先后顺序

质量指标

质量指标之一：Yield

Yield 指标用以度量每个阶段在消除缺陷方面的效率。

  • Phase Yield = 100 ×（某阶段发现的缺陷个数）/（某阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数）
  • Process Yield = 100 × （第一次编译前发现的缺陷个数）/（第一次编译前注入的缺陷个数）

只能预测，不能度量；因为无法得知注入缺陷数目。

缺陷在开发过程中注入和消除的示意图

alt text

例子
  • Yield 体现缺陷消除的效率问题
    1. 上游的问题可以引发更多的问题。
    2. 不能确定单元测试后是否有错误，不可知。
  • IBM：最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现（所以最后的 Yield 的值为 50），修改后如下（没有发现的也按照原本的比例来分）
阶段注入缺陷数消除缺陷数遗留缺陷数Yield（%）
设计100100
设计评审04640
编码202241/13 100
代码评审0121250
单元测试0120100

以上图为例：Process Yield = 100 × (17 / 26) = 65.4。如果采取的开发环境不需要编译阶段，那么 Process Yield 的计算方法就修改成第一次单元测试前发现的缺陷个数 占 第一次单元测试前注入的缺陷个数的比例

从上表估算后：

阶段注入缺陷数消除缺陷数遗留缺陷数Yield（%）
DFD10+40140
DFD REVIEW04102/7 100
CODING20+82362/19 100
CODE REVIEW012121/3 100
UNIT0121250
估算交付物缺陷数——过程建模示例

alt text

质量指标之二：质检失效比 A/FR

  • 失效成本：分析失效现象、查找原因、做必要的修改所消耗的成本。
  • 质检成本：评价软件产品，确定其质量状况所消耗的成本。
  • PSP 中定义的 失效成本 为 编译时间和单元测试时间 之和。
  • PSP 中定义的 质检成本 为 设计评审时间与代码评审时间 之和。

A/FR = PSP 质检成本 / PSP 失效成本，用来测量在第一次编译前花在查找缺陷上的时间的相对值。可用复查时间 /（编译+测试）时间来计算。能很好地指示测试中发现缺陷的可能性。

  • 当 A/FR<1 时，程序测试一般会发现很多错误；
  • 当 A/FR>2 时，测试阶段发生的缺陷数较少，过程产生无缺陷的可能性更大。
  • A/FR 的值对于小的独立的产品通常比 2.0 要大；A/FR 的值对于相对大的产品等于 1.0 较为合适。
    alt text
A/FR 控制目标
  • 理论上，A/FR 的值越大，往往意味着越高的质量。
  • 过高的 A/FR 往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在 PSP 中 A/FR 的期望值就是 2.0

质量指标之三：过程质量指标 PQI

用以度量 PSP 过程的整体质量

  • 可以度量，可以预测

5 个过程质量指标 的乘积：

  • 设计质量：设计的时间应该大于编码的时间，设计时间编码时间 min{设计时间/编码时间, 1}
  • 设计评审质量：设计评审的时间应该**大于设计时间的 50%**，设计评审时间设计时间 min{2×设计评审时间/设计时间, 1}
  • 代码评审质量：代码评审时间应该**大于编码时间的 50%**，代码评审时间编码时间 min{2×代码评审时间/编码时间, 1}
  • 代码质量：代码的编译缺陷密度应当小于 10 个/千行，编译缺陷密度 min{20/(编译缺陷密度+10), 1}
  • 程序质量：代码单元测试缺陷密度应当小于 5 个/千行，单元测试缺陷密度 min{10/(单元测试缺陷密度+5), 1}

PQI 越大，表示上面五个“应该”满足地越好，缺陷也就越少。

PQI 超过 0.4 即可。过大成本太高；

PQI 可以用作质量规划和过程改进

PQI的作用
  • 判断模块质量
  • 评估项目质量
  • 为软件改进做依据
PQI 与交付后缺陷密度的关系

alt text

PQI 与集成时缺陷数的关系

alt text

质量指标之四：Review Rate

  • 评审的速度（Review Rate）是一个用以指导软件工程师开展有效评审的指标
  • 高质量的评审需要软件工程师投入足够的时间进行评审
  • 在 PSP 的实践中，代码评审速度小于 200 LOC/小时，文档评审速度小于 4 Page/小时

估算：

  1. 估算文档数量
  2. 估算代码数量
  3. 估算评审时间等等

质量指标之五：缺陷消除效率比 DRL

  • 缺陷消除效率比度量的是不同缺陷消除手段消除缺陷的效率。
  • 只能度量，不能预测
  • 计算方式
    • 以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是 DRL。
阶段缺陷个数/小时DRL（UT）
设计评审3.61.03
编码评审82.29
单元测试3.51

质量路径 Quality Journey

为了追求极高的质量，你有哪些手段？

  • Step 1：各种测试
  • Step 2：进入测试之前的产物质量提升
  • Step 3：评审过程度量和稳定
  • Step 4：质量意识和主人翁态度
  • Step 5：个体 review 的度量和稳定
  • Step 6：诉诸设计
  • Step 7：缺陷预防
  • Step 8：用户质量观——其他质量属性

设计与质量的关系

  • 低劣的设计是导致在软件开发中返工、不易维护以及用户不满的主要原因。
  • 充分设计可以显著减少最终程序的规模，提升质量。（熟练的程序员每 10 行会注入一个错误）
  • 设计本身也是一种排错的过程。

PSP 设计过程

alt text

设计什么？
  • 设计目标程序在整个应用系统中的位置；
  • 设计目标程序的使用方式；
  • 设计目标程序与其他组件以及模块之间的关系；
  • 设计目标程序外部可见的变量和方法；
  • 设计目标程序内部运作机制；
  • 设计目标程序内部静态逻辑；
设计的内容
动态信息静态信息
外部信息交互信息（服务、消息等）功能（继承、类结构等）
内部信息行为信息（状态机）结构信息（属性、业务逻辑等）

PSP 设计模板

  • 操作规格模板（Operational Specification Template， 简称 OST）
  • 功能规格模板（Functional Specification Template， 简称 FST）
  • 状态规格模板（State Specification Template，简称 SST）
  • 逻辑规格模板（Logical Specification Template，简称 LST）
PSP 设计模板展现的信息
动态信息静态信息
外部信息OST/FSTFST
内部信息SSTLST
操作规格模板 OST
  • OST 描述的是系统与外界的交互，具体而言，是描述“用户”与待设计系统的正常情况和异常情况下的交互
  • OST 可以用来定义测试场景和测试用例，也可以作为和系统用户讨论需求的基础，特别是操作相关的需求描述。
功能规格模板 FST
  • FST 描述的是系统对外的接口，这是一种静态信息的描述。
  • 在 FST 中提供的典型信息包括类和继承关系，外部可见的属性和外部可见的方法等。
  • 在使用 FST 模板的时候，消除二义性非常重要。因此，如果有可能，尽可能用形式化符号来描述方法等行为。
状态规格模板 SST

SST 可以精确定义程序的所有的状态、状态之间的转换以及伴随着每次状态转换的动作。

在 SST 模板中，需要描述如下的信息：

  • 所有状态的名称；
  • 所有状态的简要描述；
  • 在 SST 中需要使用的参数和方法的名称与描述；
  • 状态转换的条件；
  • 状态转换是发生的动作；
逻辑规格模板 LST
  • LST 可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议用伪代码配合形式化符号来描述设计结果。
  • 在 LST 模板中，需要描述如下的信息：
    • 关键方法的静态逻辑；
    • 方法的调用；
    • 外部引用；
    • 关键数据的类型和定义；

UML和PSP设计模板的关系

alt text

设计验证方法

意义：简单评审不足以发现复杂缺陷

方法：

  • 状态机验证
  • 符号化执行验证
  • 执行表验证
  • 跟踪表验证
  • 正确性验证

状态机验证

正确状态机：

  • 完整
  • 正交

验证方法：

  1. 检验状态机，消除死循环和陷阱状态。
  2. 检查状态转换，验证完整性和正交性。
    • 在真值表中，完整性是指所有的条件组合都已经定义。
    • 在真值表中，正交性是指状态机中的任何一个状态，其相应的不同状态转换的条件不能相同。也就是说，在同样的状态转换条件下，必须转换到唯一的下一个状态。
  3. 评价状态机，检验是否体现设计意图。
状态机示例

alt text
alt text

提取出复杂的条件组合：

alt text

无法判断出是否满足状态转换的完整性和正交性 —> 构建真值表

构建真值表

alt text

修改真值表

上表满足完整性，不满足正交性。修改如下
alt text

符号化执行验证

符号化验证方法的基本思想是将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后系统地开展分析和验证。具体步骤如下：

  1. 识别伪码程序中的关键变量；
  2. 将这些变量用代数符号表示，重写伪码程序；
  3. 分析伪码程序的行为。
符号化执行验证示例
1
2
3
4
5
begin
	X:=X+Y;
	Y:=X-Y;
	X:=X-Y;
end
#指令XY
初始值AB
1X:=X+Y;A+B
2Y:=X-Y;A
3X:=X-Y;B
结果BA
优缺点分析
  • 符号化验证的方法实施简单，可以给出一般化的验证结果，很多时候往往是唯一提供全面验证的方式。
  • 这种方法通常用在验证一些复杂算法中，特别是对遗留系统的改造中，往往应用这种方法来识别和理解原有的设计。
  • 但是这种验证方法不适用于有复杂逻辑的场合，而且，纯手工的验证方法也容易引入一些人为的错误。

执行表验证

执行表用一种有序的方法来跟踪伪码程序的执行状况，分析程序行为，从而验证设计。具体步骤如下：

  1. 识别伪码程序的关键变量；
  2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
  3. 初始化被选定的变量；
  4. 跟踪被选择的关键变量的变化情况，从而判断程序行为。
执行表示例

alt text

跟踪表验证

跟踪表验证方法是对执行表验证方法的一种扩充。具体步骤如下：

  1. 识别伪码程序的关键变量；
  2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
  3. 初始化被选定的变量；
  4. 识别将伪码程序符号化的机会，并加以符号化；
  5. 定义并且优化用例组合；
  6. 跟踪被选择的关键变量的变化情况，从而判断程序行为。
识别符号化的机会

alt text

例如，令 p = 左侧空格数；q = 非空字符数；Length = 字符串长度

正确性检验

正确性检验将伪码程序当成数学定理，采用形式化方法加以推理和验证。这种方法的步骤如下：

  1. 分析和识别用例；
  2. 对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证；
  3. 对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证。
While-Do
  • 该方法并不能保证循环体算法实现设计意图。

典型 while 循环如下：

1
2
3
4
while(condition)
	begin
		states;
	end

一个正确的 while 循环设计应当满足如下条件：

  1. condition 是否最终一定会为“假”，从而使得循环可以结束；
  2. condition 为“真”的时候，单独的循环结构执行结果与循环体再加一个循环结构，其执行结果是否一致？
  3. condition 为“假”的时候，循环体内所有变量是否未被修改？

团队工程开发

需求开发

  • 需求是一切工程活动的基础。
  • 需求类别
    1. 客户需求：靠近问题一侧。描述的是客户的期望，是客户解决问题的愿望。
    2. 产品需求：靠近解决域一侧。描述的是开发团队所提供的解决方案。即针对上述的客户需求，开发团队设计出一个可以帮助客户解决工作当中碰到的问题的方案。
    3. 产品组件需求：描述的是组成产品的各个组件的需求规格。与产品需求相比，这是更低层次，更为细致的描述了上述解决方案中的某个组件的功能、性能与形式等。

需求获取

  • 客户所受到的限制也应当作为需求开发过程中需要重点关注的内容。
  • 通常采取所谓的需求“诱导”方式进行。
  • “诱导”一词的含义不仅仅是普通的需求采集，它隐含了应更加积极地、前瞻性地识别那些客户没有明确提供的额外需求。

需求汇总

  • 整理各种来源的信息，识别缺失的信息
  • 解决冲突的需求
  • 需求的整理和转化
  • 推导未显式描述的需求内容

需求验证

  • 对需求进行分析和确认，以确保符合使用者预期
  • 典型活动包括
    1. 建立和维护操作概念和相关的场景
    2. 分析需求
    3. 确认需求

团队设计

  • 设计过程与 PSP 基本一致
  • 团队设计面向整体开发，因此需要额外考虑如下内容：
    1. 团队智慧的使用
    2. 设计标准
    3. 设计复用
    4. 设计的可测试性支持
    5. 设计的可用性支持等要求

团队智慧

发挥团队智慧两大挑战：

  • 确定整体架构之前很难进行分工
    • 解决方法视软件系统规模而定，可以选择适当人数（也可以是全体成员）的团队成员参与整体架构的开发，而其他人员参与架构的评价和关键技术问题的验证。
  • 鼓励团队成员在讨论和评审会议中的参与程度
    • 需要会议的协调者，特别是项目组长或者设计工作的负责人，采取适当方法来调动整个团队的参与。

设计标准

  • 命名规范：项目小组应当设计一个统一的命名规范来命名各个模块并建立系统词典，用以描述各个模块。
  • 接口标准：组件之间的接口标准和格式也需要作为设计标准的内容之一加以定义。
  • 系统出错信息：系统异常信息和出错信息往往也需要通过一个规范加以标准化。标准化测试的好处：方便定位错误
  • 设计表示标准：定义了设计工作的产物应当满足的标准。这有可能是所有设计标准中最为重要的一项内容。

复用性考虑

在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括：

  1. 复用接口标准：再识别可复用组件的时候，需要以高内聚、低耦合的设计思想来设计可复用组件。还得定义复用组件的接口标准。
  2. 复用文档标准：对于可复用组件必须提供详细支持文档，以便于团队其他人使用。
  3. 复用质量保证机制：复用组件质量尤为重要。为了获得较高的组件质量，建议采用高质量过程来开发。

可测试性考虑

设计可测试性考虑主要体现在两方面：

  • 尽可能减少测试代码的数量；
  • 制作合理的测试计划。

可用性考虑（不在大纲）

  • 可用性的问题应当在设计阶段就开始考虑，而不能推延到实现阶段。
  • 针对每一个关键功能都定义操作概念和操作场景。
  • 分析操作场景以确保软件系统开发完成之后，系统使用者会满意。
  • 必要时，可以邀请最终用户参与场景的评审，使用模拟、原型等技术，更好的把握用户真实意图。

实现策略

  • 评审的考虑
  • 复用策略
  • 可测试性考虑

评审的考虑

  • 在设计过程中，采取的基本策略是自顶向下、逐层精化，这有利于建立系统的整体观。
  • 在实现过程中，应当更多地考虑是否便于对实现结果进行评审。因此建议自底向上进行实现。
  • 按照这种策略，在实现的过程中优先实现底层的内容，然后评审这些底层的模块，以确保其质量。之后再进行高层实现。
  • 此外，这种策略还有利于复用策略的应用。

集成策略

大爆炸集成策略

  • 定义：将所有已经完成的组件放在一起进行一次集成
  • 优点：需要很少的测试用例
  • 缺点：需要所有有待集成的组件质量非常高，否则会出现难以定位缺陷位置的问题，从而消耗很多测试时间；另外，系统越复杂，规模越大，问题越突出

逐一添加集成策略

  • 与大爆炸集成策略相反，采取一次添加一个组件的方式进行集成；持续集成实际上就是逐一添加策略
  • 优点：很容易定位缺陷位置，特别是在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础
  • 缺点：需要测试用例非常多；存在有大量的回归测试，测试时间成本大

集簇集成策略

  • 定义：是对逐一添加集成策略的改进，把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续较高层次的集成
  • 优点：可以尽早获得一些可以工作的组件，有利于其它组件测试工作的开展
  • 缺点：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷

扁平化集成策略

  • 定义：优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。即尽快构建一个可以工作的扁平化系统
  • 优点：可以尽早发现系统层面的缺陷。【能较早但是不充分！】
  • 缺点：为了确保完成的系统，需要大量的打“桩”（stub），即提供一些直接提供返回值的伪实现。这种方式往往不能覆盖整个系统应该处理的多种状态。

Ver & Val 验证与确认

验证（Verification）和确认（Validation）都是为了提升最终产品的质量而采取的措施。

验证和确认的目的不同：

  • 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致，确保解系统内部的一致性；
  • 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确，确保问题域和解系统的一致性。
  • 前者关注的是产品需求是否得到体现、从这个产品需求（即解决方案）设计出来，一直到解决方案的开发完成，整个过程当中有没有偏、解决方案有没有被正确地实现出来。
  • 后者更多关注的是你的这个客户需求有没有得到满足，简单来说就是客户期望解决的问题，有没有被解决。
例子
  • 单元测试：验证
  • 集成：验证
  • 需求评审：确认
  • 验收测试：确认
  • 试运行：确认？
验证与确认活动
  • 环境准备
  • 对象选择
  • 活动实施
  • 结果分析

配置管理

配置管理基本概念

  • 配置项：

    • 在配置管理当中作为单独实体进行管理和控制的工作产品集合
    • 从某种角度上来说，所有开发过程中不应当随意变更的工作产物都应当识别为配置项。
    • 典型的可能作为配置项纳入配置管理的工作产品包含过程说明文档、项目开发计划文档、需求规格说明书、设计规格说明书、设计图表、产品规格说明书、程序代码、开发环境，如特定版本的编译器等、产品数据文件、产品技术文件、用户支持文档

  • 基线：基线是一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。

    • 发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。
    • 典型的发布基线时间点为需求分析之后、设计完成之后、单元测试之后以及最终产品发布。
    • 是配置项持续演进的稳定基础

配置管理简介

  • 配置管理的目的是建立与维护工作产品的完整性
  • 配置管理的活动
  • 配置管理的对象

配置管理活动

alt text

  1. 识别配置项
  2. 建立配置管理系统
  3. 创建和发布基线
  4. 跟踪变更请求
  5. 控制配置项变更
  6. 建立配置管理记录
  7. 配置审计

度量和分析

度量与分析的意义

目的在于建立和维持度量的能力，以支持管理的信息需要。

作为项目管理支持类的活动，度量和分析活动可以支持如下的项目管理活动：

  1. 客观的估计与计划
  2. 根据建立的计划和目标，跟踪实际进展
  3. 识别与解决过程改进相关议题
  4. 提供将度量结果纳入未来其他过程的基础

度量与分析活动

alt text

GQM 方法简介

  • 是一种面向目标的度量软件产品和过程的方法
  • 将模糊的、抽象的目标，分解成具体的、可测量的问题
  • 步骤：
    • 首先提出度量目标（Goal）
    • 将该目标细化为关于过程或产品的特定问题（Question）
    • 这些问题以度量（Metric）的方式得到回答

alt text

GQM 示例-项目经理

  • G: 确保稳定性、可预测性的开发过程来满足计划的里程碑。
  • Q: 我的项目是否按照计划的轨迹前进，计划的里程碑都能实现吗？
  • M: 软件项目开发工作的挥发性（分支、流、变更管理（UCM）活动）。

决策分析

决策分析的意义：错误的决策往往会给项目带来灾难性后果。为了降低这种错误决策的风险，往往需要尽可能基于客观事实和正确的流程来开展决策与分析活动

困难：

一个正式评估过程往往包含下列的活动：

  1. 建立评估备选方案的准则
  2. 识别备选解决方案
  3. 选择评估备选方案的方法
  4. 使用已建立的准则与方法，评估备选解决方案
  5. 依据评估准则，从备选方案中选择建议方案

决策分析活动

alt text

决策分析练习

某基于 WEB 的信息系统的技术选型

  1. 选择标准有哪些？
  2. 可选方案有哪些？
  3. 怎么评价

根因分析与解决方案

  • 避免类似错误反复发生
  • 一个正式根因分析过程往往包含下列的活动：
    1. 识别和选定问题
    2. 根因分析
    3. 建立改进的行动方案
    4. 实施改进，评估效果

根因分析活动

alt text

根因分析典型示例（鱼骨图）

alt text
典型角度：技术角度 、人员角度、 培训角度、过程角度