BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Anand Vishwanath 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2012年4月30日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT