将内容与方式分开 - 在敏捷环境中进行设计[关闭]

Question

在敏捷（scrum）环境中，如何让产品管理创建足够小的待办事项或故事，而不让他们完成所有设计（这不是他们的专长）？换句话说，在敏捷开发中如何将“内容”（业务需求）与“方式”（设计）分开？

Answer 1

通过 Scrum， 产品管理 应该是一个人：这 产品拥有者 .

你想做的事在这期间完成 冲刺计划, ，整个团队（产品负责人、scrummaster、开发人员）都应该在场。

这 什么 应定义为 用户故事 由 产品拥有者 。用户故事应该是高层次的，限制你的产品负责人表达业务需求 一句话故事就能解决问题.

例如 作为 StackOverflow 用户，我希望看到我的声誉

冲刺计划的目标之一是决定冲刺期间应该完成的故事。所以当产品负责人选定故事后，团队就可以将它们细分，简单谈谈设计（如何）并估计它们。

简而言之， 什么 应该由产品负责人来完成 如何 由团队。如果这个过程向产品负责人解释清楚，他就不会尝试设计所有的东西。如果他无论如何尝试，scrummaster 都会阻止他。

Answer 2

你必须做的第一件事就是教会你的产品管理层扮演产品负责人的角色，这也是大量 Scrum 项目失败的原因。您必须向他表明，他对项目的投资回报率负责，为此，他负责对故事/项目/业务需求/功能或您用于以最适合的方式组成产品待办事项列表的任何内容进行优先级排序。有价值的项目具有更高的优先级。

我赞成使用用户故事作为产品待办事项列表，然后在冲刺计划中，打破故事选择的较小任务来组成冲刺待办事项列表。

在编写或帮助 PO 编写用户故事时，您应该始终牢记的是，这些故事应该是 INVEST。 我独立, 氮可以协商的， V对客户有价值， 乙可估计， S商场和 时间稳定。

我认为一开始使用下面的模板可能有助于让 PO 专注于业务目标：

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

一个故事示例是“作为一名 stackoverflow 用户，我想对一个答案进行投票，以便可以轻松找到最有价值的答案。”

不要忘记让 PO 为 Sprint Backlog 的每个故事编写或定义验收测试，因为它可以用作确定故事是否完全实施的基本标准。

对于上面的示例，两种可能的验收测试是：

“测试对答案进行投票”

“测试投票否决答案”

通过这个故事和两个验收测试，团队知道 stackoverflow 用户可以对答案进行投票，并且要更新故事状态完成，系统有必要允许用户对答案进行投票而不抛出异常。

Answer 3

不要忘记，应使用加权系统（质数、斐波那契等）按重要性顺序对产品待办事项进行评级，这样，如果您的待办事项中有类似重要性的项目（即，2 个重量为 21) 的项目，那么理论上它们都应该尝试插入到 13 和 8 之前的冲刺中。

Answer 4

在积压（重新）估计期间（优先级排序后），团队应该进行建模，以便了解用户故事的全部范围并能够准确估计复杂性。这不是可能发生的建模的全部范围（团队可能会做更多的开发），但这是一个很好的起点，并且能够利用客户/产品负责人来回答问题进而。

因此，由此产生的讨论将帮助您与产品负责人合作，将他们的需求分解为有意义且合适的粒度。