在敏捷环境中分离什么和如何设计[关闭]

随着Scrum, 产品管理 应该是一个人: 产品拥有者 .

你想做的是在 短跑计划 整个团队(产品所有者、ScrumMaster、开发人员)都应该在场。

这个 什么 应定义为 用户故事 由 产品拥有者 . 用户故事应该是高级别的,限制了产品所有者在 一句话故事就可以了 .

例如 作为StackOverflow用户,我想看看我的声誉

冲刺计划的目标之一是决定冲刺期间应该做的事情。因此,当产品所有者选择这些故事时,团队可以对它们进行细分,简单地讨论设计( 如何 )估计一下。

简而言之, 什么 应该由产品所有者完成, 怎样 由团队。 如果向产品所有者清楚地解释了这个过程,他就不会尝试设计任何东西。不管怎样,只要他尝试,清洁工就会阻止他。

您必须做的第一件事,也是导致大量Scrum项目失败的原因,是要教会您的产品管理人员扮演产品所有者的角色。你必须向他表明他对项目的投资回报率负责,为此,他负责优先考虑故事/ITEN/业务需求/功能,或你用来组成产品积压工作的任何东西,以使最有价值的ITEN具有更高的优先权。

我赞成将用户故事用作产品积压工作的ITEN,然后在Sprint计划中,打破小任务,将选择的故事组成Sprint积压工作。

在编写或帮助您的采购订单编写用户故事时,您应该始终牢记的是,这些故事应该是投资的。 我 非依赖性的, n 可辩论的, V 对客户有价值, e 可锻的, S 购物中心和 T 可转让的。

我认为在开始使用下面的模板可能有助于保持采购订单集中于业务目标:

“作为一种类型的用户,我想要-一些目标-所以-一些原因-。”

一个例子是“作为stackoverflow用户,我想投票决定一个答案,这样最有价值的答案就可以很容易地找到。”

不要忘记编写订单或为Sprint积压工作的每个故事定义验收测试,因为它可以用作确定故事是否完全实现的基本标准。

对于上述示例,两种可能的验收测试是:

“投票决定答案的测试”

“投票否决答案的测试”

通过这个故事和两个验收测试,团队知道StackOverflow用户可以对答案进行投票,并且对故事状态进行更新完成后,系统必须允许用户在不引发异常的情况下对答案进行上下投票。

别忘了,产品积压项应该按照重要性的顺序进行评级,使用一个加权系统(素数、斐波那契等),这样,如果您的积压项中有类似重要性的项目(即2个权重为21的项目),那么理论上,它们都应该尝试在13和8之前插入sprint。

在积压工作(重新)估计过程中(在优先排序之后),团队应该进行建模,以了解用户故事的全部内容,并能够准确地估计复杂性。这不是可能发生的建模的全部范围(团队可能会做更多的开发工作),但这是一个很好的开始的地方,并且能够利用客户/产品所有者随时回答问题。

因此,最终的讨论将帮助您与产品所有者合作,将他们的需求分解为一个有意义的、适当的粒度。