Jeff Sutherland 最近提出：用户故事应该是“有推动作用的需求说明（enabling specification）”，能让团队不必跟产品负责人反复对话，就能高效地往前推进工作。
要想让敏捷团队达到最佳效率，用户故事必须是有推动作用的需求说明。如果做不到这一点，团队在 Sprint 中就要不断跟产品负责人对话，弄清楚用户故事的真正含义。这会降低故事交付过程的效率，并影响团队开发速度。
“有推动作用的需求说明”已经作为一个 Scrum 模式公布了。Jim Coplien 点出了产品负责人在交付这些规范说明时的角色。
产品负责人应该交付有推动作用的需求说明，这是一个标志，表明他或者她已经竭尽所能发掘了需求空间。有推动作用的需求说明意味着需求说明足够丰富，只要负责实现的人有一定的对应技能，他不需要太多后续澄清，就可以实现相应解决方案。
产品负责人要做好自己的功课，这比把需求说明在开发前写下来这个事实要重要得多。
对于不断改进需求说明质量和产品负责人的积极参与，Timothy D Korson 进一步讲述了这两件事的重要性。
我在做产品负责人的时候，我的要求是：所有进入 sprint 的产品 backlog 条目（product backlog item, 简称 PBI），必须把对应的验收条件和测试场景开发任务放到任务板上去。作为产品负责人，我会与负责那个任务的人保持联系，而且会在产出的测试场景上签上名字。其他任何在这个 PBI 展开工作的团队成员，他们都会认真地与我们保持联系。在田纳西州 Chattanooga 的一家公司最近采纳了这个方法，他们说这对他们的 Scrum 过程是一个重大改进，产品负责人在开发过程中能够更早地参与进来，提供反馈。尽早评审测试场景，这也帮助他们尽早了解情况，从而更快发现问题，减少了返工情形，并提升了工作效率。
在自己撰写的《 Specification by Example 》一书中，Gojko Adzic 建议：将需求说明以可执行测试的形式表述，还要让非技术背景的利益相关者能弄明白。
传统意义上的文档很快就过时了。如果让编程代码作为惟一可靠的功能说明来源，这又会造就信息瓶颈和黑洞。此时，带有示例并且撰写清晰的需求说明就能发挥作用。这些需求说明通过经常运行的验收测试得以验证，我们可以相信：系统完成了测试要求的功能，从另一方面说，这些文档仍然说明了系统的功能。带有示例并且撰写清晰的需求说明读起来也很简单，易于访问和理解，因此它们帮我们移除了信息瓶颈。
Siddhartha Govindraj强调：要定期根据产品的目标验证工作。
令人惊讶的是：很多敏捷团队有自己的 sprint 的验收条件和完成定义，却没有技术来验证应用是否符合目标或者方向的变更。实质上，他们还是在玩“需求说明就是上帝”这个游戏。
如果你是产品负责人，你的工作绝对不是仅仅接受或拒绝用户故事，而是要不断验证正在构建的产品是否符合目标，还要掌控方向。
您会撰写有推动作用的需求说明么？或是其他形式的用户故事验收测试条件？它是否有助于提升开发团队效率？
查看英文原文： Product Owner should deliver Enabling Specifications
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论