列表产品推广 产品待办列表细化

产品待办列表细化是创建可操作的产品待办列表的持续过程，使 Scrum 团队能够立即运行 计划。

Scrum 团队通过定期在小组中或与整个 Scrum 团队一起完善产品待办事项列表项来实现这一水平的熟练程度，而不是在每个 中作为 计划的一部分进行一次。改进背后的想法是与所有团队成员就特定工作项为何有价值、开发人员应构建什么以及如何在技术上实现工作达成共识。

Scrum 团队的这种能力对于通过定期交付有价值的增量来建立与管理层和利益相关者的信任至关重要。

尽管 2020 年 Scrum 指南放弃了之前的时间分配指南，但 Scrum 团队应保留多达 10% 的时间用于产品待办列表细化，这仍然是一条实用规则。

一般来说，围绕以下问题构建细化过程是有益的：

在我看来，Karl 的以下引用完美地描述了产品待办列表细化是每个 Scrum 团队成功的关键因素的原因：

“永远记住，不可能以一种不会被误解的方式说话：总会有人误解你。”

（来源）

产品待办列表细化的14条成功原则

这些是我的 14 个产品待办列表细化的首要原则：

细化的目的：细化的最后阶段是对原因、内容、方式以及可能是谁的共同理解，同时开发人员对他们可以在单个 中创建有问题的 项目充满信心。持续时间：单个产品待办列表项的细化可能需要几轮。保持精炼简短而频繁。持续细化：产品待办列表细化是一项持续的活动，而不仅仅是一个 60 分钟匆忙完成清单的孤立事件。团队成员花时间细化他们感兴趣的产品待办事项列表项，例如，当他们了解与任务相关的内容时。精炼产品待办列表项是 Scrum 团队在 期间的常规工作。不需要“全员参与”： 细化并不意味着所有团队成员一直参与所有细化活动；对于那些对各自的产品待办列表项目感兴趣的人来说，它是可选的。 细化适合每个人：产品负责人应努力让整个 Scrum 团队参与到产品待办列表细化过程中，而不仅仅是依靠“首席工程师”和设计师。采用包容性方法的原因很明显：在尝试解决复杂问题时，没有专家，但有许多相互竞争的想法。因此，将细化活动的积极参与者限制为少数团队成员会增加确认偏差的风险，因为意见和专业知识的多样性受到人为限制。局外人：邀请利益相关者和主题专家参加改进会议，他们可以帮助团队理解问题和合适的解决方案。

DoR：“就绪的定义”代表初级 Scrum 团队的临时训练轮或反模式。 不要提炼太远：让产品待办列表专注于产品目标，大约涵盖三到六个 的工作。由于过多的细化是浪费，这一重点将使细化工作最小化：只细化那些可能构建的产品待办列表项。用户研究：产品待办列表细化和产品发现密切相关，并行发生。用户研究是细化活动的一部分，包括开发人员，例如，进行用户访谈或使用生产数据构建原型。：在提炼 项目时，采用由 Bill Wake 推广的 原则：I – , N – , V – , E – , S – Small, T – 。（来源。）完成和验收标准的定义：有意义的产品待办列表细化需要一个可靠的完成定义。此外，在细化过程中了解完成的定义和验收标准之间的区别。此外，就如何应用两者达成共识。质量：在改进产品待办列表项时考虑技术债务和重构，因为这两者都是开发人员的持续努力，可以轻松占用他们 15-30% 的时间。估计：一旦你放弃了数字，用估计来结束改进是有意义的。

在优化结束时估计产品待办列表项有一个目的：了解我们是否都在同一页面上，关于团队的原因、内容和方式。或者换句话说，估计就是找到继续前进的结束。估计过程中的差异可能表明对产品待办事项项目性质的理解存在差异。或者，他们可能会指出团队可能应该解决的团队成员之间的技能差距。无论如何，这些问题增加了在即将到来的 中无法交付价值的风险。当您的 Scrum 团队决定将估算作为细化过程的一部分时，一定要坚持相对估算——故事点、T 恤尺码或赛狗，如果你愿意的话——并避免绝对估算。这些根植于工业时代和泰勒主义，与个人绩效、效率、报酬和努力承诺有关。而且，人类也不擅长它们。并非一切都是用户故事：不要成为用户故事格式迷恋的受害者：“作为数据库管理员，我想将数据库软件升级到 5.x 版，这样……” 用户故事从用户的角度描述了未来的系统状态。因此，虽然每个用户故事都是产品待办列表项，但并非所有产品待办事项项都是用户故事。还有其他工作项，例如错误、尖峰或上面提到的非功能性需求。因此，通过在细化过程中强制使用统一的 项目格式来避免浪费每个人的时间。此外，细化是关于团队成员之间发生的对话。这与选择正确的文档格式无关。结论

产品待办列表细化是创建可操作的产品待办列表的持续过程。Scrum 团队的这种能力对于与管理层和利益相关者建立信任至关重要，因为它允许定期交付有价值的增量。精细化是在复杂环境中降低风险的一种非常有效的方法。