移动开发中的Sprint冲刺：本质、周期与规划

什么是开发中的Sprint冲刺？

Sprint冲刺 — 是固定时长的时间盒（timebox），在周期结束时团队交付一个可用的产品增量。冲刺概念是Scrum的基础，但也用于其他敏捷框架。在移动开发中，增量是指可以在设备上安装、测试并向利益相关者展示的应用构建。冲刺不可延长——如果任务未完成，将移至下一个冲刺。

冲刺的关键特征是固定时长。团队在批准后不会更改冲刺目标。这提供了可预测性：利益相关者知道何时会获得结果。在冲刺期间，团队自行决定如何分配工作。Scrum Master保护团队免受外部干扰——新任务不会添加到当前冲刺中。根据Scrum Guide 2025，这是保持可持续开发节奏（sustainable pace）的唯一方法。

冲刺由四个必需事件组成：Sprint计划会议（规划）、每日Scrum（每日同步）、Sprint评审会议（演示结果）、Sprint回顾会议（过程分析）。它们之间是主要工作：任务实施、测试、代码评审。每个事件的持续时间与冲刺长度成正比：对于2周冲刺，计划会议4小时，评审会议2小时，回顾会议1.5小时，每日站会15分钟。总计约8小时的仪式时间——占团队工作时间的10%。

Sprint冲刺的Scrum仪式

Scrum仪式（Ceremonies/Events）— 在冲刺框架内的结构化团队会议。Sprint计划会议在开始时、每日Scrum每天进行、Sprint评审会议和回顾会议在结束时进行。所有事件都有时间盒（时间限制）。Scrum Master监督时间盒和聚焦的遵守情况。每个仪式由整个Scrum团队参与：产品负责人、Scrum Master、开发人员。例外是每日Scrum（仅开发人员参与，产品负责人和Scrum Master可选）。

仪式与冲刺阶段的关联：计划会议确定方向（做什么和怎么做），每日站会同步（谁在做什么，有什么阻碍），评审会议展示结果（做了什么，没做什么），回顾会议改进流程（如何让下一个冲刺更好）。跳过回顾会议是团队最常见的错误：当截止日期紧迫时，首先被牺牲的就是回顾会议。这会导致流程停滞和重复同样的错误。Scrum.org（2025）的研究表明：每2周进行一次回顾的团队，速度提升速度快35%。

Sprint计划会议：迭代规划

Sprint计划会议 — 团队在冲刺开始时的会议，确定要做什么以及如何做。产品负责人从产品待办列表中提出优先任务。团队评估容量（capacity），考虑假期、会议、技术债务，并选择可以在冲刺中完成的任务。计划会议的成果是Sprint目标（冲刺目标）和Sprint待办列表（任务清单）。Sprint目标以简短语句表述：「实现订单页面并通过SBP集成支付」。

Velocity速度 — 团队速度，以每个冲刺的故事点衡量。最近3-5个冲刺的平均值。根据Scrum.org（2025）的数据，一个5人移动开发团队（3名Android + 2名iOS）在2周冲刺中的velocity为25-40 SP。计划会议将velocity作为上限——实际取量少10-15%以应对意外任务（代码评审、事故、协助其他团队）。容量 vs 速度：容量是「人时」，速度是「故事点」。容量考虑了假期、病假、会议。典型的损失率为25-30%的工作时间用于非编码活动。

计划分为两部分：「做什么」（PO讲解任务，团队澄清）— 2小时，和「怎么做」（团队分解和评估）— 2小时。对于移动项目，在「怎么做」部分讨论：与Android/iOS版本的兼容性、是否需要功能开关、对APK/IPA大小的影响、新权限。计划扑克技术用于评估：每个开发人员给出自己的故事点评估（1、2、3、5、8、13）。差异超过2个单位——讨论原因。这能在规划阶段而非冲刺中期发现隐藏风险。

Sprint冲刺执行：每日站会与跟踪

每日Scrum（站会） — 每天15分钟的团队同步会议。每个参与者回答三个问题：「昨天做了什么？」、「今天计划做什么？」、「有什么阻碍？」。每日站会不是给经理的状态报告，而是团队自组织的工具。如果在站会中发现两名开发人员正在处理同一任务——这是需要重组的信号。重要：每日站会不解决问题，而是发现问题——解决问题需要在站会后召集单独的会议。

Scrum板（冲刺看板）— Sprint待办列表的可视化。列：待办 / 进行中 / 评审中 / 已完成。每个任务在板上移动。燃尽图（Burndown Chart）— 按冲刺天数显示的剩余工作量图表。理想燃尽图是从总SP到0的直线。实际燃尽图是考虑任务完成情况的阶梯状图表。下降的燃尽图（低于理想线）——我们落后了。问题信号：如果冲刺中期完成了不到30%的任务——需要调整。可能未考虑风险或任务被高估。

对于移动开发，冲刺跟踪受特定因素影响：构建时间（CI中Android项目的构建可能需要30分钟以上）、等待App Store / Google Play审核（如果需要通过TestFlight向测试人员发布构建）、与不同设备的兼容性（在10多种型号上测试需要时间）。建议：在冲刺结束时预留1天缓冲用于最终测试和发布构建。根据Mind the Product（2025）的数据，这可以将冲刺未完成的风险降低40%。

Sprint评审会议与回顾会议

Sprint评审会议 — 向利益相关者展示增量。团队展示可工作的应用构建，而非幻灯片。时长——2周冲刺为2小时。产品负责人检查是否符合验收标准。利益相关者提供反馈，这可能会影响产品待办列表。评审会议不是报告，而是对话：利益相关者可以提问并提出更改建议。关键规则：Sprint评审会议是关于产品的，而不是关于过程的。我们展示取得了什么成果，而不是如何取得的。

Sprint回顾会议 — 团队内部会议，用于分析刚刚结束的冲刺。形式：开始做（Start Doing）、停止做（Stop Doing）、继续做（Continue Doing）。时长——2周冲刺为1.5小时。回顾会议是讨论问题的安全空间。规则：在回顾会议中不讨论技术细节（这有专门的技术会议）。只讨论流程、沟通、工具、文化。Scrum Master促进会议并确保每个参与者都发言。

回顾会议的成果是1-3个针对下一个冲刺的改进。如果团队确定了问题「代码评审时间过长」— action item：「设定评审SLA为4小时。如果评审未按时完成——开发人员在Slack中提醒」。行动项必须具体、可衡量，并分配给特定人员。根据Atlassian（2025）的数据，执行回顾会议行动项的团队在3-4个冲刺中将velocity提升15-25%。不执行的团队则停滞不前。

如何选择冲刺时长

2周 — 移动开发的标准。可预测性和灵活性之间的最佳平衡。足以：规划、实施3-5个中等功能、测试、展示结果。1周 — 适用于流程成熟度和CI/CD程度高的团队。需要快速决策、最小化官僚主义。适合早期阶段的初创公司，需要快速实验。缺点：仪式开销高（每周计划会议+评审会议+回顾会议=7.5小时）。

3-4周 — 适用于复杂项目，需要与硬件集成（可穿戴设备、IoT、BLE设备）、长时间的应用商店审核或大型迁移（例如从RxJava迁移到Coroutines）。长冲刺提供更多测试时间，但增加了「瀑布效应」的风险——团队失去敏捷灵活性。Scrum Guide建议：不要超过1个月。如果冲刺更长——评审会议上上下文过多，利益相关者无法提供有质量的反馈。

冲刺常见问题

问题1：范围蔓延（Scope Creep）。在冲刺中期，产品负责人添加了一个「紧急且重要」的新任务。团队同意——然后冲刺失败。解决方案：Sprint目标是合同。任何更改都需要重新审视Sprint目标，而这仅在紧急情况下才可能。新任务进入产品待办列表和下一个冲刺。如果任务确实至关重要——旧Sprint目标被取消，冲刺重新规划，但这是例外而非常规。范围蔓延频率超过每3个冲刺1次——表明产品负责人能力不足。

问题2：未完成任务。到冲刺结束时，50%的任务处于进行中，20%处于评审中，只有30%已完成。原因：高估容量、低估复杂性、意外缺陷。解决方案：在回顾会议中分析原因。如果系统性地无法按时完成——不要在计划会议中增加任务数量，而是减少。承担少20%任务的团队完成率更高（80%+对比50-60%）。计划会议检查清单：对每个任务检查验收标准、就绪定义和与其他任务的依赖关系。

问题3：形式化的回顾会议。团队为了走过场而进行回顾——15分钟、泛泛而谈、没有行动项。解决方案：每次更改回顾会议形式。方法：帆船法（什么在阻碍、什么在推动）、开始/停止/继续、快乐/悲伤/愤怒、4Ls（喜欢、学到、缺少、渴望）。设定有截止日期和负责人的行动项。在下一次回顾开始时检查之前行动项的完成情况。根据Atlassian（2025）的数据，使用不同回顾会议形式的团队产生的有用洞察多50%。