迭代结束时，团队先邀请业务代表查看可运行增量并讨论下一步优先级；随后团队内部分析构建等待过长，约定下个迭代改进。前后两项活动分别是（）。
迭代评审与干系人一起检查产品增量和环境变化，并调整后续方向；迭代回顾由团队检查人员、流程、工具和协作，形成下一步改进。
选项分析
错误。每日站会用于短周期同步，不承担完整增量评审。
正确。前者检查增量和方向，后者改进团队工作方式。
错误。顺序相反，投标人会议也与迭代过程无关。
错误。每个迭代末的检查和适应不等于整个项目收尾。
本题为什么容易错
两场会时间挨得近，容易被合并成一场。实践中可以紧凑安排，但目标、讨论对象和开放范围仍应分清。
简短答案
展示本次增量并调整待办列表，与改进团队工作方式分别是哪类会议，正确答案是 B（迭代评审；迭代回顾）。迭代评审与干系人一起检查产品增量和环境变化，并调整后续方向；迭代回顾由团队检查人员、流程、工具和协作，形成下一步改进。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 每日站会；项目启动会 | 本题干扰项 | 错误。每日站会用于短周期同步，不承担完整增量评审。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 迭代评审；迭代回顾 | 本题正确答案 | 正确。前者检查增量和方向，后者改进团队工作方式。 | 看到题干核心场景时优先联想到它 |
| 迭代回顾；投标人会议 | 本题干扰项 | 错误。顺序相反，投标人会议也与迭代过程无关。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 项目收尾；需求冻结会 | 本题干扰项 | 错误。每个迭代末的检查和适应不等于整个项目收尾。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 每日站会；项目启动会：错误。每日站会用于短周期同步，不承担完整增量评审。
- 迭代回顾；投标人会议：错误。顺序相反，投标人会议也与迭代过程无关。
- 项目收尾；需求冻结会：错误。每个迭代末的检查和适应不等于整个项目收尾。
知识点详解
迭代评审聚焦产品增量及其价值，通常邀请产品负责人、团队和相关干系人共同检查成果、市场或环境变化，并调整产品待办列表。迭代回顾聚焦团队效能，在相对安全的内部环境中检查人员、互动、流程、工具和完成定义，选择可执行改进。二者共同构成检查与适应，但不能互相替代。
备考速记
评审看做出的东西，回顾看做事的方法。
产品增量在产品增量场景中的作用
产品增量在本题中的核心价值，是解决“迭代结束时，团队先邀请业务代表查看可运行增量并讨论下一步优先级；随后团队内部分析构建等待过长，约定下个迭代改进。前后两项活动分别是（）”这个场景问题。复习时不要只背选项名称，还要理解它为什么适用于该场景，以及它能解决哪类安全、流程或管理问题。
同类题怎么考
- 根据会议讨论内容判断评审或回顾。
- 识别把回顾会开成绩效追责会的反模式。
产品增量在系统集成项目管理工程师软考中的考法
软考选择题通常不会只考概念定义，还会把产品增量放到产品增量场景中，要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时，先抓住题干中的业务场景，再看哪个选项最能解决该场景下的核心问题。
解题思路
记住两个问题就够了。评审会问“我们做出的东西对不对，下一步做什么”；回顾会问“我们这次是怎么做的，下次怎样做得更好”。题干前半有业务代表、可运行增量和优先级，显然是评审；后半是团队内部改善构建等待，属于回顾。
考点定位
Review 看产品和价值，Retrospective 看团队怎么工作。两者都在迭代末发生，但对象和参与者不同。
易错提醒
- 评审只做PPT汇报，没有展示可用增量。
- 回顾会邀请管理层追责，成员不再愿意暴露真实问题。
- 回顾产生十几项改进，却没有选一两项真正执行。
备考提示
- 给每类敏捷会议写出目的、参与者、输入和输出。
- 把评审产生的产品调整与回顾产生的过程改进分两列。
你可能还想了解
- 迭代评审需要哪些干系人参加？
- 迭代回顾为什么不适合做绩效追责？
- 评审和回顾可以合并吗？
本文小结
迭代评审与干系人检查可运行增量并调整产品方向；迭代回顾由团队检查协作和流程，选出下一迭代要落实的工作方式改进。