Scrum 流程与需求管理规范

Scrum是一个广泛应用于敏捷项目管理的轻量级框架，旨在通过协作、迭代和增量交付来应对复杂问题并高效创造价值。其核心结构围绕三种角色、三类工件和五个事件展开。

三种角色包括：

• 产品负责人，定义产品愿景和需求优先级；
• Scrum Master，确保团队遵循Scrum过程并移除障碍；
• 开发团队，跨职能、自组织的执行小组。

三类关键工件是：

• 产品待办列表，所有需求的动态清单；
• 冲刺待办列表，当前迭代要完成的任务；
• 增量，每个冲刺结束时产生的可交付成果。

工作通过固定时长的冲刺（通常为2-4周）来推进，每个冲刺包含计划会、每日站会、评审会和回顾会这五个事件，以保障计划、同步、检视和适应的节奏。

Scrum强调透明、检视和适应，通过短周期快速交付可用产品增量，并根据反馈持续调整，特别适用于需求快速变化或具有不确定性的产品开发项目。

本文旨在梳理并优化 Scrum 流程，并结合实际工作经验，明确需求收集与管理规范，以提升团队协作效率与交付质量。

Sprint 流程概览

整个 Sprint 周期（时间盒）设定为 10 个工作日（两周），具体安排如下：

• Sprint 会议：5 天
• 开发：8 天
• 验收与总结：5 天
• 技术提升日：1 天（用于团队自主学习与技术探索）

核心会议流程：

• Sprint 计划会议 1：与原始需求方、产品负责人及团队共同确定 Sprint 目标及本周期要完成的既定产品待办事项（Product Backlog）。
• Sprint 计划会议 2：团队将既定产品待办事项拆解为具体的、可在一天内完成的任务（Task），形成 Sprint 待办事项（Sprint Backlog）。
• Scrum 每日站会：每日举行，限时15分钟，同步进度、计划与障碍。
• Sprint 评审会议：向需求方演示本 Sprint 完成的功能，验收成果是否达成既定目标。
• Sprint 回顾会议：团队复盘本 Sprint 的成功经验与待改进项，持续优化流程。

需求收集与管理规范

需求分类

需求来源包括外部业务团队与内部团队，例如：

• 新功能需求
• 可用性问题（Bug）
• 性能优化
• 技术债务偿还
• 概念性想法

需求提交模板

所有需求需通过以下模板提交，以确保信息完整、清晰。

填写说明：

需求种类：从以下选择

• 任务
• 可用性问题（Bug）
• 性能问题
• 概念想法

注意：即使是当前技术暂不可行的概念性想法，也欢迎提出，以激发创新。

优先级：从以下选择，避免滥用“非常紧急”

• 特别严重
• 非常重要
• 很重要
• 普通
• 低

注意：优先级依据商业价值与影响程度判定。紧急需求需业务方尽早规划并提出。

需求类型：

• 详细需求
• 毛坯需求

注意：我们接受不完整的需求雏形。产品负责人将负责梳理毛坯需求，不明确的部分可暂置。

需求标题：采用动宾短语格式，从使用者角度描述。

• 正确示例：“导出酒店每日PV、UV流量数据”
• 错误示例：“添加导出按钮”（技术描述）、“管理关键词”（动词宽泛，边界不清）

详细描述：必须按照用户故事（User Story） 格式书写。

• 格式：作为一个 <角色>， 我想要 <活动>， 以便于 <商业价值>。
• 示例：作为一名酒店运营人员，我期望能导出酒店页面的流量数据，以便分析用户行为并优化营销策略。
• 原则：需符合 INVEST 原则
• 独立性（Independent）：尽可能独立于其他故事。
• 可协商性（Negotiable）：细节可在沟通中确认，非固定合同。
• 有价值（Valuable）：必须对客户或用户产生明确价值。
• 可估算性（Estimable）：团队能估算其工作量。
• 短小（Small）：最好不超过8人/天的工作量，确保在一个迭代内完成。
• 可测试性（Testable）：有明确的完成标准和验收条件。
• 注意：
• 角色需具体，避免“用户”等过于宽泛的表述。
• 商业价值需具体、可衡量，避免“提升业绩”等空泛描述，应如“预计每月提升1万订单”。

验收条件：定义功能完成后的具体验收标准，是开发与测试的依据。

示例（针对“导出CN酒店每日PV、UV流量数据”）：

• 可基于用户角色配置导出权限。
• 可按天选择导出日期。
• 单次导出最大时间跨度为31天。
• 所有导出操作记录日志（操作人、时间）。
• 导出字段包含：PV、UV、跳出率、新访客占比。

价值验证：说明功能上线后如何量化跟踪效果（如通过特定数据指标、用户反馈收集等）。

Sprint 计划会议 1

目标：确定 Sprint 目标与既定产品待办事项列表。

会议准备

• 资源预订：会议室、投影仪、白板等。
• 提前一天发送会议议程与目标给所有与会者：
  • 原始需求人（可选）
  • 产品负责人
  • Scrum Master
  • 开发团队全体成员
• 产品待办事项列表已按优先级排序完毕。
• 明确 Sprint 时间表：
  • Sprint 起止日期
  • 各会议（计划会2、每日站会、评审会、回顾会）时间安排

会议议程

• 产品负责人向团队阐述本轮 Sprint 目标及高优先级需求（用户故事）。
• 开发团队就用户故事提出疑问，产品负责人或原始需求方现场解答。
• 讨论中若发现遗漏需求，可现场补充至产品待办事项列表。
• 讨论并最终确认需求的优先级顺序。
• 全体与会者对 Sprint 目标 和 既定产品待办事项列表 达成共识。

会议产出

• 确认的、可供 Sprint 计划会议 2 细化的既定产品待办事项列表。

产品待办事项列表模板

处理情况：等待处理 / 正在进行 / 已经完成 / 不予处理 / 暂时搁置 / 需要讨论

Sprint 计划会议 2

目标：将产品待办事项拆解为具体任务，生成 Sprint 待办事项列表，并再次确认 Sprint 目标。

会议准备

• 参会人员：产品负责人、Scrum Master、开发团队（原始需求方不参与）。
• 时间：在 Sprint 计划会议 1 结束后尽快举行（建议间隔10分钟）。
• 材料：会议1产出的既定产品待办事项列表、任务估算工具（如计划扑克）。

会议进程

• 团队逐项分析既定产品待办事项，讨论并拆解出实现所需的具体任务，例如：
  • 编码、测试、代码审查
  • 技术学习、文档编写
  • 部署、上线
• 对任务进行工作量估算（可采用计划扑克等方式）。任何预估超过1天的任务必须进一步拆解。
• 根据团队容量（速度），与产品负责人协商：
  • 若任务过多，则调整或移除部分低优先级事项。
  • 若任务量不足，则从产品待办事项中引入新需求。

会议产出

• 将最终确认的 Sprint 目标 和 本周期要完成的需求清单 邮件同步给：原始需求人、产品负责人、Scrum Master、开发团队。
• 将详细的 Sprint 待办事项列表（任务列表） 邮件同步给：产品负责人、Scrum Master、开发团队。

Sprint 待办事项列表模板

说明：一个“需求”可能对应多个“任务”。任务描述可以是技术性工作，如“设计数据库表结构”。

Scrum 每日站会

目标：同步进度，协调工作，及时发现并清除障碍。

会议准备

• 时间/地点：每日固定时间、固定地点举行，严格限时 15分钟。
• 参会人员：Scrum Master、开发团队。原始需求方可选择性旁听（不发言）。
• 工具：可视化任务板（如物理看板或电子工具），清晰展示任务状态（待处理、进行中、已完成）。

会议进程

每位团队成员依次回答三个问题：

• 上次站会后我完成了什么？
  • 将对应任务状态更新为“已完成”。
• 今天我将要做什么？
  • 若任务新开始：状态设为“进行中”。
  • 若任务不在当前列表：需添加到 Sprint 待办事项。
  • 若任务过大：需拆分为子任务。
• 我遇到了什么阻碍？
  • 任何阻碍进度的问题，由 Scrum Master 记录到 障碍待办事项列表（Impediment Backlog） 中。

纪律：

• 聚焦于进度同步，而非问题深入讨论。复杂问题应另安排专题会议。
• 仅限开发团队成员发言，确保会议高效。

会议产出

• 更新后的 Sprint 待办事项列表 与 障碍待办事项列表。
• 更新的 燃尽图（Burndown Chart），可视化剩余工作量。
• 由 Scrum Master 通过邮件向团队同步每日站会纪要。

障碍待办事项列表管理

• 此列表用于跟踪所有阻碍团队进度的内部或外部问题。
• Scrum Master 负责推动列表中的每一项障碍得到分配和解决。
• 典型障碍示例：
  • 会议纪律涣散，流程未被遵循。
  • 产品目标或 Sprint 目标不清晰。
  • 产品负责人无法及时响应问题。
  • 团队规模过大或成员地理位置分散。
  • 遇到未预料的技术难题。
  • Scrum Master 身兼多职，无法专注服务于团队。

Sprint 评审会议

目标：检视本 Sprint 的产出成果，验证是否达成 Sprint 目标，并收集反馈以调整后续方向。

会议准备

• 资源预订：会议室、演示设备。
• 提前一天发送议程。
• 参会人员：原始需求人（关键）、产品负责人、Scrum Master、开发团队。
• 材料准备：Sprint 目标、既定产品待办事项列表、可工作的软件增量。

会议进程

• 开发团队演示本 Sprint 完成的可工作产品功能。
• 产品负责人与需求方根据验收条件进行评审。
• 收集反馈：
  • 若提出功能修改或新想法：作为新项加入产品待办事项列表。
  • 若发现未解决的障碍：加入障碍待办事项列表。

会议产出

• 全体与会者对 Sprint 产出成果 和 产品整体开发现状 达成共识。
• 更新后的产品与障碍待办事项列表。

Sprint 回顾会议

目标：回顾 Sprint 过程，总结经验教训，制定改进措施，持续提升团队效能。

核心原则：我们坚信，在当时的认知、技能、资源和环境下，每个人都已尽力做出了最好的贡献。回顾的目的是改进流程，而非指责个人。

会议准备

• 参会人员：Scrum Master、开发团队全体成员、产品负责人（可选）。
• 工具：便签纸、白板、计时器。
• 白板布置：
  • 张贴“核心原则”。
  • 绘制一条贯穿 Sprint 周期的时间轴。
  • 设立三个区域：“做得好的/成功经验”、“可以改进的”、“改进责任人（团队/公司）”。

会议进程

• 设定基调：重申会议目标与核心原则。
• 时间轴回顾：团队成员用便签写下 Sprint 期间的关键事件，贴在时间轴上并简短分享。
• 收集反馈：
  • 成功经验：每人写下并分享做得好的方面。
  • 改进点：每人写下并分享可以改进的方面。
• 归因与规划：
  • 针对每个“改进点”，讨论“谁负责”推动解决（团队内部或需公司层面支持）。
  • 将对应的便签移至“改进责任人”区域。
  • 团队共同对改进项进行优先级排序。
• 总结与收尾：会议主持人总结，并请每位成员对本次回顾会给予简短反馈。

会议产出

• 明确的、公开的 团队改进行动计划（来自“改进责任人”区域）。
• 将需要公司层面支持的障碍，加入 障碍待办事项列表。
• 完整的会议纪要邮件发送给整个团队。