背书答案

软件危机是什么

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

四大本质困难

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

软件发展三大阶段

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

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

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

区别

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

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

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

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

管理的三大要素

  • 目标
  • 状态
  • 纠偏

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

  • 成本
  • 质量
  • 工期

瀑布模型的正确理解

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

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

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 是根据结果（未来）来进行管理。四级和五级被称为高等级，是因为强调定量管理和改进；与普通等级的本质差别是通过数据和模型来管理和改进过程。

PDCA

  • P Plan 计划：确定目标、制定方案。
  • D Do 执行：按计划实施。
  • C Check 检查：检查执行结果，发现问题和偏差。
  • A Act 处理/改进：总结经验，标准化有效做法，修正问题，进入下一轮改进

常见八步表述：

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

前四步对应plan

第五步对应Do

第六步对应check

第七、八步对应Act

IDEAL

IDEAL 包括五个阶段：

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

【2023】AI 浪潮对软件工程中项目管理、质量管理、过程改进的挑战和机遇

随着 ChatGPT 的横空出世，以大模型为代表的 AI 技术势必对各行各业带来前所未有的影响。具体到软件工程，人工智能技术的应用也日渐常见，可以从项目管理、质量管理、过程改进三个方面展开。

项目管理可能会迎来更高级别的自动化和智能决策。AI 可以在项目规划和进度管理方面提供更准确的预测，帮助项目经理更好地分配资源、识别风险并制定更有效的计划。然而，挑战也随之而来，因为团队需要适应与 AI 系统的集成，同时确保人机合作的高效性。

同时，项目管理方面也可能会迎来更高层次的挑战。大规模 AI 模型的训练和部署可能需要更多的计算资源和时间，因此项目进度和资源分配会成为关键问题。由于 AI 项目通常较为复杂，需求可能会在开发过程中发生变化，因此敏捷开发等灵活的项目管理方法可能更受青睐。

质量管理方面，AI 可以通过自动化测试、静态代码分析和缺陷预测等技术提高软件质量。但是，面对新兴技术的快速变化，质量管理也需要不断更新，以适应新的测试方法和工具，确保软件在快速迭代的环境中依然可靠。

质量管理方面也有一些新的考虑因素。AI 模型的不透明性和复杂性可能使得测试变得更加困难，而且难以预测模型在真实场景中的表现。这可能导致质量保障的挑战，需要创新性的测试方法和工具来确保 AI 系统的可靠性和稳定性。

在过程改进方面，AI 的介入可以帮助发现效率低下的环节、优化流程，并提供个性化的指导。但是，团队需要对新技术的接受和应用进行适应，同时保持对人的关怀，确保人机协同工作的顺畅。

随着软件中融入更多的 AI 元素，团队可能需要重新评估其开发过程。引入新的技术可能需要更新现有的开发流程和规范，以适应新的需求和挑战。同时，关注数据质量和模型解释性也将成为过程改进的重要方向，以确保 AI 系统的可解释性和可信度。

敏捷宣言

四条价值观：

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

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

期望理论

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

M = V * E

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

自主团队内部环境/特点

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

知识工作管理，知识工作者必须

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

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

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

知识工作领导者

知识工作领导者应具备四个典型特质：

  • 诚实（Honest）：说到做到，承诺了什么就实际完成什么
  • 胜任（Competent）：具备完成工作所需的技能、知识和专业能力
  • 有愿景（Visionary）：能够看到更远的未来，并对理想未来形成可信、清晰的判断
  • 鼓舞人心（Inspirational）：对未来有积极、热情、有能量的看法，能够带动团队信心和行动

TSP 角色和职责

角色 职责
项目组长 激励成员，主持例会，汇报项目状态，分配工作任务，维护项目资料，组织项目总结
计划经理 带领小组开发、平衡项目计划，跟踪项目进度，参与项目总结
过程经理 带领团队定义、记录开发过程并支持过程改进，建立维护团队开发标准，建立记录维护项目会议记录，参与项目总结
开发经理 带领团队制定开发策略和高层设计，开展规模/资源估算，开发需求/设计规格说明，实现软件产品，开展测试，开发用户支持文档，参与项目总结
质量经理 带领团队开发跟踪质量计划，向组长警示质量问题，评审配置管理，组织协调项目小组评审，参与项目总结
支持经理 带领团队识别各类工具和设施，管理配置管理系统，维护项目词汇表，维护项目风险和问题跟踪系统，支持开发过程中的复用策略应用，参与项目总结
开发成员  

TSP 启动过程

会议 内容 会议内容
1 建立产品目标和业务目标 产品目标：要做什么？业务目标：要做的怎么样？
2 角色分配和小组目标定义 角色分配：怎么安排？小组目标：有没有与组织目标冲突？
3 开发流程定义和策略选择 开发流程：打算使用什么样的过程？开发策略：分为几个迭代？每个迭代做什么？组件如何获取？
4 整体计划 整体计划：估算 + 计划，需要明确做哪些事情？产出物有哪些？产出物规模如何？需要多少资源？团队给出的资源够不够？
5 质量计划 质量计划：有哪些质量实践？做到什么程度？需要投入多少资源？
6 个人计划以及计划平衡 个人计划：个人要做哪些事情？计划平衡：如何寻求一个最早完成项目的时间？
7 风险评估 风险评估：what if？
8 准备向管理层汇报计划 向管理层汇报准备：呼应第一次会议要求，体现团队述求，此外，如何体现这个计划不是粗制滥造？
9 向管理层汇报计划内容 汇报和讨论
  Launch 总结 总结：总结得失

口诀：先定目标分角色，流程策略做整体；质量个人再平衡，风险评估备汇报；管理汇报后总结

Scrum角色和职责

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

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

估算的目的

给各类计划提供决策依据

PROBE方法的作用

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

估算的要点

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

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

EVM的三种实现

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

PROBE估算流程

截屏2026-06-27 00.00.53

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

三种消除缺陷的方式：测试，评审，设计

启发1：尽可能将缺陷在模块内早期解决（否则后面系统测试代价极大）

启发2：code review 消除缺陷的效率最高，应重视

启发3：即尽量用上游的手段解决问题（即尽量用评审而非测试）

质量路径

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

Step 1：各种测试。先通过单元测试、集成测试、系统测试、验收测试等测试活动发现缺陷，这是最直接也最容易被组织接受的质量保障手段

Step 2：进入测试之前的产物质量提升。只依赖测试代价很高，因此要在需求、设计、编码等测试前阶段提高产物质量，尽量让缺陷不要流入测试

Step 3：评审过程度量和稳定。通过度量评审投入、评审速度、缺陷发现率、Yield 等指标，让评审成为可管理、可重复、可改进的过程

Step 4：质量意识和主人翁态度。团队成员不能把质量只看作测试人员的责任，而要对自己产出的质量负责，主动发现并消除缺陷

Step 5：个体review的度量和稳定。个人评审是进入小组评审和测试前的重要质量关口，需要度量个人评审时间、评审速度和发现缺陷数量，使其稳定有效

Step 6：诉诸设计。仅靠后期发现和修复缺陷不够，还要通过更好的设计降低复杂性、提高可理解性、可维护性和可测试性，从源头减少缺陷

Step 7：缺陷预防。利用缺陷数据分析根因，识别高频缺陷类型和薄弱过程，采取规范、模板、检查表、培训和过程改进等措施防止同类缺陷再次发生

Step 8：用户质量观——其他质量属性。质量最终要从用户角度判断，除了缺陷少，还要关注可用性、性能、可靠性、安全性、兼容性等用户真正感知的质量属性

通用计划框架

截屏2026-06-18 23.58.53

（PSP）质量管理策略

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

Yield、A/FR、PQI、Review Rate、DRL

Yield

计算方式：

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

用途：

  • 判断缺陷消除效率
  • 建立缺陷预测模型
  • 支持过程改进
  • 更适合用于估算/预测，不要简单当成事后直接度量质量的万能指标

往年题：基于 Yield 指标构建缺陷预测模型，并列举该模型的可能改进方案

总体思想：利用回归技术预测软件开发过程中各阶段的 Inject Rate（缺陷注入率）和 Yield（缺陷消除率）

Yield 指标只能用来估算，不可以用来度量。结合 Yield 指标，只需要知道如下指标就可以基于 Yield 指标构建一个基本的缺陷预测模型：

  • 注入阶段注入多少缺陷
  • 缺陷注入的密度（需求每一页注入多少缺陷）
  • 缺陷注入的速度（每小时注入多少缺陷）
  • 消除阶段的缺陷注入密度和速度
  • 历史数据中的软件规模、文档规模、开发人员规模

步骤：

  1. 确定纳入影响因子的数据以及数据度量方法
  2. 从系统历史库中收集历史数据，并进行整理
  3. 依照回归技术进行计算
  4. 在项目进行过程中不断收集数据，与预测数据进行比较，调整回归参数
  5. 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制

改进方案：

  • 结果受限于历史数据在简单性、可理解性、稳定性、可度量性、相关性等方面的质量。因此，维护历史数据
  • 影响因子的选择上面不仅仅需要有关软件规模的数据，还需要有关开发过程、开发文档、开发人员等方面的数据，并且需要将数据可度量化
  • 反馈模型。即在开发过程中随着实际数据的产生，将这些数据作为输入变量放入模型中以调整回归参数
  • 可能的改进是假设注入水平和消除水平都符合正态分布，计算均值和标准差，因此，可以用蒙特卡罗方法模拟结果

A/FR

计算方式：

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

用途：

  • 衡量评审等质检活动投入与失败成本之间的关系
  • A/FR 越大通常意味着质量越高
  • 但过高说明评审过多，可能降低效率
  • 在 PSP 中 A/FR 的期望值就是 2.0

PQI

计算方式：

PQI 是五个数据的乘积：

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

用途：

  • 判断模块开发质量
  • 规划质量活动
  • 支持过程改进
  • PQI 的期望值是 0.4；如果 PQI > 0.4，可以认为软件产品质量较高
  • PQI 越接近 1 越好，但不能说 PQI 能充分保障质量

Review Rate

计算方式：

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

用途：

  • 用于指导有效评审
  • 控制评审速度，避免过快导致遗漏缺陷
  • 评审不是越快越好，也不是越慢越好，因为过慢会影响效率

DRL

计算方式：

  • DRL = Defect-Removal-Leverage，缺陷消除效率比
  • 以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该基础的比值就是 DRL

用途：

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

设计模板

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

截屏2026-06-27 15.07.43

设计验证方法

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

集成策略选择

  • 大爆炸集成策略
  • 逐一添加集成策略（持续集成本质上就是逐一添加策略）
  • 集簇集成策略
  • 扁平化集成策略

验证与确认 V & V

  • 验证 Verification、确认 Validation 都是为了提升最终产品的质量而采取的措施
  • 验证和确认的目的不同
  • 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致
  • 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确

配置管理

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

为什么会出现敏捷软件开发？/ 敏捷要解决的根本问题是什么？

敏捷软件开发出现的根本原因是为了应对软件开发固有的两大特性：复杂性和可变性

传统瀑布模型试图通过详尽的前期计划来预测和控制项目，但在面对需求频繁变更和技术不确定性时显得僵化。敏捷通过短迭代、频繁反馈、持续交付和拥抱变化的原则，提供了一种更有效的方式来驾驭这种复杂性和可变性，从而持续交付客户价值

敏捷评价项目成功的最重要标准

为客户创造价值

Scrum33355

  • 三大支柱

    • 透明、检视、适应

  • 五个价值

    • 承诺、专注、开放、尊重和勇气

  • 三个角色

    • 开发人员、PO、Scrum Master

  • 三个工件

    • 产品 Backlog、Sprint Backlog、增量

  • 五个事件

    • Sprint
    • Sprint 计划会议

    • 每日 Scrum 会议

    • Sprint 评审会议

    • Sprint 回顾会议

请简述Scrum的理论基础及其三大支柱

Scrum的理论基础是经验主义和精益思维

  • 经验主义主张知识来源于实际经验和基于观察的决策，而非预先计划。Scrum通过其三大支柱来实现经验主义
  • 精益思维则强调减少浪费并专注于创造核心价值

三大支柱是实现经验主义的具体方式：

  • 透明
    • 确保工作的过程和成果对所有相关者都是可见和易于理解的
  • 检视
    • 必须频繁地、勤勉地检视Scrum的工件和进展，以便及时发现与预期目标的偏差或潜在问题。Scrum的五个事件就是为了提供固定的检视机会
  • 适应
    • 当检视发现任何方面超出了可接受的范围，团队必须尽快调整过程或正在处理的工作。如果不能适应，检视就毫无意义

什么是跨职能团队？为什么它对Scrum至关重要？

定义

  • 跨职能团队是指团队成员具有在每个 Sprint 中创造价值而所需的全部技能

重要性:

  • 减少依赖和瓶颈: 团队不必等待外部专家或另一个团队完成工作，这大大加快了交付速度

  • 增强责任感和所有权: 整个团队对交付的成果负有集体责任，促进了协作和共同解决问题

  • 提高灵活性: 团队可以更灵活地应对Sprint中出现的问题，因为所需的技能都在团队内部

  • 减少浪费: 避免了因团队间交接、沟通不畅和等待而造成的时间浪费

请简述Scrum的五大事件及其各自的核心目的

Scrum定义了五个官方事件，它们是固定的检视和适应机会：

  • Sprint: 这是所有其他事件的容器，是一个固定时长（一个月或更短）的周期。其目的是将想法转化为价值，并保持开发节奏的一致性。
  • Sprint计划会议 (Sprint Planning): 在Sprint开始时举行，目的是规划本Sprint要完成的工作。产出是Sprint目标 (Sprint Goal) 和 Sprint待办列表 (Sprint Backlog)。 (对于1个月的Sprint，时间盒为8小时)
  • 每日站会 (Daily Scrum): 每天15分钟的短会，供开发者检视实现Sprint目标的进展，并根据需要调整即将进行的工作。其核心是检查进度和识别障碍。
  • Sprint评审会议 (Sprint Review): 在Sprint结束时举行，目的是检视Sprint的成果（Increment），并与利益相关者协作，获取反馈，调整Product Backlog。重点是展示可工作的软件，而非技术细节。 (对于1个月的Sprint，时间盒为4小时)
  • Sprint回顾会议 (Sprint Retrospective): Sprint的最后一个事件，目的是检视上一个Sprint的过程，识别和规划改进措施，以提高质量和效能。这是一个关于流程改进的会议，而不是追究责任。 (对于1个月的Sprint，时间盒为3小时)

什么是“完成的定义”(DoD)？它在Scrum中有什么重要作用？

定义:

用于描述一个用户故事、任务或功能何时可以被认为真正“完成” 。它是团队对完成工作的标准化定义，确保开发过程中每个增量都符合质量要求并准备好交付

重要作用:

  • 提高透明度：DoD 明确了完成的标准，减少了团队之间的沟通误解
  • 保证质量：通过对代码质量、测试和文档的明确要求，确保产出的增量软件可用且可靠
  • 支持验收流程：DoD 是验收用户故事或功能的依据。如果工作未达到 DoD，任务不能被标记为完成
  • 防止技术债：通过明确完成标准，避免开发过程中留下未解决的问题

请简述XP的五个核心价值观，并解释“简单”价值观的含义

XP的五个核心价值观是沟通、简单、反馈、勇气和尊重。

  1. 沟通: 鼓励团队成员、客户之间进行开放、持续的交流。
  2. 简单: 寻求并实现能满足当前需求的最简单的解决方案。
  3. 反馈: 建立快速的反馈循环，无论是通过自动化测试还是频繁的客户演示，来尽早发现问题。
  4. 勇气: 鼓励团队成员敢于面对困难，如重构复杂代码或承认计划有误。
  5. 尊重: 团队成员必须相互尊重，这是有效协作的前提。

“简单”价值观的核心是 YAGNI (You Ain’t Gonna Need It) 原则，意为“你不会需要它”。它要求开发者抵制为未来不确定的需求进行预先设计和编码的诱惑，只专注于实现当前明确需要的功能。这样做可以避免过度工程化，减少系统复杂度和维护成本。

请简述持续集成的完整流程（或称为“日常集成循环”）

  1. 从主线拉最新代码
    • git pull origin main，让本地不落后，减少后续冲突的发生面
  2. 本地改 + 跑完整自动化构建
    • 绿了再改、改完再跑。构建包含编译、单元测试、静态检查，任何一项红就不推
  3. 推送前再 pull 一次、再构建一次
    • 这会儿同事很可能又合进来新东西。合并后再跑完整构建，验证能与同事改动共存
  4. git push 推到主线
    • 触发中央 CI 在干净环境里再跑一次，消除“在我机器上能跑”

请简述持续集成(CI)和持续交付(CD)的区别与联系

联系:

持续交付(CD)建立在持续集成(CI)的基础之上。CI是实现CD的必要前提。没有一个可靠、自动化的CI流程，就无法确保代码库始终处于可发布状态。

区别:

目标不同: CI的主要目标是自动化代码的集成和验证过程，确保主线代码的健康。CD的目标是自动化软件的交付过程，让任何通过验证的版本都能随时部署。

范围不同: CI的范围通常止于自动化测试，产出的是经过验证的构建产物。CD则将流程延伸至部署阶段，产出的是可以一键部署到生产环境的发布包。

触发方式不同: 在CI中，集成和测试是自动的。在CD中，部署到类生产环境（如Staging）通常是自动的，但部署到最终的生产环境通常是手动的业务决策。而持续部署(Continuous Deployment)则将最后一步也自动化了。

请简述Kanban方法的核心实践，并解释“限制在制品(WIP Limit)”的重要性

看板由以下三种协同工作的实践组成

  • 定义并可视化工作流程
  • 主动管理工作流程中的事项
  • 改进工作流程

Kanban方法的六大实践主要包括：

  • 可视化：把头脑里的隐性工作外显化为团队共享认知
  • 限制在制品（Limit WIP）：每个阶段设并发上限
    • 一列满了新工作就必须等待，强制团队面对真实瓶颈
  • 管理流动：关注重点从“人忙不忙”转向“工作项流不流”
  • 显式化策略：把隐性规则写出来贴在板上
    • 减少“什么叫完成、什么 Bug 要打断”这类协调摩擦
  • 实施反馈循环：日站会、补充会、Kanban 回顾、服务交付回顾
  • 协同改进：用实验而非命令推动演进

限制WIP的重要性在于:

  • 揭示瓶颈: 当某一列达到WIP上限时，工作流会自然停止，团队被迫去解决导致堵塞的瓶颈问题，而不是绕过它

  • 促进流动: 它创建了一个“拉动系统”。只有当下一阶段有空闲容量时，工作才能从上一阶段“拉”过来，这避免了工作的堆积和浪费

  • 减少上下文切换: 限制WIP迫使团队成员专注于完成手头的工作，而不是在多个任务间频繁切换，从而提高了效率和质量

  • 缩短交付周期: 通过减少排队时间，WIP限制能够显著缩短工作项从开始到完成的平均时间（周期时间）

Scrum 的定义与定位

核心定义: Scrum 是一个轻量级的框架 (Framework)，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值

关键点: 它不是一个详尽的过程或方法论，而是一个容器，你可以在其中运用各种过程和技术（如XP实践）。

PPT 重点 ( Scrum定义 ): “Scrum 不是构建产品的一种过程或一项技术,而是一个框架”。

Scrum 团队特征

Scrum团队是一个内聚的、自给自足的单元，包含三个特定角色。

规模: 10人或更少。小团队沟通效率更高，保持敏捷。如果团队过大，应考虑拆分为多个专注于同一产品的Scrum Team。

跨职能 (Cross-functional): 团队内部拥有在一个Sprint中创造价值所需的所有技能，无需依赖团队外部的人。这减少了交接和等待的浪费。

自管理 (Self-managing): 团队内部决定谁做什么、何时做、以及如何做，以最好地完成工作。这赋予团队自主权和责任感。

PPT 重点 ( 跨职能的Scrum Team ): “完整技能闭环: 具备端到端交付价值所需全部能力”。

PPT 重点 ( Scrum Guide 2020 ): 2020版指南取消了“开发团队(Development Team)”的称谓，统称为“开发者(Developers)”，强调Scrum Team是一个不可分割的整体。

Scrum 工件与承诺

Scrum的工件代表工作或价值，为透明度提供了保障。每个工件都有一个对应的“承诺”，以提供清晰度和焦点。

  1. 产品待办列表 (Product Backlog)

定义: 一个动态涌现、有序排列的列表，包含改进产品所需的一切。

承诺: 产品目标 (Product Goal)，它描述了产品的未来状态，是团队规划的长期目标。

  1. Sprint 待办列表 (Sprint Backlog)

定义: 由Sprint目标、为Sprint选择的PBI以及交付增量的行动计划组成。

承诺: Sprint 目标 (Sprint Goal)，它是本Sprint要实现的单一目标。

  1. 增量 (Increment)

定义: Sprint中完成的所有Product Backlog项的总和，它是一个可用的、符合“完成的定义”的产品构件。

承诺: 完成的定义 (Definition of Done, DoD)。

XP 的历史与理念

XP 是一套旨在提高软件质量和响应客户需求变化的敏捷软件开发方法。它的许多实践被广泛采纳，并与Scrum等框架结合使用。

创始人: Kent Beck。

标志性项目: 克莱斯勒综合薪酬系统 (C3) 项目 (1996年)。这是XP实践首次被系统性应用和总结的地方。

核心理念: 把有益的实践（如测试、简单设计）做到极致 (Extreme)。

PPT 重点 ( 极限编程的历史背景 ): “尝试将多种‘最佳实践’组合应用，以快速响应需求变化并提高软件”。

XP 与变更成本曲线

传统观点: 软件变更的成本随时间指数级增长。因此，传统方法强调“早期做好一切”来避免后期昂贵的修改。

XP 的核心前提: 通过一系列技术实践，可以“压平”变更成本曲线，使得后期的变更成本不再高昂。

如何实现: 依靠简单设计、自动化测试、重构、持续集成等实践，让系统始终保持易于修改的状态。

PPT 重点 ( 降低变更成本的技术 , 哪些技术使得变更成本变低 ): 反复强调自动化测试（安全网）、简单设计、重构、CICD是降低变更成本的关键技术。“Beck的曲线并非无视规律，只是把反馈周期从几个月缩短到几分钟，结果就没有机会让成本成指数增长”。

XP 的定位

核心: XP 更侧重于工程实践 (Engineering Practices)。它提供了一套具体的、高质量的编码、测试和设计技术。

与Scrum的关系: XP 与 Scrum 是互补的。Scrum 提供了项目管理的框架（角色、事件、工件），但对如何进行技术工作着墨不多。XP 则填补了这一空白，提供了如TDD、重构、结对编程、持续集成等强大的工程实践来保证增量的质量。

PPT 重点 (Scrum局限): “Scrum不包含技术实践，但如果没有XP实践的支撑，Scrum难以成功。”

软件开发的四项基本活动

Kent Beck 提出软件开发围绕四项活动循环进行: 编码 (Coding)、测试 (Testing)、倾听 (Listening)、设计 (Designing)。这四项活动紧密相连，相互影响。

PPT 重点 ( 软件开发的基本内容 ): 图示清晰地展示了这四个活动之间的循环关系。

XP 的核心实践

XP 由一系列相互支撑的实践组成。

  1. 计划游戏 (Planning Game)

目的: 结合业务（客户）和技术（开发者）双方的考虑，共同决定项目的范围、优先级和发布计划。

分工: 业务方决定业务价值（什么更重要），技术方提供成本估算（什么更容易实现）。

  1. 简单设计 (Simple Design)

核心: 仅为当前需求做设计，保持设计尽可能简单。

四条基本规则:

  • 通过所有测试 (Passes all the tests)
  • 清晰表达意图 (Reveals all the intention)
  • 消除重复 (No duplication / DRY - Don’t Repeat Yourself)
  • 尽可能少的元素 (Fewest number of elements)

PPT 重点 ( 简单设计 ): “没有重复的逻辑。警惕像并行类层次结构这样的隐藏重复。” 反对“为今天实现，为明天设计”。

  1. 测试驱动开发 (Test-Driven Development, TDD)

核心循环: 红 (Red) -> 绿 (Green) -> 重构 (Refactor)

  • 红: 先编写一个失败的测试用例
  • 绿: 编写最少的代码使测试通过
  • 重构: 在保持测试通过的前提下，改进代码设计

价值: TDD 不仅是测试，更是一种设计活动，它能驱动出良好、解耦的设计。

PPT 重点 ( TDD , 红绿重构循环 ): “通过先写测试再写实现的逆向流程驱动代码设计”。

  1. 结对编程 (Pair Programming)

定义: 所有生产代码都由两位开发者在一个工作站上共同完成。

角色:

  • 驾驶员 (Driver): 负责敲键盘，关注具体的实现细节
  • 领航员 (Navigator): 负责从更战略性的角度思考，如整体设计、潜在问题、测试用例等

PPT 重点 ( 结对编程 ): 强调了两个人的不同思考角度。

  1. 重构 (Refactoring)

定义: 在不改变软件外部可见行为的前提下，改善其内部结构。

目的: 消除技术债，提高代码可读性和可维护性，为新功能开发铺平道路。

时机: 不是凭空猜测，而是“当系统要求你复制代码时，它就是在要求进行重构”。

  1. 代码集体拥有制 (Collective Ownership)

定义: 团队中的任何人都可以修改任何地方的代码。

目的: 鼓励团队成员为整个代码库的质量负责，促进知识共享，避免因个人成为瓶颈而导致延误。

  1. 现场客户 (On-Site Customer)

定义: 团队中有一位真正的客户或客户代表，能够随时回答问题，明确需求和优先级。

目的: 缩短反馈循环，确保团队开发出真正符合业务需求的产品。

  1. 编码标准 (Coding Standards)

定义: 团队遵循统一的编码规范。

目的: 提高代码的可读性，支持结对编程和代码集体拥有制。

持续集成的定义与核心目标

定义: 持续集成是一种软件开发实践，团队成员频繁地（通常每天至少一次）将他们的代码更改集成到共享的代码库主线 (Mainline) 中。每次集成都会触发一次自动化的构建和测试。

PPT 重点 ( 什么是持续集成(CI)? ): “团队成员频繁地 (通常每天至少一次) 将他们的代码更改集成到共享的代码库主线中。”

核心目标: 尽早发现并解决集成过程中可能出现的问题。

通过频繁、小批量的集成，将传统模式下“集成地狱”（一次性大规模集成的痛苦过程）的风险和成本分摊到日常开发中。

PPT 重点 ( 什么是持续集成(CI)? ): “核心目的是尽早发现并解决集成过程中可能出现的各种问题”。

持续集成的关键实践与要素

  1. 维护单一的代码库主线 (Single Source Repository / Mainline)

定义: 所有开发活动都围绕一个单一的、共享的、代表项目当前集成状态的分支进行。在Git中，通常是 main 或 master 分支。

这是CI的基石，所有集成都在这里发生。

PPT 重点 ( 实践 1 - 主线 (Mainline) 的重要性 ): “主线是代码库中一个单一的、共享的分支，它代表了项目当前的、经过集成的状态。”

  1. 自动化构建 (Automate the Build)

要求: 整个构建过程（编译、测试、打包等）必须能通过一个简单的单一命令来触发。

价值: 消除手动操作的复杂性和易错性，是实现自动触发的前提。

PPT 重点 ( 实践 2 - ⾃动化构建 ): “目标是实现‘一键构建’(Single Command Build)”。

  1. 让构建自测试 (Make the Build Self-Testing)

定义: 构建过程本身包含了运行自动化测试套件的步骤。构建的成功与否，不仅取决于编译是否通过，更取决于所有自动化测试是否通过。

价值: 一个成功的构建（“绿色构建”）能给团队信心，表明代码库处于健康状态。这是检测语义冲突的关键武器。

PPT 重点 ( 实践 3 - 让构建⾃测试 ): “作者将这种包含自动化测试验证的构建称为‘自测试构建’(Self-Testing Build)”。

  1. 立即修复失败的构建 (Fix Broken Builds Immediately)

原则: 修复失败的构建是整个团队的最高优先级。

首选方案: 恢复 (Revert) 导致失败的提交，以最快速度让主线恢复到健康状态，避免阻塞其他人的工作。

PPT 重点 ( 实践 5 - ⽴即修复失败的构建 ): “如果主线构建坏了，谁也别想回家” (Kent Beck)。

  1. 保持构建快速 (Keep the Build Fast)

重要性: 快速反馈是CI的核心价值。缓慢的构建会扼杀CI的活力。

目标时间: 经验法则是，主提交构建（Commit Build）应在十分钟内完成。

解决方案: 对于慢速测试，可以采用构建流水线 (Deployment Pipeline)，将构建分为快速反馈的“提交阶段”和更全面的“后续阶段”。

Kanban 的起源与核心理念

Kanban 是一种用于管理和改进知识型工作流程的方法，它强调通过可视化和限制在制品来优化价值的流动。

来源: 起源于日本丰田汽车公司的丰田生产体系 (Toyota Production System, TPS)。

目的: 最初用于管理生产线上的物料流动，实现准时化生产 (Just-In-Time)，核心是减少库存和浪费。

PPT 重点 ( Kanban的起源 - 制造业根基 ): “这种拉动式生产 (pull system) 极大减少了库存和浪费”。

核心理念:

  • 可视化 (Visualize): 将工作流程和工作项全部展现在看板上，让所有人都能看到工作的状态和流动
  • 限制在制品 (Limit Work in Progress, WIP): 限制同时进行的工作项数量，以避免多任务过载，减少排队，加速流动
  • 管理流动 (Manage Flow): 关注工作项如何顺畅地通过整个系统，识别并消除瓶颈
  • 持续改进 (Improve Collaboratively): 基于数据和团队的观察，不断试验和改进工作流程

Kanban 的关键元素与度量指标

  1. Kanban 看板 (Kanban Board)

定义: 可视化工作流程的核心工具。典型看板按流程划分为列（如：待办、开发中、测试中、已完成）。

作用: 作为信息辐射器，提供实时透明度，显示任务状态、位置和整体负荷。

  1. Kanban 卡片 (Kanban Card)

定义: 代表一个具体的工作项（如用户故事、任务、缺陷）。

作用: 在看板上流动，反映工作的进展。卡片上通常记录标题、负责人等必要信息。

  1. 工作流的定义 (Definition of Workflow, DoW)

定义: 团队对于工作流程各个阶段、流转规则、策略等达成的明确且共享的理解。

  1. 在制品 (Work in Progress, WIP)

定义: 介于工作流的开始节点与结束节点之间的任何一个工作项。

  1. 拉动系统 (Pull System)

理念: 下游主动拉取上游工作，而非上游推送。

实现: 当下游阶段有空闲容量（未达到WIP上限）时，才从上游就绪区拉取新卡片。这保证了系统按节奏工作，减少浪费。

  1. 度量指标
  • 在制品数量 (WIP): 正在进行的工作项总数
  • 周期时间 (Cycle Time): 一个工作项从开始处理到完成交付的总时长。这是衡量流程效率的核心指标
  • 产能 (Throughput): 单位时间内完成的工作项数量
  • 工作项存续时长 (Work Item Age): 一个工作项从开始处理到当前时刻所经过的时间

Kanban 与 Scrum 的区别

周期: Scrum是迭代式的，有固定的Sprint周期；Kanban是流动式的，没有固定的迭代周期。

角色: Scrum有三个规定角色（PO, SM, Developers）；Kanban不规定特定角色，通常保留现有组织架构。

变更: Sprint中通常不接受新需求变更；Kanban可以随时接受高优先级的变更，灵活性更高。

会议: Scrum有规定的5个事件；Kanban不强制规定会议，但鼓励建立反馈环路。

框架性质: Scrum是迭代式 (Iterative) 框架，Kanban是流动式 (Flow-based) 框架。这是最本质的区别之一。

PPT 重点 ( Kanban与Scrum的差异 ): 表格清晰对比了框架性质、角色、时间规划、流程和工件的差异。

Kanban 补充概念

硬币传递游戏 (Coin Game)

演示: 这个游戏通常用来演示小批量流动比大批量流动的效率更高。

结论: 每次只传递1枚硬币（单件流，对应最低的WIP）的方式，总交付时间最短，第一个产出的时间也最早。这直观地展示了限制WIP和持续流动的威力。

快速通道 (Expedite Lane)

定义: 为处理紧急工作而设置的特殊泳道 (Swimlane)。

规则: 进入快速通道的工作项通常可以绕过WIP限制，优先处理。

Scrumban

定义: 由 Corey Ladas 提出，是Scrum和Kanban的混合体，常被视为从Scrum到Kanban的中间态或过渡。

特点: 保留了Scrum的一些结构（如定期会议），但用Kanban的拉动系统和WIP限制取代了固定的Sprint承诺。

敏捷综合概念

行为驱动开发 (Behavior-Driven Development, BDD)

演变: 从 测试驱动开发 (TDD) 演变而来。

核心思想: BDD 更侧重于软件的行为，并使用一种业务人员和技术人员都能理解的通用语言 (Ubiquitous Language) 来描述这些行为。

格式: 通常使用 Given-When-Then 格式来编写验收标准。

用户故事地图 (User Story Mapping)

解决的问题: 传统线性的Backlog全局视角缺失。

实现方式: 通过二维结构（横轴是用户活动流程，纵轴是优先级和发布计划）来组织用户故事，提供了产品的整体视图。

DevOps 核心概念

定义: 一种文化、运动或实践，强调软件开发 (Dev) 和 IT运维 (Ops) 的协作和沟通，并通过自动化来加速高质量软件的交付。

与敏捷关系: DevOps 可以看作是敏捷理念从开发领域向交付和运维领域的延伸。敏捷关注“如何更有效地开发软件”，DevOps关注“如何更快更可靠地交付软件”。

核心实践: CI/CD、基础设施即代码(IaC)、监控与反馈等。

核心目标: 打破开发(Dev)与运维(Ops)之间的壁垒，通过自动化和协作，提升软件交付的速度(Velocity)和可靠性(Reliability)。它并不关心是否要固定软件架构。

与敏捷的关系: DevOps 扩展了敏捷的理念。敏捷聚焦于开发团队内部的效率和响应力，而DevOps将这种思想延伸到从代码提交到最终部署和运维的整个生命周期。

基础设施即代码 (IaC): 用代码的方式来管理和配置基础设施，实现自动化、可重复和版本控制。

DevOps 部署策略

金丝雀发布 (Canary Deployment): 将一小部分流量切换到新版本，进行观察。如果运行良好，再逐步扩大流量。这是一种低风险的渐进式发布策略。

蓝绿部署 (Blue-Green Deployment): 维护两套完全相同的生产环境（蓝和绿）。新版本部署在非活跃环境（如绿），测试通过后，通过负载均衡将所有流量瞬间切换到新环境。

DevSecOps: 将安全(Security)实践融入到DevOps流程的每个阶段，实现“安全左移”，强调内建安全(Build Security In)而非事后补救。

DORA 指标

定义: 衡量DevOps效能的四个关键指标。

精英团队标准:

  • 部署频率: 每日多次 (On-demand)
  • 变更前置时间: 少于1小时
  • 变更失败率: 0-15%
  • 平均恢复时间: 少于1小时

用户故事的3C原则

  • 卡片 Card
    • 在一堆卡片上写下你期望的软件特性
  • 交谈 Conversation
    • 聚在一起对要开发的软件进行深人讨论
  • 确认 Confirmation
    • 对完工条件进行确认