移动开发中的任务梳理：本质、目标与执行过程

什么是任务梳理？

Backlog Grooming（refinement）——为未来冲刺准备Product Backlog任务的过程。Product Owner和开发团队审查任务的会议：澄清需求，添加验收条件，评估复杂度，识别依赖关系和风险。Scrum Guide中没有强制性的“梳理”事件——这是Scrum团队为减少Sprint Planning中的不确定性而引入的额外实践。建议频率——每个冲刺1次，不超过60分钟。

“梳理”一词反映了本质：团队“梳理”积压任务，删除过时的任务，澄清模糊的任务，拆分过大的任务。在移动开发中，梳理尤为重要，因为平台特性：Android任务在复杂度上可能与iOS版本不同，需要考虑targetSdk、compileSdk、与API级别的兼容性。没有梳理，Sprint Planning会变成混乱：团队第一次看到任务，无法评估它们，导致不可预测性和延误。

梳理的成果——几个准备好进入Sprint Planning的任务：它们有描述、验收条件、评估，并符合Definition of Ready。Product Owner应按优先级顺序梳理任务：离当前冲刺最近的——最详细。3-4个冲刺后的任务——仅在史诗级别。渐进细化技术：任务越接近冲刺，其描述就越详细。对于当前冲刺中的任务——完全细化（验收条件、设计、API规范）。对于2个冲刺后的任务——故事级别（用户故事，不包含实现细节）。对于3+个冲刺后的任务——史诗级别（仅名称和商业价值）。

Definition of Ready：任务何时准备好进入冲刺

Definition of Ready（DoR）——任务在纳入Sprint Backlog之前必须满足的标准检查清单。DoR是Product Owner和团队之间的合同：PO保证所有开发信息都已就绪，团队保证能够评估和执行任务。DoR不是通用的——每个团队定义自己的标准集。没有DoR，任务可能带着模糊的需求进入冲刺，导致返工和延误。

移动开发的典型DoR：1）验收条件已描述（采用Given-When-Then格式的接受标准）。2）Figma中的设计模型已准备就绪（针对UI任务），包含所有状态：默认、加载、错误、空状态。3）API规范已批准（OpenAPI/Swagger，请求和响应示例）。4）存在故事点评估。5）已识别对其他任务的依赖关系。6）任务不依赖于未就绪的外部组件。7）移动特性：已确定目标OS版本、功能标志需求、对旧API级别的支持。

任务评估技术

Planning Poker——梳理中最流行的评估技术。每位开发者获得一套带有斐波那契数（1、2、3、5、8、13、21）的卡片。PO展示任务并解释。讨论后，所有人同时展示卡片。如果评估差异很大（例如3和13），开发者解释其评估，然后重新投票。迭代重复直到达成共识。Planning Poker的目的不是精确评估，而是发现对任务理解的差异。

T-Shirt Sizing——简化的快速评估技术：XS（1 SP）、S（2）、M（3）、L（5）、XL（8）、XXL（13）。适用于积压任务的初步排序，当任务很多且需要快速估计数量级时。T-Shirt Sizing之后，通过Planning Poker对下一个冲刺的任务进行更精确的评估。亲和估算——无需数字按相对复杂度分组排序任务；将任务从最简单到最复杂排列在桌子上，然后分组到集群中，每个集群获得一个评估。

在移动开发中，评估必须考虑平台复杂性。一个Android任务可能评估为5 SP，而同样任务在iOS上可能评估为3 SP（或相反）。这是正常的：不同平台有不同的实现复杂度。建议：如果是跨平台团队，请分别评估每个平台。使用相对比例：基准任务（例如带文本和按钮的屏幕）= 1 SP。其他所有内容——相对于它。根据Scrum.org（2025），经过3-4个冲刺后，团队评估准确度达到实际复杂度的±20%。

分解：如何拆分大型任务

大于8 SP的任务应分解为更小的任务。大型任务无法在一个冲刺中完成，难以评估，且不能带来进展感。分解技术：按水平层（UI → ViewModel → Repository → Network/DB）或按垂直切片（功能：一个完整屏幕）划分任务。水平分解更适用于移动开发：子任务1——UI布局（XML/Jetpack Compose/SwiftUI），子任务2——ViewModel + State，子任务3——Repository + Network，子任务4——单元测试。

垂直分解——将用户故事切割成具有独立价值的更小故事。示例：史诗“购物车” → 故事1 “将产品添加到购物车”，故事2 “显示购物车”，故事3 “从购物车删除产品”，故事4 “提交订单”。每个故事都有自己的商业价值，可以独立发布。SPoK（基于Kano的故事点）：按商业价值对故事进行排序（必须有、应该有、可以有），并按价值顺序实施。

梳理中的分解检查清单：1）任务大于8 SP？→ 分解。2）有验收条件吗？→ 如果没有，请添加。3）依赖于其他任务？→ 识别并记录依赖关系。4）包含不确定性？→ 在主任务之前添加Spike（调研）。5）需要设计？→ 检查模型就绪状态。INVEST规则：Independent（独立于其他）、Negotiable（可协商）、Valuable（对业务有价值）、Estimable（可评估）、Small（小）、Testable（可测试）。如果任务不满足INVEST——它还没有准备好进入冲刺。

梳理过程：分步指南

第1步：热身（5分钟）。Scrum Master提醒梳理目标和DoR。团队查看看板，PO显示将有讨论哪些任务。第2步：任务审查（30分钟）。PO依次介绍当前冲刺末尾和下一个冲刺开始的任务。每个任务：名称、描述、验收条件（如果有）、设计链接、API规范。团队提出澄清性问题：“有空状态的模型吗？”、“使用什么HTTP方法？”、“iOS minimum deployment target是什么？”。

第3步：评估（15分钟）。团队通过Planning Poker或T-Shirt Sizing评估任务。如果差异 > 2 SP，讨论原因并重新投票。规则：如果任务无法评估（需求不明确，没有设计），则返回给PO进行修改，并在下次梳理时带着澄清内容再来。不要评估包含未知因素的任务——这必然导致冲刺中的错误。第4步：记录结果（10分钟）。PO在Jira/Linear中记录评估结果，更新任务描述并设置优先级。

梳理成果：3-7个完全准备好进入Sprint Planning的任务（包含DoR、评估、设计、API）。PO更新积压任务：删除过期任务、合并重复任务、澄清优先级。重要：梳理不会结束PO的工作——在梳理之间，他需要准备后续任务。推荐节奏：PO准备3-4个任务进行梳理，团队处理它们。如果积压中有超过50个任务，PO应在梳理前进行优先级排序（MoSCoW或Weighted Shortest Job First）。

梳理与Sprint Planning的区别

梳理——是准备。没有承诺——任务只是澄清和评估。Sprint Planning——是承诺。团队从梳理准备的任务中选择，并承诺在冲刺中完成它们。主要区别：梳理不绑定到特定冲刺（总体积压细化），梳理中没有Sprint Goal，梳理可以在冲刺的任何时间进行。Sprint Planning——严格在冲刺开始时进行，并且始终导致Sprint Goal。

在梳理中，任务只是被评估，但不被纳入冲刺。在Planning中，任务从准备好的池子中选择。没有梳理，Sprint Planning需要6-8小时（而不是4小时），因为团队第一次看到任务，无法快速评估它们。80/20规则：Sprint Planning中80%的任务应完全准备就绪（经过梳理），20%——可以是新任务（紧急错误、热修复）。如果Planning中超过20%的任务未评估——梳理不充分。

梳理的常见错误

错误1：每月一次梳理。团队积累3-4个冲刺的任务，试图在2小时内澄清所有内容。结果：一半任务仍未评估，Planning占用全天时间。解决方案：梳理应定期进行——每个冲刺1次，60分钟。如果任务很多，请在冲刺中间添加第二次梳理。最好少做些任务但高质量的梳理，而不是多而肤浅。节奏：一次梳理3-5个任务，每个任务获得充分讨论和评估。

错误2：没有上下文的评估。PO展示任务“实现购物车屏幕”，没有设计、没有API、没有验收条件。团队“凭感觉”评估——13 SP。在Planning中，发现实际上是5 SP（因为屏幕很简单）。解决方案：如果没有设计或API，任务不予评估。PO有义务在梳理前准备材料。规则：“没有模型——没有评估”。例外：Spike任务——不确定性调研，它们在没有设计的情况下单独评估（根据调研复杂度，2-5 SP）。

错误3：梳理变成Planning。团队开始将任务分配给执行者，并讨论谁将做什么。解决方案：提醒梳理是关于澄清，而不是分配。分配——在冲刺开始后的每日站会上进行。梳理回答“做什么？”，Planning回答“什么时候做？”，每日站会回答“谁做？”。在一次会议中混合这些问题会降低每个会议的效率。Scrum Master应停止Planning讨论，将注意力转移到任务澄清上。

错误4：忽视技术债务。梳理中只讨论新功能，技术任务被忽视。3-4个冲刺后，技术债务积累到临界水平。解决方案：每次梳理至少应有1个技术任务通过评估。比例：每3个功能 → 1个技术任务。使用技术债务比率指标：冲刺中技术任务与功能任务的比例。目标值：0.25-0.3（25-30%的时间用于技术债务）。如果比率低于0.2——开发速度将在后续冲刺中下降。