敏捷协作

瀑布是把需求、设计、开发、测试、上线排成线性阶段，上一阶段完成才进入下一阶段，文档驱动，适合需求稳定、合规要求高、一次交付的项目，如银行核心系统。 敏捷把工作切成小迭代（通常 1 到 4 周），每轮交付可用的增量并持续收集反馈调整，适合需求不确定、要快速验证的互联网产品。 区别的本质是对变化的态度：瀑布假设需求可提前冻结，敏捷假设需求会演化。 现实中常是混合模式，例如硬件部分用瀑布、软件部分用敏捷。

Product Owner 负责产品价值最大化，具体是管理并排序产品待办列表（Product Backlog），明确验收标准，决定发布什么与顺序，是业务方与团队之间的唯一需求出口。 Scrum Master 负责流程与服务，保障 Scrum 正确执行、清除障碍、组织事件，更像是教练而非项目经理，不直接分配任务。 Developers（开发团队）负责每轮交付可用的产品增量，自组织决定怎么做，团队规模建议 10 人以内。 常见误区是 PO 只传话不定优先级、SM 变成监工，这两点可以在面试中主动指出。

站会的目的是同步进展、暴露阻塞、做当日计划，时间控制在 15 分钟内。 正确开法是围绕看板逐项过任务，每人讲三件事：昨天完成了什么、今天计划做什么、有什么阻塞需要帮助。 常见错误是把站会开成向领导汇报、讨论技术细节停不下来、只念流水账不提风险。 改进方法：细节讨论会后单聊（会后跟进）、用看板可视化代替口头描述、固定时间地点形成节奏。 站会不是状态汇报会，而是团队自查与互助的对齐机制。

Product Backlog 是产品所有已知需求的唯一有序清单，条目包括功能、技术改造、缺陷与探索任务，按价值与优先级排序，顶端条目要足够细化以供迭代开发。 维护方法：PO 定期梳理（Backlog Refinement），评估价值、工作量与风险；排序常用 RICE 或加权最短作业优先；每个迭代开始时从顶端选取形成迭代待办（Sprint Backlog）； 明确每个条目的验收标准（故事遵循角色—能力—价值格式）。列表是动态的，业务变化时要敢于重排。 面试可强调：一个清晰排序的 Backlog 本身就是产品策略的表达。

DoD 即 Definition of Done，是团队共同约定的「完成」标准，典型内容包含代码评审通过、自动化测试覆盖、验收标准满足、文档更新、可部署到预发环境。 它的作用有三个：一是统一质量预期，避免「开发完成但测试发现做不完」的口径混乱；二是让增量真正可发布，保障每轮迭代交付可用软件；三是暴露隐性工作，把测试、文档这些容易被忽略的环节显性纳入估算。 与之对应的故事级验收标准（Acceptance Criteria）定义单个需求怎么算合格。 区分 DoD 与 AC 是这题的加分点。