期末复习

复习总览

  • 过程线：软件工程方法如何随软件本质难题和历史阶段演化
  • 项目管理线：如何用团队、估算、计划、跟踪来实现成本、工期、质量目标
  • 质量管理线：如何通过缺陷管理、评审、指标和设计来判断并改进质量状态

三条线对应考点

主线 核心问题 典型考点
过程线 软件工程为什么出现，软件方法为什么演变 软件危机、本质困难、三大阶段、生命周期模型、瀑布、CMMI、PDCA、IDEAL、敏捷、DevOps
项目管理线 软件项目怎样实现成本、工期、质量目标 团队动力学、自主团队、TSP、估算、PROBE、WBS、计划、风险、EVM
质量管理线 如何知道质量状态，如何提高质量 PSP 质量策略、评审、Yield、A/FR、PQI、Review Rate、DRL、设计、需求、V&V、配置管理、GQM、决策分析、根因分析

过程线

概念

管理的三大要素

  • 目标
  • 状态
  • 纠偏

软件项目管理典型的三大目标

  • 成本
  • 质量
  • 工期

软件过程和生命周期的区别和联系

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

广义软件过程 = 软件开发过程

软件过程是为了实现一个或多个事先定义的目标而建立起来的一组实践的集合。这组实践通常有一定先后顺序，并作为整体实现目标

区别

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

迭代式

大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来完成交付。

瀑布模型

  • 瀑布模型是有回溯的过程

  • 瀑布模型不是单一模型，是一系列模型，覆盖最简单场景（过程元素少）到最复杂的场景（过程元素多）
  • 软件项目应该结合实际情况选择合适过程元素的瀑布模型，基本原则是，项目面临困难和挑战越多，选择的模型应该越复杂；软件项目团队往往低估项目的挑战，选择了过于简单的不使用的瀑布模型

易错点：

  • 不要简单说“瀑布模型就是错的”
  • 不要把瀑布模型理解成完全没有反馈
  • 不要把瀑布模型和迭代式简单对立
  • 正确答法要强调“根据项目挑战调整过程元素”

考法：

  • 简答：如何理解瀑布模型
  • 判断改错：瀑布模型是不是单一模型
  • 结合历史阶段：为什么软件独立成产品后会出现瀑布模型

对应往年题：

  • 【2020】我们如何理解瀑布模型

软件过程管理

软件项目管理与软件过程管理

软件项目管理：应用方法、工具、技术以及人员能力来完成软件项目、实现项目目标的过程

软件过程管理：为了让软件过程在开发效率、质量等方面有着更好性能绩效

判断题模板

题干：软件过程管理是软件项目管理应该实现的目标

错误。软件项目管理关注具体项目如何在成本、工期和质量约束下完成；软件过程管理关注组织的软件过程如何具有更好的效率和质量绩效。二者相关，但不是目标和手段的简单包含关系。

题干：不同的软件开发过程应该使用不同的生命周期模型，反之亦如此

错误。生命周期模型是粗粒度框架，软件过程是具体实践集合。二者不是一一对应关系。同一种生命周期模型可以搭配不同软件过程，同一种实践也可以出现在不同生命周期模型中。

对应往年题：

  • 【2018】软件项目管理和软件过程管理
  • 【2018、2020】生命周期模型与软件过程的区别和联系
  • 往年判断题：软件过程管理是软件项目管理应该要实现目标
  • 往年判断题：不同的软件开发过程应该使用不同的生命周期模型，反之亦如此

PDCA

PDCA 是 Plan、Do、Check、Act。

常见八步表述：

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

前四步对应plan

第五步对应Do

第六步对应check

第七、八步对应Action

IDEAL

IDEAL 包括五个阶段：

字母 阶段 具体做什么
I Initiating 初始 明确改进动机和业务目标，获得管理承诺，建立改进基础
D Diagnosing 诊断 分析当前过程状态，识别问题、差距和改进机会
E Establishing 建立 确定改进目标和优先级，制定改进策略、行动计划和资源安排
A Acting 执行 按计划实施改进方案，试点、部署并跟踪改进活动
L Learning 学习 总结经验教训，评估改进效果，将有效实践制度化并推广到后续改进

判断题模板：

题干：PDCA 和 IDEAL 不适合在敏捷环境中使用。

错误。PDCA 和 IDEAL 是过程改进参考元模型，适用于各种过程改进环境。敏捷中的 Sprint Planning、开发、Review、Retrospective 本身就体现了计划、执行、检查和调整的循环。

对应往年题：

  • 【2020、2023】请描述 CMMI 模型的 5 个等级特征，并解释为何 CMMI 模型不应该是敏捷方法的对立面
  • 【2015、2016】请分别描述 PDCA 模型和 IDEAL 模型的主要步骤
  • 往年判断题：XP 与 CMM/CMMI 是对立的两种软件开发方法
  • 往年判断题：PDCA 和 IDEAL 不适合在敏捷环境中使用

CMM/CMMI

CMMI Capability Maturity Model Integration

等级 英文 具体解释
Level 1 Initial 初始级 过程不可预测，成功靠个人英雄主义。组织处于混乱状态，反应迟钝（reactive）
Level 2 Managed 已管理级 在项目级别建立基本管理纪律。能够跟踪需求、计划项目、度量和控制。但过程仍是被动响应的
Level 3 Defined 已定义级 过程在组织级别被文档化和标准化。组织有一套标准软件过程，项目可以根据需要进行裁剪（tailor）。过程是主动的（proactive）
Level 4 Quantitatively Managed 定量管理级 组织和项目建立了定量的质量和过程性能目标，并使用统计方法来管理过程，结果是可预测的
Level 5 Optimizing 持续优化级 聚焦于持续的过程改进。通过量化的反馈和有计划的创新活动，主动消除常见原因的缺陷，不断优化过程

等级 2 和等级 3 关注的是当前状态；等级 4 和等级 5 是根据结果（未来）来进行管理。四级和五级被称为高等级，是因为强调定量管理和改进；与普通等级的本质差别是通过数据和模型来管理和改进过程。

CMMI 与敏捷

CMMI 不应该被看作敏捷方法的对立面。CMMI 是过程管理和改进参考模型，描述组织过程能力应该具备什么特征；敏捷方法多是具体开发方法或实践，描述如何开发。二者处于不同层次，可以结合使用。

软件工程演变的历史视角

软件危机和软件工程

软件危机是指

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

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

软件工程有两个视角：

视角 关注问题
管理视角 能否复制成功
技术视角 能否把问题解决得更好

三大阶段

阶段 典型特征 主流方法
软硬件一体化 软件支持硬件完成计算任务，功能单一，复杂度有限，几乎不需要需求变更 非常线性的软件过程 / 硬件开发流程思想、Measure twice, cut once、Code and Fix
软件成为独立产品 摆脱了硬件束缚（OS），功能强大，规模和复杂度剧增；个人电脑出现，普通人成为软件用户；需求多变，兼容性要求，来自市场的压力 形式化方法、结构化程序设计和瀑布模型、成熟度模型
网络化和服务化 功能更复杂，规模更大；用户数量急剧增加；快速演化和需求不确定；分发方式的变化（SaaS） 迭代式开发、敏捷宣言、XP、Scrum、Kanban、开源软件开发方法、DevOps

考法：

  • 简答：列出三大阶段的特点和主流方法
  • 简答：结合三大阶段说明软件开发方法如何演变
  • 选择：判断某个实践属于哪个阶段

对应往年题：

  • 【2018】软件发展三大阶段的特点和主流开发方法
  • 【2020】请结合软件发展的三大阶段，描述不同阶段的典型软件开发方法和实践
  • 课上选择题：整体来看，我们可以把软件的发展分为三大阶段，以下不属于三大主要阶段的是？
  • 课上选择题：以下哪一种实践是软硬件一体化阶段的典型实践？

驱动力：本质难题 四大本质困难

困难 含义 答题关键词
复杂性 软件实体数量多、关系复杂、状态空间巨大 非线性、状态爆炸、难以穷举
不可见性 软件是逻辑实体，没有物理形态 看不见、沟通困难、进度难观察
可变性 软件经常要随需求、业务、硬件、环境变化 需求变更、演化、回归错误
一致性 软件必须适配外部接口、规则、历史系统 兼容、约束、人为规则

本质难题变化带动软件方法演变

易错点：

  • “质量难题”很重要，但不是 Brooks 所说的四大本质困难之一
  • 四大本质困难不是彼此独立的，它们会相互促进
  • 除不可见性外，复杂性、可变性、一致性的表现程度会因项目而异

考法：

  • 选择题：给出四个选项，问哪个不是本质困难
  • 简答题：解释软件危机、软件工程、四大本质困难
  • 综合题：用本质困难解释为什么软件工程方法会演化

对应往年题：

  • 【2020-mid】关于 Brooks 提及的软件开发本质难题，下列说法中不准确的是？
  • 课上选择题：以下描述中，不属于软件开发本质困难或者本质挑战的是？

项目管理线

概念

三大目标

  • 成本
  • 质量
  • 工期

团队动力学

知识工作特点

软件项⽬管理中⾃主型团队的必要性/软件开发的特点：

  • 软件开发是一项既复杂又富有创造性的知识工作

  • 软件开发是一种智力劳动。开发者要处理和讨论极其抽象的概念，把不同的不可见部分整合成一个可以工作的系统

  • 软件开发是一种智力活动，开发者是智力劳动者，而对于智力劳动者而言，管理的第一准则，就是智力劳动者不能被管理，只能实现自我管理
知识工作管理

知识工作管理的关键规则：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。

要自我管理，知识工作者必须：

  • 有积极性
  • 能做出准确的估算和计划
  • 懂得协商承诺
  • 有效跟踪他们的计划
  • 持续地按计划交付高质量产物
领导者和特点

软件开发作为一种知识工作，需要领导者而不是一般经理

  1. 善于倾听团队成员的想法，并加以分析和改进
  2. 善于通过询问来诱导团队成员向着正确的方向前进
  3. 善于通过激励以及设定挑战目标等方式吸引团队成员努力表现
  4. 当出现不一致意见的时候，领导者则善于提供各种沟通方式，促成团队达成一致意见
  5. 培养团队成员技能
  6. 鼓励建立起合理的授权机制
  7. 通过挑战建立目标，确定团队努力方向
不同的激励方式
理论 要点
马斯洛需求层次 激励来自未满足需求；低层需求先于高层需求；自我实现最高
海兹伯格双因素 激励因素是内在因素，保健因素是外在因素
麦克勒格 X 理论 假设人逃避工作、缺乏主动性，适合底层需求激励
麦克勒格 Y 理论 假设人能够自我约束、自我导向，渴望承担责任
期望理论 动机 = 目标价值 × 成功概率
马斯洛需求层次理论

五个层次从低到高：

  1. Physiological 生理需求
  2. Safety 安全需求
  3. Social 社交 / 归属需求
  4. Esteem 尊重需求
  5. Self-Actualization 自我实现需求

核心判断

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

人们在下列情况下能够受到激励并且出大量成果：

M = V * E

  • V：相信自己会因为成功得到相应的回报
  • E：相信自己的努力很可能会产生成功的结果

自主团队内部环境/特点

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

项目启动阶段获得管理层支持：

  • 项目小组应当体现出已经尽最大可能满足管理层需求的工作态度
  • 项目小组应当在计划中体现定期需要向管理层报告的内容
  • 项目小组应当向管理层证明他们制定的工作计划是合理的
  • 项目小组应当在计划中体现为了追求高质量而开展的工作
  • 项目小组应当在工作计划中允许必要的项目变更
  • 项目小组应当向管理层寻求必要的帮助

项目进展过程中获得管理层支持：

  • 项目小组应当严格遵循定义好的开发过程开展项目开发工作
  • 项目小组应当维护和更新项目成员的个人计划和团队计划
  • 项目小组应当对产品质量进行管理
  • 项目小组应当跟踪项目进展，并定期向管理层报告
TSP

TSP 即 Team Software Process，团队软件过程。它通过一系列启动会议帮助团队建立目标、角色、过程、计划、质量策略和风险管理机制。

对应往年题：

  • 【2021】列出 TSP 角色并解释其中 5 个的职责
  • 课堂选择题：在 TSP 团队组建过程中，确定软件开发策略的是第几次会议？
  • 课堂选择题：过程经理的工作内容有哪些？
TSP 角色和职责
角色 职责
项目组长 激励成员，主持例会，汇报项目状态，分配工作任务，维护项目资料，组织项目总结
计划经理 带领小组开发、平衡项目计划，跟踪项目进度，参与项目总结
过程经理 带领团队定义、记录开发过程并支持过程改进，建立维护团队开发标准，建立记录维护项目会议记录，参与项目总结
开发经理 带领团队制定开发策略和高层设计，开展规模/资源估算，开发需求/设计规格说明，实现软件产品，开展测试，开发用户支持文档，参与项目总结
质量经理 带领团队开发跟踪质量计划，向组长警示质量问题，评审配置管理，组织协调项目小组评审，参与项目总结
支持经理 带领团队识别各类工具和设施，管理配置管理系统，维护项目词汇表，维护项目风险和问题跟踪系统，支持开发过程中的复用策略应用，参与项目总结
开发成员  
TSP 启动过程
会议 内容 会议内容
1 建立产品目标和业务目标 产品目标：要做什么？业务目标：要做的怎么样？
2 角色分配和小组目标定义 角色分配：怎么安排？小组目标：有没有与组织目标冲突？
3 开发流程定义和策略选择 开发流程：打算使用什么样的过程？开发策略：分为几个迭代？每个迭代做什么？组件如何获取？
4 整体计划 整体计划：估算 + 计划，需要明确做哪些事情？产出物有哪些？产出物规模如何？需要多少资源？团队给出的资源够不够？
5 质量计划 质量计划：有哪些质量实践？做到什么程度？需要投入多少资源？
6 个人计划以及计划平衡 个人计划：个人要做哪些事情？计划平衡：如何寻求一个最早完成项目的时间？
7 风险评估 风险评估：what if？
8 准备向管理层汇报计划 向管理层汇报准备：呼应第一次会议要求，体现团队述求，此外，如何体现这个计划不是粗制滥造？
9 向管理层汇报计划内容 汇报和讨论
  Launch 总结 总结：总结得失

对应往年题：

  • 【2021】列出 TSP 角色并解释其中 5 个的职责
  • 课堂选择题：在 TSP 团队组建过程中，确定软件开发策略的是第几次会议？
  • 课堂选择题：过程经理的工作内容有哪些？
Scrum角色和职责

Scrum 是跨职能的自组织团队。

角色 职责
Scrum Master 服务型领导，促进和支持 Scrum
Product Owner 价值最大化，管理 Product Backlog
Development Team 在 Sprint 结束时交付潜在可发布并完成的 Increment

估算和计划

估算要点

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

给各类计划提供决策依据

要做哪些估算：

应该要做规模估算和资源估算

估算对象：

  • 时间
  • 规模
  • 日程
抽象的、相对的估算

对项目估算的认识以及 PROBE 方法估算的优缺点：

规模估算往往可以依据历史数据来完成，其原因在于规模估算结果的偏差产生原因相对客观，偏差可以用以修正新的估算结果。

时间估算的偏差产生原因更加复杂，一方面和规模有关，另外一方面，跟人的主观能动性有关，因此，时间估算偏差的原因可能估算结果本身，这使得历史数据中时间偏差可参考价值不大。

从上述讨论可以得出，对于估算来说，本质上是一种猜测，追求的目标应该是一致性以及估算结果的使用者对估算结果的信心。

PROBE 方法通过定义的估算过程和数据收集以及使用的框架，使得估算结果可以尽可能一致，从而使得一些统计方法可以用来调整估算结果，增强用户对估算结果的信心。但是这种估算方法非常依赖高质量的历史数据，一旦数据不完整或者缺失，就可能导致估算结果有显著偏差。

PROBE估算方法

PROBE 方法原理：

全称：PROxy Based Estimation

作用：精确度量和早期规划之间的桥梁

原理：

  • 设立合理的代理作为精确度量和早期规划需要的度量之间的桥梁
  • 相对大小，而非绝对大小

截屏2026-06-27 00.00.53

补充：PROBE 是可以说精确度量的，一般来讲使用功能点估算。

为什么 PROBE(A) 估算时间时不使用历史生产效率数据：

在估算资源需求（例如，人时）的时候，生产效率一般在分母上，考虑到个人软件工程师的生产效率波动，容易导致估算偏差范围变大

对应往年题：

  • 【2020】按通用计划框架，为开发合理项目计划，应做哪些估算？PROBE 方法充当什么角色？
  • 【2013、2015A、2018】谈谈你对项目估算的认识，并解释 PROBE 方法估算的优缺点
  • 【2023】软件项目规模估算的基本要点有哪些？
  • 【2018、2020】描述 PROBE 方法基本原理和过程，并解释估算时间时为什么不用历史数据中的生产效率数据
  • 【2020】PROBE ABCD 方法在估算规模时对历史数据质量有什么要求？

SCRUM故事点

Story Point 是 Scrum 中用于估算用户故事相对规模的单位，不追求绝对工时，而强调相对大小和团队共识。PPT 中给出的做法是：选取可识别的最小用例为 2 个 Story Point。

估算要点：

  • 用户故事要满足可估算性（Estimable），开发团队需要估计用户故事以便确定优先级、工作量和计划
  • 很多团队要求每个故事大小在 2-8 个故事点，大于 8 个故事点通常要求拆分故事
  • 燃尽图可用剩余工作故事点跟踪进度，每日例会结束后计算剩余工作故事点并更新燃尽图
  • 故事点是抽象的、相对的估算，重点不只是得到数值，而是帮助团队建立共同理解、暴露分歧

通用计划框架

截屏2026-06-18 23.58.53

各类计划

WBS：

WBS = Work Breakdown Structure，工作分解结构。

定义：

WBS 是以可交付成果为导向，对满足项目目标和交付产物所需工作的分解。它定义项目工作范围，是范围管理、估算和计划的基础。

好的 WBS：

  • 工作包不重复
  • 所有要素定义清晰完整
  • 最底层要素有明确责任人
  • 最底层要素是实现目标的必要且充分条件

易错点：

  • WBS 不是 OBS
  • WBS 可以和 OBS 配合，但不要求直接对应

任务计划与日程计划：

任务计划描述：

  • 项目所有任务清单
  • 任务之间的先后顺序
  • 每个任务所需时间和资源

日程计划描述：

  • 各任务在日历上的开始和结束安排

风险计划：

风险管理目的：在风险发生前识别潜在问题，并规划应对措施，以减少风险对项目目标的负面影响。

风险管理包括：

  • 风险识别
  • 风险应对

典型策略：

  • 风险转嫁
  • 风险解决
  • 风险缓解

各类计划与跟踪：

课程总结“项目管理线”把“各类计划”和“跟踪”单独列在估算和计划后面。PPT 第四讲内容中，团队项目规划不仅包括日程计划，还包括质量计划、风险计划等。

质量计划要点：

  • 质量计划要解决的关键问题是开展哪些活动，以及这些活动开展的程度，例如时间、人数和目标
  • 质量计划需要把项目总体质量目标细分成若干小目标，便于在过程中管理和控制

里程碑评审审查内容：

  • 项目相关承诺，如日期、规格、质量等
  • 项目各项计划的执行状况
  • 项目当前状态讨论
  • 项目面临风险讨论

其他计划跟踪：

  • 日程计划跟踪
  • 承诺计划跟踪
  • 风险计划跟踪
  • 数据收集计划跟踪
  • 沟通计划跟踪

纠偏活动管理：

  • 偏差原因分析
  • 纠偏措施定义
  • 纠偏措施管理
质量

质量计划要解决的关键问题是开展哪些活动，以及这些活动开展的程度，例如时间、人数和目标。质量计划需要把项目总体质量目标细分成若干小目标，便于在过程中管理和控制。

风险

风险管理目的：

在风险发生前识别潜在问题，并规划应对措施，以减少风险对项目目标的负面影响。

风险管理包括：

  • 风险识别
  • 风险应对

典型策略：

  • 风险转嫁
  • 风险解决
  • 风险缓解

跟踪

挣值管理体系

EVM：

EVM = Earned Value Management，挣值管理。

定义：

EVM 是用来客观度量项目进度的一种项目管理方法。它把任务完成情况转化为挣值，从而比较计划、实际进展和成本。

材料原句要点：

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

基本变量：

缩写 含义
PV Planned Value，计划价值
EV Earned Value，挣值
AC Actual Cost，实际成本
BAC Budget at Completion，完工预算
SV Schedule Variance，进度偏差
SPI Schedule Performance Index，进度绩效指数
CV Cost Variance，成本偏差
CPI Cost Performance Index，成本绩效指数

常用公式：

SV = EV - PV
SPI = EV / PV
CV = EV - AC
CPI = EV / AC

截屏2026-06-18 08.54.09

三种实现：

实现 重点
简单实现 建立 WBS，定义工作范围；为 WBS 中每一项工作定义 PV；按照 100-0 或 50-50 规则为已完成或正在进行的工作赋值，得到 EV
中级实现 在简单实现基础上，加入日程偏差的计算
高级实现 在中级实现的基础上，还需要考察项目的实际成本

EVM 局限：

  • 不能直接用于质量管理
  • 高度依赖估算准确
  • 对需求频繁变化和探索型项目不友好
简单、中级和高级

见“挣值管理体系”中的“三种实现”表。复习时按简单实现、中级实现、高级实现三层分别背：是否只看 PV/EV、是否加入日程偏差、是否进一步考察实际成本。

变形：燃尽图
  • 燃尽图是EVM 的一种变形
  • Scrum 中燃尽图用剩余工作量跟踪进度，常以故事点为单位
  • 每日例会结束后计算剩余工作故事点并更新燃尽图
为何适应软件项目
  • 燃尽图适用于软件过程管理，一般不适用于软件质量管理
  • 燃尽图需要定量化的管理机制，需要团队持续估算、记录和更新剩余工作量
  • 燃尽图依赖项目估算和团队共识。团队对故事点、剩余工作量和完成标准达成共识后，才能用曲线判断进度状态
  • 燃尽图能够较好适应需求变更。需求变化时，可以调整待办项和剩余工作量，通过曲线变化反映当前计划和实际进展，而不是只固定追踪最初计划

截屏2026-06-18 09.09.31

对应往年题：

  • 【2013、2014、2015A、2015B、2016】如何制定一份让人无法拒绝的计划？
  • 【2023】挣值管理简单、中级和高级三种实现方式的基本要点
  • 【2021】给计划/实际表格，判断进度快慢和潜在风险
  • 课堂选择题：WBS 哪些说法不正确？
  • 课堂选择题：EVM 哪些说法不正确？

质量管理线

概念

质量管理的挑战：三要素

  • 目标：到底追求什么质量。第五讲强调软件质量定义存在挑战，面向用户的质量观要求明确用户是谁、用户需求优先级是什么
  • 状态：当前质量水平如何。需要通过缺陷、评审结果、Yield、A/FR、PQI、DRL 等指标理解质量状态
  • 纠偏：发现质量偏差后如何改进。可以通过加强评审、调整质量计划、改进过程、诉诸设计、缺陷预防等方式纠偏

面向用户的质量观

质量定义：

软件质量可以从多个角度理解：

  • 满足规定和隐含需求能力的特征整体
  • 外部质量面向最终用户，内部质量不直接面向最终用户
  • 面向用户的质量观强调用户满意度
  • 质量是对用户的价值，具有主观性

面向用户的质量观要回答：

  • 用户是谁？
  • 用户需求优先级是什么？
  • 用户优先级对开发过程有什么影响？
  • 如何度量质量？

质量管理策略和背后逻辑

（PSP）质量管理策略：

用缺陷管理替代质量管理。高质量产品意味着组成产品的各个组件基本无缺陷，而各组件的高质量主要通过高质量评审来实现

逻辑链：

软件能工作 -> 基本无缺陷 -> 组件基本无缺陷 -> 高质量评审 -> 质量指标控制

质量管理策略的背后逻辑：

  • 用户的质量期望可以很多，例如执行速度、安全性、可用性、可靠性、兼容性、可维护性、可移植性等
  • 但软件产品“必须能够工作”是最基本的期望
  • 如果软件产品本身不能工作，讨论其他期望没有意义
  • 为了使软件产品可以工作，产品基本没有缺陷是最基本要求
  • 因此 PSP 采用“用缺陷管理替代质量管理”的方式，先确保基本无缺陷，再考虑其他质量目标

评审

个人评审

评审为什么重要：

测试消除缺陷流程：

  1. 发现异常行为
  2. 理解程序工作方式
  3. 调试定位缺陷位置和原因
  4. 确定修改方案
  5. 回归测试

评审消除缺陷流程：

  1. 沿评审者逻辑理解程序
  2. 发现缺陷时通常也知道位置和原因
  3. 修正缺陷

与测试相比，评审往往能更早发现缺陷，并且在发现缺陷时同时定位位置和原因，因此缺陷消除成本更低。PSP 强调通过高质量评审提高组件质量

质量控制指标

Yield

Yield 用来度量某阶段消除缺陷的效率。

Phase Yield：

Phase Yield = 100 × 某阶段发现缺陷数 / (某阶段注入缺陷数 + 进入该阶段前遗留缺陷数)

Process Yield：

Process Yield = 100 × 第一次编译前发现缺陷数 / 第一次编译前注入缺陷数

用途：

  • 判断缺陷消除效率
  • 建立缺陷预测模型
  • 支持过程改进

易错点：

  • 往年题强调 Yield 更适合用于估算/预测，不要简单当成事后直接度量质量的万能指标

截屏2026-06-27 14.32.15

A/FR

A/FR = Appraisal to Failure Ratio，质检失效比

公式：

A/FR = PSP 质检成本 / PSP 失效成本

其中：

质检成本 = 设计评审时间 + 代码评审时间 失效成本 = 编译时间 + 单元测试时间

含义：

  • A/FR 越大通常意味着质量越高
  • 但过高说明评审过多，可能降低效率
  • 在 PSP 中 A/FR 的期望值就是 2.0

PQI

PQI = Process Quality Index，过程质量指标

它是五个数据的乘积：

指标 基准
设计质量 设计时间应大于编码时间
设计评审质量 设计评审时间应大于设计时间 50%
代码评审质量 代码评审时间应大于编码时间 50%
代码质量 编译缺陷密度应小于 10 个/KLOC
程序质量 单元测试缺陷密度应小于 5 个/KLOC

用途：

  • 判断模块开发质量
  • 规划质量活动
  • 支持过程改进
  • 往年整理中给出：PQI 的期望值是 0.4；如果 PQI > 0.4，可以认为软件产品质量较高

易错点：

  • PQI 越接近 1 越好，但不能说 PQI 能充分保障质量
  • PQI 可用于辅助判断和改进，不是质量保证的唯一依据

Review Rate

Review Rate 是评审速度，用于指导有效评审。

参考：

代码评审速度 < 200 LOC / 小时 文档评审速度 < 4 Page / 小时

易错点：

  • 评审不是越快越好
  • 也不是越慢越好，因为过慢会影响效率
  • 不能说技能强的人就可以无限突破评审速度限制

DRL

DRL = Defect-Removal-Leverage，缺陷消除效率比

缺陷消除效率比度量的是不同缺陷消除手段消除缺陷的效率

定义：

以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该基础的比值就是 DRL

用途：

  • 比较不同缺陷消除手段的效率
  • 说明评审相对测试的效率优势

截屏2026-06-27 14.49.32

综合题答题模板：

题目：结合 A/FR、PQI、Review Rate、DRL、Yield 说明如何确保高质量。

答：

这些指标既是质量管理参考指标，也应体现在质量计划中。首先，应在计划阶段安排个人评审、小组评审、单元测试、集成测试等活动。其次，用 A/FR 控制评审投入与失败成本的比例，用 PQI 检查设计、评审、代码和测试质量，用 Review Rate 控制评审速度，用 DRL 比较评审和测试等缺陷消除手段效率。再次，用 Yield 建立缺陷预测和过程改进模型，尽早发现质量偏差并采取补救措施。最后，依据这些指标持续改进过程，而不是只在测试阶段被动发现缺陷。

对应往年题：

  • 【2013、2021】基于 Yield 指标构建缺陷预测模型，并列举改进方案
  • 【2013、2015、2018】解释 A/FR、PQI 的计算方式和用途
  • 【2015A】结合 A/FR、PQI、Review Rate、DRL、Yield 说明如何确保高质量
  • 课堂选择题：关于 DRL、PQI、Yield、Review Rate 的判断

Quality Journey

Quality Journey是什么？顺序如何？体现了什么样的质量管理哲学？

追求高质量的路径：

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

对应往年题：

  • 【2013、2015A】如果对质量的追求无止境，不考虑资源和成本，有哪些可能有效策略？
  • 课堂选择题：关于 PSP 质量管理策略，下列说法正确的是？
  • 课堂选择题：Humphrey Quality Journey 中哪些说法正确？

设计

  • 低劣设计会导致返工、维护困难和用户不满
  • 充分设计可以减少最终程序规模，提升质量
  • 设计本身也是排错过程

UML 与 PSP 模板：

  • 用例图和时序图提供类似 OST 的信息
  • UML 类图描述类结构，但方法行为需要 FST 补充
  • UML 没有直接对应 LST 的图示方法
  • UML 状态图类似 SST，但 SST 对状态、转换条件和动作要求更细

设计验证方法：

常见方法：

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

正确状态机要求：

  • 完整
  • 正交

设计验证方法要点：

方法 核心表述
符号化执行验证 将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号表示，然后手工分析伪码程序的行为
执行表验证 采用构建执行表的方式跟踪伪码程序的执行状况，分析程序行为
跟踪表验证 是对执行表验证方法的一种扩充，会识别将伪码程序符号化的机会并加以符号化，定义并优化用例组合
正确性检验 将伪码程序当成数学定理，采用形式化方法推理和验证；复杂结构逐项用标准问题验证，不能明确判断时用跟踪表等辅助验证

对应往年题：

  • 课堂选择题：哪个设计模板记录内部动态信息？
  • 课堂选择题：PSP 四大设计模板和 UML 典型设计图的关系
  • 课堂选择题：一个完全正确的状态机应满足什么？
  • 课堂选择题：各种设计验证手段的描述
模板：要设计哪些信息？

PSP 设计模板：

  • 操作规格模板（Operational Specification Template，OST）
    • 描述的是系统与外界的交互，用户与待设计系统的正常情况和异常情况下的交互
    • 可以用来定义测试场景和测试用例，也可以作为和系统用户讨论需求的基础，特别是操作相关的需求描述
  • 功能规格模板（Functional Specification Template，FST）
    • 描述的是系统对外的接口，是一种静态信息的描述
    • 消除二义性非常重要，尽可能使用形式化符号来描述方法等行为
  • 状态规格模板（State Specification Template，SST）
    • 可以精确定义程序所有的状态和转移以及伴随着每次状态转换的动作
  • 逻辑规格模板（Logical Specification Template，LST）
    • 精确描述系统的内部静态逻辑
    • 为了消除描述的二义性，一般建议用伪代码配合形式化符号来描述计算结果

截屏2026-06-27 15.07.43

设计的层次

设计表示标准定义了设计工作的产物应当满足的标准。这有可能是所有设计标准中最为重要的一项内容。

项目小组可以基于 4 个设计模板，再参考设计的层次，合理定义团队设计表示的标准。

  • 设计不是只在一个粒度上进行。系统、子系统、组件、模块、类、方法等都可能是不同设计层次
  • 设计层次的意义在于：在不同抽象层次上分别表达设计信息，避免只写高层结构而缺少可实现细节，也避免只写代码级细节而缺少整体观
  • 每一层设计都应说明必要的外部 / 内部、动态 / 静态信息

PSP 四个设计模板在不同层次上的应用：

信息类型 对应模板 在设计层次中的作用
外部动态信息 OST / FST 描述本层设计对象如何与外界交互，可用于测试场景和操作相关需求讨论
外部静态信息 FST 描述本层设计对象对外接口、外部可见属性和方法
内部动态信息 SST 描述本层设计对象内部状态、状态转换和转换动作
内部静态信息 LST 描述本层设计对象内部逻辑、关键方法、调用关系和数据定义

设计的层次强调设计应在不同抽象层级上逐层展开；PSP 四大设计模板提供了每一层需要表达的信息框架，使团队能以一致、完整、可验证的方式表示设计结果。

设计验证方法
  • 状态机验证
    • 正确的状态机应该是：完整、正交的
  • 符号化执行验证
    • 基本思想是将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后手工分析伪码程序的行为
    • 优点是：实施简单，可以给出一般化的验证结果，很多时候往往是唯一提供全面验证的方式
    • 通常用在验证一些复杂算法中，特别是对遗留系统的改造中，往往应用这种方法来识别和理解原有的设计
    • 缺点是：不适用于有复杂逻辑的场合
    • 纯手工的验证方法也容易引入一些人为的错误
  • 执行表验证
    • 采用构建执行表的方式跟踪伪码程序的执行状况，分析程序行为
  • 跟踪表验证
    • 是对执行表验证方法的一种扩充，区别在于会识别将伪码程序符号化的机会，并加以符号化
    • 定义并且优化用例组合
  • 正确性检验
    • 定理证明？把伪码程序方程数学推理，采用形式化方法加以推理和验证
    • 对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证
    • 对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证

质量管理相关补充

需求类别

需求 含义
客户需求 描述客户的期望，往往表现为客户在实际工作中碰到具体问题，希望通过某个东西帮忙解决这些问题
产品需求 描述开发团队所提供的解决方案，即针对客户需求设计出一个可以帮助客户解决问题的方案
产品组件需求 描述组成产品的各个组件的需求规格，比产品需求更低层次、更细致，描述某个组件的功能、性能、形式等

客户需求不是简单的功能描述。预算、工期、法律法规、行业限制也可能是需求开发中需要关注的内容。

需求开发过程

  • 需求获取
  • 需求汇总
  • 需求验证
  • 需求文档制作

需求获取

需求获取不仅是普通采集，还包括“诱导”：积极、前瞻性地识别客户没有明确提出但会影响开发周期和最终产品的需求。

需求汇总

需求汇总要做：

  • 整理各种来源的信息
  • 识别缺失信息
  • 解决冲突需求
  • 把客户需求转化为产品需求和组件需求
  • 推导未显式描述的需求

需求验证

需求验证要确保需求符合使用者预期。典型活动：

  • 建立和维护操作概念与场景
  • 分析需求
  • 确认需求

优秀 SRS 特征

特征 含义
内聚 一条需求只说明一件事
完整 不遗漏必要信息
一致 条目之间不矛盾
原子 尽量避免多个需求混在一句话里
可跟踪 客户需求、产品需求、组件需求可双向跟踪
非过期 体现最新认识
可行 资源范围内可实现
非二义 清晰客观
强制 缺失会导致不满足客户期望
可验证 有明确判断标准

对应往年题：

  • 【2015】给出需求开发完整过程，并解释客户需求和产品需求含义及其体现
  • 课堂选择题：下面描述属于典型客户需求的是？
  • 课堂选择题：关于需求开发的描述哪些正确？

团队设计、实现策略与集成策略

团队设计要额外考虑：

  • 团队智慧
  • 设计标准
  • 复用性支持
  • 可测试性支持
  • 可用性支持

设计标准

典型设计标准：

  • 命名规范
  • 接口标准
  • 系统出错 / 异常信息
  • 设计表示标准

复用性支持

复用支持包括：

  • 复用接口标准
  • 复用文档标准
  • 复用质量保证机制

实现策略

设计阶段常采用自顶向下、逐层精化。实现阶段为了便于评审和复用，常建议自底向上实现，先建立底层模块质量基础，再支持高层实现。

集成策略

策略 优点 缺点 适用场景
大爆炸集成 可能测试用例较少 缺陷定位困难 组件质量普遍较高
逐一添加 易定位缺陷 回归测试多 组件质量不高，需要坚实基础
集簇集成 尽早获得可工作组件，支持复用 系统级缺陷暴露较晚 有功能关联的模块
扁平化集成 尽早暴露系统级缺陷 需要大量 stub 需要快速形成系统骨架

持续集成本质上就是逐一添加集成策略。

对应往年题：

  • 课堂选择题：团队设计活动中应约定哪些设计标准？
  • 课堂选择题：团队设计活动中应注意哪些内容？
  • 课堂选择题：关于集成策略哪些描述正确？
  • 课堂选择题：考虑集成策略时应注意哪些方面？
  • 课堂选择题：扁平化集成策略和集簇式集成策略的判断

V&V：验证与确认

定义

Verification 验证：

确保选定工作产品与事先指定给该工作产品的需求一致。

Validation 确认：

确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确。

经典区分：

概念 关注 典型说法
Verification 是否符合规格 正确地构建产品
Validation 是否满足真实需求 构建了正确的产品

二者关系

验证和确认都是为了提升最终产品质量。验证依据来自确认目标，因为产品和组件需求必须与客户需求一致；验证为确认提供前提，因为如果产品需求和组件需求都没有完成，讨论客户需求是否满足没有意义。

活动区分

典型验证：

  • 需求评审
  • 详细设计评审
  • 代码评审
  • 单元测试

典型确认：

  • 验收测试
  • 试运行
  • 用户手册检查
  • 系统使用培训材料确认

注意：具体活动应按目标判断，而不是死记名称。

对应往年题：

  • 【2015B】解释质量保障活动中的 V&V 分别是什么含义，两者关系是什么？
  • 课堂选择题：哪些活动是典型 Verification？
  • 课堂选择题：哪些活动是典型 Validation？
  • 课堂选择题：哪些产物属于典型 Validation 对象？

配置管理、度量分析、决策分析与根因分析

配置项：

在配置管理中作为单独实体进行管理和控制的工作产品集合。

基线：

配置项持续演进的稳定基础。

配置管理目的：

建立和维护工作产品的完整性。

配置管理活动：

  • 识别和记录配置项物理特性和功能特性
  • 控制上述特性的变更
  • 记录和报告变更过程及配置项状态
  • 验证配置项是否与需求一致

典型配置项：

  • 过程说明文档
  • 项目开发计划文档
  • 需求规格说明书
  • 设计规格说明书
  • 设计图表
  • 产品规格说明书
  • 程序代码
  • 开发环境，如特定版本的编译器等
  • 产品数据文件
  • 产品技术文件
  • 用户支持文档

度量与分析

意义：

  • 支持客观估计和计划
  • 根据计划和目标跟踪实际进展
  • 识别和解决过程改进议题
  • 为未来过程提供度量结果基础

GQM：

GQM = Goal - Question - Metric
从管理目标出发，提出能刻画目标达成情况的问题，再定义可量化回答问题的指标。

PPT 中的三层结构：

层次 含义
概念层（目标） 为特定对象定义目标；对象可以是软件产品、软件过程以及相关资源等
操作层（问题） 使用一系列问题定义所研究对象，评价或评估特定目标达成进展
量化层（度量） 以量化方式回答操作层识别出来的问题

决策分析

正式决策分析步骤：

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

关键点：

  • 首先要明确哪些场合需要正式决策分析
  • 评价方法体现决策者利益诉求，所以要谨慎设计
  • 候选方案识别应与评价准则配合，不能随意拍脑袋

根因分析

目的：

避免类似错误反复发生。

过程：

  1. 识别和选定问题。
  2. 根因分析。
  3. 建立改进行动方案。
  4. 实施改进，评估效果。

典型角度：

  • 技术
  • 人员
  • 培训
  • 过程

易错点：

根因分析不能只停在“找到根因”，还要制定行动方案、实施改进并评价效果。

对应往年题：

  • 课堂选择题：哪些产物属于典型配置项？
  • 课堂选择题：团队内部配置审计通常应关注什么？
  • 课堂选择题：关于决策分析的论述中不恰当的是？
  • 课堂选择题：关于根因分析的论述中不恰当的是？

技术实践

敏捷相关方法

敏捷宣言

四条价值观：

  • 个体和互动 胜过 流程和工具
  • 可以工作的软件 胜过 详尽的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划

尽管右项有价值，我们更重视左项的价值

敏捷为什么出现

软件开发具有复杂性和可变性，很多风险无法通过充分前期计划完全消除。因此需要短周期迭代、快速反馈和持续交付来降低风险。

敏捷方法的特征

特征 含义
小周期迭代 用短周期持续学习和交付
快速响应变更 通过反馈机制处理变化
价值交付 关注对客户产生价值
自动化 通过测试、构建、部署自动化支持快速反馈

常见误区：

误区一：敏捷就是轻量、不严格

不正确。以 XP 为代表的敏捷方法对工程实践要求非常严格，例如 TDD、持续集成、结对编程、编码标准等。

误区二：敏捷就是拥抱变更、变更驱动

不准确。所有软件工程方法都需要限制和管理变更。敏捷承认变化不可避免，通过短周期反馈降低变更风险，而不是无条件接受所有变更。

误区三：敏捷不是计划驱动

不准确。所有正式项目都需要计划。敏捷也有计划，只是计划周期更短，反馈更频繁，计划会随着经验调整。

误区四：TDD 必然提供更高质量

不能绝对化。TDD 是重要工程实践，但“必然提供更高开发质量”没有足够证据支持，质量还依赖评审、设计、持续集成、团队能力等因素。

对应往年题：

  • 【2020、2023】请完整描述敏捷宣言；敏捷宣言有哪些内容，如何正确理解？
  • 【2015B、2016】结合 Scrum 论述敏捷方法应该具备的特征，并解释为何严格、重型、计划驱动等作为敏捷对立面不合适
  • 【2015A】敏捷方法的特征有哪些？哪些关于敏捷特征的说法不合适，为什么？
  • 【2014】为何说将“规范方法”“计划驱动方法”等作为敏捷方法对立面具有误导性？

DevOps

定义

DevOps 把敏捷思想从开发团队扩展到交付和运维全生命周期，通过协作文化、自动化工具链、CI/CD、监控反馈等方式缩短代码从提交到生产环境的时间，同时保证质量。

三个步骤

往年题标准答法：

  1. 实现开发到运维的工作快速地从左向右流动。
  2. 从右向左的每个阶段采用持续、快速的反馈机制。
  3. 建立具有创意和高可信度的企业文化，支持动态、严格、科学的实验。

为什么流行

答题句：

DevOps 流行是因为网络化和服务化时代要求软件快速交付、频繁变更和高可靠运行。DevOps 通过自动化测试、持续集成、持续交付、监控反馈和开发运维协作，降低交付风险，提高响应速度。

典型实践

  • CI/CD
  • 自动化测试
  • 版本控制
  • 容器化和虚拟化
  • 基础设施即代码
  • 微服务
  • 监控和可观察性
  • 无责沟通
  • 从事故中学习
  • 早期安全，即 DevSecOps

对应往年题：

  • 【2016】DevOps 三个步骤
  • 【2018】DevOps 的特点，为什么流行？
  • 【2021】解释至少 5 个 DevOps 技术、实践、方法

Scrum

定义

Scrum 是一个用于复杂产品开发的轻量级框架。它不是具体构建产品的技术过程，而是在框架中应用各种流程和技术，通过经验主义和精益思维持续交付价值。

答题句：

Scrum 通过短周期 Sprint、透明的工件、固定事件和自管理团队，使团队能够在复杂和不确定环境中持续检视、适应并交付产品增量。

Scrum 33355

类别 内容
3 个支柱 透明、检视、适应
3 个角色 Product Owner、Scrum Master、Developers
3 个工件 Product Backlog、Sprint Backlog、Increment
5 个事件 Sprint、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective
5 个价值观 承诺、专注、开放、尊重、勇气

角色和职责

Scrum Team 是跨职能的自组织团队。

角色 职责
Scrum Master 服务型领导，促进和支持 Scrum
Product Owner 价值最大化，管理 Product Backlog
Development Team 在 Sprint 结束时交付潜在可发布并完成的 Increment

三个工件

工件 含义 承诺
Product Backlog 产品需求动态清单 Product Goal
Sprint Backlog Sprint 目标、选中条目和计划 Sprint Goal
Increment 符合完成标准的可交付成果 Definition of Done

Scrum Team 特征

  • 通常 10 人以内
  • 自管理
  • 跨职能
  • 无子团队或层级结构
  • 专注单一 Product Goal

用户故事

用户故事模板：

作为<某类用户>，我想要<某个功能>，从而<创造某种价值>。

3C：

C 含义
Card 卡片
Conversation 交谈
Confirmation 确认

INVEST：

字母 含义
I Independent 独立
N Negotiable 可协商
V Valuable 有价值
E Estimable 可估算
S Small 短小
T Testable 可测试

DoD

Definition of Done 是团队对“完成”的统一标准。它提高透明度，保证质量，支持验收，防止技术债。

对应往年题：

  • 【2015B、2016】结合 Scrum 论述敏捷方法应具备的特征
  • 课堂选择题：TSP 和 Scrum 都是过程框架，需要填补具体实践后才是可工作的过程
  • 课堂选择题：Scrum 适合迭代式场景，TSP 也可以适合；二者都需要度量数据收集和分析支持管理决策

XP

核心思想

XP 关注开发阶段，尤其是程序员把工程任务实现并集成进系统的过程。它把测试、持续集成、重构、结对编程等实践做到极致，以压平变更成本曲线。

答题句：

XP 通过自动化测试、简单设计、重构、持续集成和结对编程，把反馈周期从月级压缩到分钟级，阻止错误和错误假设长期累积，从而降低后期变更成本。

XP 四大价值观与四项活动

四大价值观：

  • 交流
  • 简单
  • 反馈
  • 勇气

尊重是底座。

四项基本活动：

  • 编码
  • 测试
  • 倾听
  • 设计

XP 十二项实践

| 实践 | 含义 | | — | — | | 计划游戏 | 业务决策与技术估算协同 | | 小发布 | 发布尽可能小但有业务意义的版本 | | 隐喻 | 用共同比喻理解系统结构 | | 简单设计 | 只做当前需要的最简单设计 | | TDD | 先写测试，再写代码，再重构 | | 重构 | 不改变行为，只改善结构 | | 结对编程 | 两人协作，提高质量和知识流动 | | 集体代码所有 | 团队任何人都可以改进代码 | | 持续集成 | 频繁集成到主线并自动验证 | | 40 小时工作制 | 不靠长期加班维持进度 | | 现场客户 | 客户随时解答问题和争议 | | 编码标准 | 统一代码风格 |

TDD

TDD 的基本循环：

Red -> Green -> Refactor
先写失败测试 -> 用最简单代码让测试通过 -> 在测试保护下重构

简单设计

简单设计四条准则：

  1. 通过所有测试。
  2. 消除重复。
  3. 清晰表达意图。
  4. 最小化类和方法数量。

YAGNI：

不要因为“未来可能需要”就提前开发功能。提前设计和提前实现会增加维护成本和复杂性。

重构

重构的纪律：

不改变外部行为，只改善内部结构。

没有测试兜底、没有明确触发信号、只凭感觉改代码，不是重构，而是破坏。

持续集成

持续集成核心实践：

  • 单一主线代码库
  • 自动化构建
  • 自测试构建
  • 每人每天向主线提交
  • 每次主线提交都触发构建
  • 保持构建快速
  • 在类生产环境中测试
  • 任何人都能方便获得最新可执行文件

CI/CD 区分：

概念 含义
CI 频繁集成到主线，并通过自动化构建和测试验证
持续交付 任意通过验证的主线版本都处于可发布状态，但发布可人工触发
持续部署 通过流水线验证后自动部署到生产环境

对应往年题：

  • 【2015B】XP 规定开发人员每周工作时间不超过多少小时，连续加班不超过两周？答案：40 小时
  • 【2015A】TDD 可以提供更高开发质量这一说法为什么不宜绝对化？
  • 往年判断题：XP 与 CMM/CMMI 是不是对立的两种软件开发方法？

Kanban

定义

Kanban 是通过使用可视化、拉动式系统来优化流程中价值流动的策略。

Kanban 关注的不是如何写代码，而是工作项如何在流程中流动。

Kanban 六大实践

| 实践 | 含义 | | — | — | | 可视化 | 将隐性工作外显为共享认知 | | 限制 WIP | 限制每个阶段同时进行的工作量 | | 管理流动 | 关注工作项是否顺畅流动 | | 显式化策略 | 把规则写清楚，减少协调摩擦 | | 实施反馈循环 | 通过站会、补充会、回顾等持续反馈 | | 协同改进 | 用实验推动流程演进 |

Kanban 度量

| 指标 | 含义 | | — | — | | WIP | 已开始但未完成的工作项数量 | | 产能 | 单位时间完成的工作项数量 | | 工作项存续时长 | 某工作项从开始到当前经过的时间 | | 周期时间 | 已完成工作项从开始处理到完成交付的总时间 |

Kanban vs Scrum

| 比较 | Scrum | Kanban | | — | — | — | | 节奏 | 固定 Sprint 时间盒 | 连续流动 | | 需求变更 | Sprint 内通常不打断承诺 | 可随优先级进入队列 | | 结构 | 角色、事件、工件明确 | 更像流程改进工具箱 | | 适用 | 新产品开发、结构化迭代 | 运维、持续交付、工单、流式工作 |

Scrumban：保留 Scrum 的部分节奏和会议，引入 Kanban 的拉动和 WIP 限制。

Kanban vs XP

XP 关注工程实践和代码质量，例如 TDD、重构、持续集成；Kanban 关注流程可视化、WIP 限制和工作流改进。二者可以同时使用。

精益软件开发

精益思想在软件中的映射：

制造业概念 软件对应
库存 WIP、未完成工作
次品 Bug、缺陷、返工
停线 CI 红灯即停
拉动生产 按价值和下游需求拉取工作
价值流 需求从想法到上线的端到端流程

精益关键词：

  • 消除浪费
  • 建立质量
  • 快速交付
  • 延迟决策
  • 尊重人
  • 全局优化

对应往年题：

  • 【2020-mid】下列不属于看板方法典型实践的是？
  • 【2018】精益屋的两大支柱
  • 【2018】JIT、价值流和价值拉动的关系

综合题专项

判断改错题模板：

题型：给一句话，问是否正确，为什么。

答题结构：

判断：错误 / 正确但不完整。
原因：指出混淆了哪两个概念。
展开：分别定义两个概念。
结论：说明正确关系。

例：XP 与 CMM/CMMI 是对立的两种软件开发方法。

错误。XP 是具体软件开发方法，包含结对编程、TDD、持续集成等工程实践；CMM/CMMI 是过程管理和改进参考模型，用于描述组织过程能力成熟度。二者处于不同层次，可以结合使用，不应简单对立。

简答题模板：

题型：解释某概念 / 某模型 / 某方法。

答题结构：

定义 -> 组成/步骤 -> 作用 -> 易错点或适用场景。

例：解释 PROBE。

PROBE 是基于代理的估算方法。它通过早期容易判断的代理对象，在历史数据支持下，将早期规划估算与后期精确规模度量连接起来。其过程包括概要设计、代理识别、规模估算与调整、预测区间计算、资源估算与调整。PROBE 的优点是过程一致、能利用历史数据并增强估算信心，缺点是依赖高质量历史数据。

指标计算题模板：

质量指标题要先写公式，再解释含义。

A/FR = PSP 质检成本 / PSP 失效成本
质检成本 = 设计评审时间 + 代码评审时间
失效成本 = 编译时间 + 单元测试时间

Phase Yield = 某阶段发现缺陷数 / (该阶段注入缺陷数 + 进入该阶段前遗留缺陷数) × 100

SV = EV - PV
SPI = EV / PV
CV = EV - AC
CPI = EV / AC

计算后必须补一句：

该指标反映了什么，偏高或偏低意味着什么，应采取什么管理动作。

场景分析题模板：

题型：给项目场景，问应该采用什么策略。

答题结构：

先识别问题类型 -> 说明对应原则 -> 选择策略 -> 说明为什么不选其他策略。

例：组件质量普遍不高时如何集成？

组件质量普遍不高时，不宜采用大爆炸集成，因为缺陷定位困难。更适合逐一添加集成，每次集成都建立在已有稳定基础上，便于定位新缺陷。若模块之间功能关联明显，也可以采用集簇集成，先形成可工作的组件。

老师口头强调

来源说明：

依据录音 /Users/huatiancen/Library/Containers/com.tencent.qq/Data/Downloads/2026年06月16日 11点51分.m4a 的本地 Whisper 转写整理。

转写中有少量识别误差，已按课程语境保守校正：

转写误差 课程语境
IDAL / PCA IDEAL / PDCA
互模型 瀑布模型
CMP TSP
政治管理 挣值管理
平整 评审

三条主线

老师明确说复习可以抓三条线：

  1. 过程线。
  2. 项目管理线。
  3. 质量管理线。

过程线强调点

  • 过程是第一条线
  • 要理解什么是过程、什么是管理、什么是过程管理
  • 管理视角强调复制成功，不是凭空创新
  • 软件工程提出是为了解决本质难题
  • 本质难题在不同历史阶段凸显方式不同，所以软件工程方法也不同
  • 三大历史阶段要能串起来：软硬件一体化、软件独立成产品、网络化和服务化
  • 生命周期模型、软件过程、迭代式开发之间的关系容易理解偏差
  • 瀑布模型是重点易错点：瀑布模型是一个 family，不是单一僵死模型。应根据项目挑战和能力调整过程元素。现实中常见错误是低估项目难度，选择过于简单、不适用的方法

项目管理线强调点

  • 项目管理三大目标：成本、工期、质量
  • 软件开发是智力工作 / 知识工作，不能靠简单微观控制管理
  • 团队动力学重要
  • 激励理论中尤其要注意期望理论：动机 = 价值 × 成功概率
  • 自主团队要掌握
  • TSP 启动过程要熟悉，因为课程实践本身就在做类似 TSP 的事情
  • 估算是重点。估算会不会做，取决于是否正确认识估算的意图和目标
  • 定量管理和估算相关，但定量管理更强调用定量管理手段和过程模型
  • 项目进度跟踪重点是挣值管理体系，简单、中级、高级实现都要掌握

质量管理线强调点

  • 质量管理的难点在于判断“状态是什么”
  • 要掌握过程度量、结果度量和质量管理策略
  • 评审是重点，尤其是评审速度、评审时机、小组评审和质量控制指标
  • 每个质量指标都要熟悉用途，不要只背公式
  • Quality Journey / 质量路径要能说明“为了追求高质量应该怎么做”
  • 设计被特别强调。老师建议认真理解设计，因为做出更好的设计是软件工程师未来展现核心竞争力的重要机会之一
  • 设计要理解内部/外部、动态/静态，以及设计层次

必练往年题

过程线

  • 【2018】软件发展三大阶段的特点和主流开发方法
  • 【2020】结合软件发展的三大阶段，描述不同阶段的典型软件开发方法和实践
  • 【2018】软件项目管理和软件过程管理
  • 【2018、2020】生命周期模型与软件过程的区别和联系
  • 【2020】我们如何理解瀑布模型
  • 【2020、2023】描述 CMMI 五个等级，并解释为何 CMMI 不应是敏捷方法的对立面
  • 【2015、2016】描述 PDCA 和 IDEAL 模型主要步骤

敏捷线

  • 【2020、2023】完整描述敏捷宣言，并说明如何正确理解
  • 【2015B、2016】结合 Scrum 论述敏捷方法应具备的特征，并解释严格、重型、计划驱动等对立说法为什么不合适
  • 【2015A】敏捷方法特征有哪些？哪些关于敏捷特征的说法不合适？
  • 【2016】DevOps 三个步骤
  • 【2021】解释至少 5 个 DevOps 技术、实践、方法

项目管理线

  • 【2020】按通用计划框架，为开发合理项目计划应做哪些估算？PROBE 充当什么角色？
  • 【2013、2015A、2018】谈谈你对项目估算的认识，并解释 PROBE 方法优缺点
  • 【2023】软件项目规模估算的基本要点
  • 【2013、2014、2015、2016、2020】自主团队的必要性和特点
  • 【2021】列出 TSP 角色并解释其中 5 个职责
  • 【2023】挣值管理简单、中级、高级三种实现方式

质量管理线

  • 【2013、2021】基于 Yield 构建缺陷预测模型，并列举改进方案
  • 【2013、2015、2018】解释 A/FR、PQI 的计算方式和用途
  • 【2015A】结合 A/FR、PQI、Review Rate、DRL、Yield 说明如何确保高质量
  • 【2013、2015A】不考虑资源和成本，追求质量有哪些有效策略？
  • 【2015】需求开发完整过程，客户需求和产品需求含义
  • 【2015B】解释 V&V 含义和关系

课件思考题与课堂练习补充

来源：课程介绍、软件质量与管理各讲 PPT/PDF、Scrum、敏捷概述、新方法学、XP、持续集成、Kanban、Agentic AI 时代敏捷等课件中的启发性问题、思考讨论题和课堂练习题。答案优先依据 PPT、课上选择题含答案、往年整理；个别题目资料本身存在答案标注不完整处，会在答案中注明。

课程介绍中的启发性问题

  1. 软件过程管理和软件项目管理是不是一回事？如果不是，两者差异是什么？

    参考答案：不是一回事。软件项目管理是应用方法、工具、技术以及人员能力完成软件项目、实现项目目标的过程，目标通常是成本、质量、工期；软件过程管理是为了让软件过程在开发效率、质量等方面有更好性能绩效，和软件过程改进意思相近。

  2. 软件估算过程中，项目经验 / 历史数据的作用是什么？如何把项目经验 / 历史数据转变成估算结果？

    参考答案：历史数据是估算的依据，用来支持规模估算、资源估算和预测区间。典型做法是收集规模、时间、缺陷等 PSP/TSP 数据，借助 PROBE 等方法，用代理对象和历史数据建立关系，再调整得到估算结果。

  3. 估算应该追求的目标 / 目的究竟是什么？

    参考答案：估算目的是给各类计划提供决策依据。估算要的是过程，而非单个结果；估算过程应尽量详细、依赖数据、建立信心，并让相关干系人达成一致共识。

  4. 什么是管理？管理的要素有哪些？如何区分有管理还是没有管理？

    参考答案：管理至少包含目标、状态、纠偏三要素。能定义目标、知道当前状态，并在偏离目标时采取纠偏措施，才算有管理；只有口号、没有度量和纠偏，不是有效管理。

  5. 什么叫做软件质量？质量管理需要做哪些事情？要实现什么样的效果？如何检验？

    参考答案：软件质量是软件满足规定和隐含需求的能力，也体现为对用户的价值。质量管理要定义质量目标、安排评审和测试等质量活动、使用 A/FR、PQI、Yield、Review Rate、DRL 等指标跟踪质量状态，并通过缺陷数据、评审结果、测试结果和用户质量观检验。

  6. 什么是敏捷和敏捷宣言？

    参考答案：敏捷是一种思考软件开发的方式。敏捷宣言四条价值观是：个体和互动胜过流程和工具；可以工作的软件胜过详尽的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。必须补一句：尽管右项有价值，我们更重视左项价值。

    补充判断：

    • “客户合作胜过合同谈判”不等于不要合同，而是不要只依赖合同替代持续合作
    • “可以工作的软件胜过详尽的文档”不等于不要文档，有价值、推动项目进展的文档仍然需要
    • “个体和互动胜过流程和工具”不等于脱离过程，服务大量用户时反而需要恰当过程
    • “响应变化胜过遵循计划”不是甲方任意变更，而是承认变化并用反馈和迭代管理变化

  7. 究竟要不要度量？

    参考答案：要度量，但不能为度量而度量。PPT 中强调度量体现决策者对目标的关切，应从 GQM 出发：先有目标，再提出问题，再定义度量。没有度量难以管理和改进；错误度量会扭曲行为。

  8. 从极度反对 CMM 到出台大量成熟度模型，这是成熟度模型的问题，还是其他问题？

    参考答案：问题不在成熟度模型本身，而在误用。CMMI 是过程管理和改进参考模型，不是具体软件过程，也不是公司之间能力比较或过程优劣的简单标准。

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

    参考答案：定量管理的本质是通过数据和模型管理、预测和改进过程。仅仅收集数据不等于定量管理，还要有目标、模型、分析和纠偏。DevOps 强调快速交付和反馈，仍然需要度量、监控和定量分析。

  10. 需求分析、设计、测试分别要解决什么问题？

    参考答案：需求分析要识别客户期望和限制，并转化为产品需求、产品组件需求；设计要描述内部/外部、动态/静态信息，并支持实现、验证和质量目标；测试的目的不是证明没有缺陷，而是发现缺陷、验证产品和组件是否满足需求，并为质量判断提供依据。

第一讲：过程、项目管理与过程改进

以下说法是否正确？为什么？

  1. 软件过程管理是软件项目管理应该要实现的目标。

    答案：错误。项目管理关注具体项目是否达成成本、质量、工期目标；过程管理关注过程绩效和可复制成功。二者相关，但不是简单的目标和手段关系。

  2. “在公司导入敏捷过程是我们今年过程改进的主要目标。”

    答案：表述不严谨。导入敏捷过程是改进方案或手段，真正的过程改进目标应是效率、质量、响应变化能力等可评价的绩效目标。

  3. XP 与 CMM/CMMI 是对立的两种软件开发方法。

    答案：错误。XP 是具体敏捷开发方法；CMM/CMMI 是过程管理和改进参考模型。二者层次不同，可以结合使用。

  4. CMM/CMMI 不适合当今互联网环境的项目管理需求。

    答案：错误或过度绝对。CMMI 不是具体项目管理方法，而是过程改进参考模型；互联网环境也需要过程能力、度量、改进和组织级经验沉淀。

  5. PDCA 和 IDEAL 不适合在敏捷环境中使用。

    答案：错误。PDCA 和 IDEAL 是过程改进参考元模型，敏捷迭代、Review、Retrospective 本身也体现计划、执行、检查、调整。

  6. 不同的软件开发过程应该使用不同的生命周期模型，反之亦如此。

    答案：错误。生命周期模型是粗粒度框架，软件过程是实践集合，二者不是一一对应关系。

第二讲：软件发展阶段与本质困难

  1. “Measure twice, cut once”描述的是下述哪个软件开发场景：软件设计、代码评审、需求开发、V&V。

    答案：软件设计。

  2. 不属于软件发展三大主要阶段的是：软硬件一体化、网络化和服务化、云计算化和云原生、软件成为独立产品。

    答案：云计算化和云原生。

  3. 不属于软件开发本质困难或者本质挑战的是：质量难题、复杂性、不可见、一致性。

    答案：质量难题。Brooks 四大本质困难是复杂性、不可见性、可变性、一致性。

  4. 哪一种实践是软硬件一体化阶段的典型实践：Code and Fix、迭代式开发、瀑布生命周期模型、成熟度模型。

    答案：Code and Fix。

第三讲：团队动力学、TSP 与 Scrum

  1. TSP 和 Scrum 的团队组成有哪些共性？这些共性对于高效团队有什么帮助？

    参考答案：二者都强调团队、自主、角色分工、计划与反馈。TSP 通过项目组长、计划经理、开发经理、质量经理、过程经理、支持经理等角色覆盖团队运作；Scrum 通过 Product Owner、Scrum Master、Developers 保证产品价值、过程促进和开发执行。共性作用是明确责任、减少沟通成本、支持自我管理，并通过反馈和度量帮助团队改进。

第四讲：估算、计划和跟踪

  1. 项目交付日期、团队组成等都确定了，估算的意义在哪里？

    参考答案：估算仍然有意义，因为估算不是只为了决定截止日期，而是为计划、承诺、风险判断、资源安排和后续跟踪提供决策依据。

  2. 哪种估算方法好？

    参考答案：没有脱离场景的最好方法。估算应看数据质量、历史经验、代理是否合理、过程是否一致以及能否建立信心。

  3. 哪个估算结果更好（靠谱）？

    参考答案：更靠谱的估算应有清晰假设、足够详细的分解、历史数据支持和预测区间，而不是看单个数字是否“好看”。

  4. 究竟该如何做好估算？

    参考答案：尽可能划分详细；建立对结果的信心；依赖数据；估算要的是过程而非结果；估算过程是相关干系人达成一致共识的过程。

  5. 规模估算和时间估算有什么不同？

    参考答案：规模估算偏差原因相对客观，历史数据更有参考价值；时间估算受人的主观能动性、承诺和工作方式影响，估算值本身可能影响实际用时。

  6. 计算均值和标准差程序的估算练习。

    参考答案：这类题重点不是记一个固定 LOC 或分钟数，而是训练估算过程：先拆分输入读取、解析、均值计算、标准差计算、输出、异常处理等任务，再估算规模和时间，并说明假设。

  7. WBS 题：哪些说法不正确？

    答案：A、D。WBS 不应该简单对应 OBS；WBS 分解时“同一层不能应用不同标准”不是绝对规则。B 正确，C 按课堂口径为正确。

  8. EVM 题：哪些说法不正确？

    答案：B、D。中级实现加入日程偏差计算，不引入成本信息；EVM 高度依赖估算准确，不适合需求频繁变化的场景。A、C 正确。

第五讲：质量策略、指标与设计验证

  1. PSP 质量管理策略，哪些正确？

    答案：A、B、C。PSP 用缺陷管理替代质量管理；高质量组件主要通过高质量评审实现；经过训练，评审是高效缺陷消除手段。D 错，PSP 主要讨论内部质量和缺陷管理，不是主要解决外部质量。

  2. DRL 题，哪些不正确？

    答案：C、D。DRL 以单元测试每小时发现缺陷率为基准，不是以缺陷个数为基准；DRL 可以度量，不是只能预测。

  3. PQI 题，哪些不正确？

    答案：B、C、D。PQI 越高越好但不能充分保障质量；不是越低越好；PQI 可以用于质量规划。A 正确。

  4. Yield 题，哪些正确？

    答案：A、B、C。Yield 可辅助判断模块开发质量、提供过程改进依据，并分为 Process Yield 和 Phase Yield。D 错。

  5. Quality Journey 题，哪些正确？

    答案：A、C、D。Quality Journey 的步骤可在适当时候更换顺序；仍在“用缺陷管理替代质量管理”策略下讨论；测试在路径中先于评审得到贯彻和改善。B 不是 PPT 中给出的早期必备步骤。

  6. PSP 四大设计模板和 UML 关系，哪项完全正确？

    答案：D。FST 在 UML 中可以通过类图部分体现。OST 可由用例图/时序图体现部分信息；类结构和关系可在 FST/UML 类图中体现；LST 不能简单通过类图体现。

  7. 各种设计验证手段，哪些正确？

    答案：C、D。受限于手工方式，设计验证容易引入人为错误；符号化执行不适合复杂计算过程。执行表和跟踪表都不是“唯一一种提供全面设计验证”的手段。

  8. 完全正确的状态机应满足什么？

    答案：B、C。正确状态机应该完整、正交，即状态转换条件满足完整性和正交性。

  9. 关于质量，哪些说法不正确？

    答案：C。安全和保密一般属于质量要素；质量是多重属性组合，最终用户一般不能直接感知内部质量，质量与主观感受有关。

  10. 关于质量控制指标，哪些说法正确？

    答案：四项都不正确。A/FR 不是越高越好，过高会降低效率；Yield 不是精确度量模块质量的万能指标；评审不一定早于编译，课堂整理中强调可先编译除掉明显错误；PQI 可用于指导质量计划。

  11. 设计验证手段，哪些正确？

    答案：A。符号化执行容易引入人为错误。状态机验证、执行表、正确性检验相关选项都过度绝对或方向错误。

第六讲：团队需求、设计、集成与 V&V

  1. 哪些属于典型客户需求？

    答案：A、B、C。客户期望、预算限制、法律法规限制都可能是客户需求或客户限制；系统功能描述更接近产品需求/功能规格。

  2. 哪些属于典型设计标准？

    答案：A、B、C、D。命名规范、接口标准、出错或异常处理信息、设计表示方式都属于团队设计中应约定的设计标准。

  3. 团队设计活动中应注意哪些内容？

    答案：A、B、C、D。设计标准、复用、可测试性、可用性都在 PPT 中出现。

  4. 关于集成策略，哪些正确？

    答案：A、B、C、D。组件质量普遍不高时不宜扁平化；需要尽早获得可工作组件可用集簇式；组件质量普遍较高可用大爆炸；持续集成本质上是逐一添加策略。

  5. 考虑集成策略时应注意哪些方面？

    答案：A、B、C、D。要考虑质量状态、获取方式、功能和关系、数量。

  6. 扁平化集成策略和集簇式集成策略，哪些正确？

    答案：A、C。扁平化可较早暴露系统级错误；集簇式有助于复用策略实现。B 与 A 相反，D 过于绝对。

  7. 典型 Verification 活动有哪些？

    答案：A、B、C。需求评审、详细设计评审、单元测试是典型验证；试运行更接近确认。

  8. 典型 Validation 活动有哪些？

    答案：A、C。验收测试、系统测试常作为确认；代码评审和持续集成更偏验证。

  9. 典型 Validation 对象有哪些？

    答案：C、D。用户手册、系统使用培训材料面向用户使用环境，属于典型确认对象。

  10. 需求开发描述，哪些正确？

    答案：B。工期或预算往往是客户需求/限制的一个方面。A 把客户需求缩窄成具体功能要求，错误；C、D 不是 PPT 口径，产品需求由开发团队将客户需求转化而来，客户参与但不主导整个需求开发。

第七讲：配置管理、度量分析、决策分析与根因分析

  1. 哪些属于典型配置项？

    答案：A、B、C、D。接口设计文档、源代码、用户手册、系统使用培训材料都可作为配置项纳入配置管理。

  2. 团队内部配置审计通常应该关注什么？

    参考答案：材料中该题标注为“AD 可能对？”。按配置管理审计常见口径，重点关注物理审计和基线/配置项状态；复习时记住配置管理活动包括识别记录配置项、控制变更、记录报告状态、验证配置项与需求一致。

  3. 决策分析题，哪项不恰当？

    答案：C。候选方案的识别不应该晚于评价标准到导致方案被标准预设限制；PPT 强调正式决策分析要明确判定标准、谨慎设计评价方法，项目投标可视为典型决策分析活动。

  4. 根因分析题，哪项不恰当？

    答案：D。根因分析不能止于找到根因的解决方案，还要建立行动方案、实施改进并评估效果。

敏捷概述与新方法学

  1. 为什么敏捷与精益出现在软件开发行业？

    参考答案：网络化和服务化时代需求快速演化、不确定性高，计划驱动和重文档过程难以快速响应。敏捷强调迭代、反馈、客户合作和响应变化；精益强调消除浪费、价值流和持续改进。

  2. 如何做到敏捷？

    参考答案：不能只喊价值观，要通过具体实践落地，例如短周期迭代、站会、看板、TDD、持续集成、重构、回顾等。PPT 强调实践清晰、客观，便于执行和观察。

  3. 如何学习敏捷软件开发？

    参考答案：既要理解敏捷宣言和原则，也要学习明确实践。先用实践建立反馈，再理解实践背后的价值观。

  4. “干活的人最清楚该如何完成工作”与传统计划驱动方法有什么差别？

    参考答案：传统泰勒主义倾向由计划者规定工作方式；敏捷认为知识工作者最了解技术工作，应由团队自组织、自管理，并通过反馈和改进调整过程。

  5. 文档什么时候有价值？

    参考答案：文档如果创造价值、推动项目进展、服务用户或沟通，就是有价值的；如果只是为了形式、替代沟通或阻碍反馈，就有问题。

  6. 你是否应走向敏捷？

    参考答案：取决于项目不确定性、需求变化、团队能力和反馈需求。若需求变化常态、价值需要通过使用反馈发现，敏捷更合适；但敏捷不是不要纪律，而是用工程实践和反馈管理变化。

  7. 能否作出设计，使编码成为建造活动？

    参考答案：软件设计很难像建筑图纸那样完全消除编码中的发现过程。设计有价值，但很多设计错误只有编码和测试时才暴露。因此软件开发不能完全等同于按图施工。

  8. 如何对付不可预测的世界？

    参考答案：采用迭代式和适应性过程，短周期交付、获取反馈、回顾改进。每次迭代后追问做得好的部分、教训、可改进部分和未搞清楚部分。

  9. Agentic AI 时代敏捷开放问题如何答？

    参考答案：AI 能降低产物生成门槛，但不能替代价值判断。人仍需判断何种系统值得开发、需求和业务目标是什么、Agent 产出是否满足质量和安全边界。人与 Agent 的协作可以被理解为“个体与工具边界变模糊”，但敏捷仍要围绕价值、反馈、协作和判断力重构实践。

Scrum 课件问题

  1. 软件开发为什么需要 Scrum？

    参考答案：Scrum 用轻量框架处理复杂产品开发，通过 Product Backlog、Sprint、检视和适应，让团队在不确定环境中持续交付价值。

  2. Scrum 为什么适合复杂产品开发，而不是提前规定全部细节？

    参考答案：复杂产品存在需求不确定和实现不确定，提前规定所有细节会失效；Scrum 用透明、检视、适应和短 Sprint 管理复杂性。

  3. 为什么用户故事要说明 why？

    参考答案：why 告诉团队用户为什么想要该功能，帮助判断价值、优先级和更合适的解决方案。

  4. 接收标准回答什么问题？

    答案：回答“我们如何得知它何时已完工？”

  5. 估算扑克中要关注什么？

    参考答案：关注团队是否想法一致、是否存在分歧、是否有未考虑因素。差异本身是讨论需求理解、风险和复杂度的机会。

  6. Daily Scrum 回答哪些问题？

    答案：昨天做了什么；今天准备做什么；遇到什么障碍，需要其他人如何帮助。

  7. 为什么 Sprint 结束于演示？

    参考答案：演示让增量可见，帮助检视真实进展和产品价值，及时获得反馈，而不是只看文档或口头报告。

  8. Sprint Retrospective 讨论什么？

    答案：什么是好的，哪些可以做得更好，哪些需要在下个 Sprint 中改变。

  9. AI 时代 Scrum 回顾会可增加哪些问题？

    答案：Agent 使用效果如何；哪些任务适合委托；哪些不适合；AI 代码是否可解释、可检视、符合质量和安全边界。

  10. 为什么 Scrum 在 AI 时代仍有效？

    参考答案：AI 改变实现速度，但没有消除复杂性、不确定性、价值判断和反馈需求。Scrum 的透明、检视、适应仍然有效。

XP 与持续集成课件问题

  1. XP 如何把小调整做到底？

    参考答案：XP 从价值观出发，经由交流、简单、反馈、勇气等价值观，落实到测试、编码、倾听、设计等活动，再落实为 TDD、重构、持续集成、结对编程、集体代码所有权等实践。

  2. XP 实践的弱点能否由别的实践补上？

    参考答案：可以，这是 XP 的组合逻辑。单个实践可能有弱点，但测试、重构、持续集成、编码标准、集体所有权等相互支撑，不能随便只挑一项孤立采用。

  3. 计划游戏讨论哪些问题？

    答案：范围：为了有价值必须解决多少问题；优先级：只能先有 A 或 B 时选哪个；发布日期：哪些日期有关键业务影响；详细日程：版本内先做哪些故事。

  4. TDD/简单设计时追问什么？

    答案：还有哪些测试没覆盖；能否简化系统让问题自然消失。

  5. 集体代码所有权要思考什么？

    参考答案：无所有权会导致谁想改就改、破坏系统一致性；个人所有权又会造成瓶颈和等待。XP 用测试、持续集成、编码标准、结对等实践支撑集体所有权。

  6. 每周是否正好 40 小时重要吗？

    答案：不重要。重要的是是否长期靠加班维持进度；长期加班说明计划、范围、设计或测试出了问题。

  7. 引入 XP 为什么不能只选一项实践？

    参考答案：XP 实践相互支撑，单独采用容易暴露弱点。例如集体所有权需要测试、持续集成和编码标准支撑；简单设计需要测试和重构支撑。

  8. 为什么重复跑三次构建？

    参考答案：每一步失败都给出更小的怀疑半径，CI 的调试效率来自小半径反馈。

  9. CI 真正在解决什么问题？

    参考答案：解决延迟集成导致的问题，把集成风险前置，用频繁集成和自动验证快速发现冲突和回归。

  10. 为什么 feature branch 上跑 CI 不算 CI？

    参考答案：CI 的核心是频繁合入主线并验证主线。只在长期分支上自动构建，不能证明主线持续集成。

  11. 主线构建坏掉时为什么不能继续盖新代码？

    参考答案：坏主线会扩大问题范围，让多个问题缠在一起。应先恢复绿色主线，再继续开发。

  12. 紧密小团队是否每次都要重量级 PR？

    参考答案：不一定。PPT 提醒紧密小团队可重新评估是否每次都要重量级 PR；关键是既保持快速集成，又保证必要检视和质量门禁。

Kanban 与精益课件问题

  1. 如何从开始到结束控制工作项流动？

    参考答案：通过可视化工作流、明确政策、限制 WIP、管理周期时间和持续改进来控制流动。

  2. 看板中明确政策要说明什么？

    答案：说明工作项如何在每个状态中从开始到完成。

  3. 为什么产能度量是对工作项的精确计数？

    参考答案：Kanban 关注流动，产能表示单位时间完成的工作项数量，因此要精确计数完成项。

  4. 如何避免任务滞留影响整体交付？

    参考答案：可视化工作项状态，限制 WIP，关注周期时间和阻塞项，主动识别需要额外关注或加快处理的任务。

  5. Kanban 与 XP/Scrum 的关注点有什么不同？

    答案：XP/Scrum 更聚焦如何开发更好软件，包含工程技术和团队协作；Kanban 更关注如何管理和改进工作流程，本身不规定技术实践。

  6. 在 Kanban 的“开发中”列实施 TDD、重构、持续集成，会不会影响看板流程？

    答案：不会，反而可能缩短开发耗时、减少质量问题、加速流动。Kanban 不规定技术实践，但可以兼容这些工程实践。