产品负责人应该交付有推动作用的需求说明

最新推荐文章于 2022-08-02 15:53:37 发布

原创最新推荐文章于 2022-08-02 15:53:37 发布 · 83 阅读

0 ·

CC 4.0 BY-SA版权

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强调：要定期根据产品的目标验证工作。