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
评论