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

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

译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s