对于业务分析师(或其他非开发团队成员)来说，与开发人员一起跟踪故事是很常见的吗？

Question

我们正在使用与Greenhopper一起使用的JIRA，目前我们的业务分析师有任务进行分析，这些任务最终将导致新的故事被放置在待办事项中，与当前sprint的故事一起运行，这感觉有点混乱--特别是因为它们不重叠开发故事的工作流程。

这种情况常见吗？应该是吧？这感觉就像分析应该是一个外部过程，输入到产品待办事项中，而不是标记在sprint待办事项上的东西，但我对scrum还是新手。

我咨询了scrum指南，没有看到任何明确的内容，虽然我们没有真正的产品负责人(虽然有时我会说我们的经理填补了这个角色，而其他时候业务分析师也是这样)，但我想我也可以将这个问题表述为：

产品负责人应该在开发团队工作的故事旁边跟踪他们的任务吗？

Answer 1

业务分析师是团队的一员吗？如果是这样的话，那么请考虑Scrum指南对于不将团队划分为角色非常清楚：

• Scrum除了开发人员之外，不承认开发团队成员的头衔，而不管开发人员正在做什么工作；
• 个别发展小组成员可能具有专门技能和重点领域，但问责制属于整个发展小组；
• 开发团队不包含专门用于测试或业务分析等特定领域的子团队。

因此，要么巴斯是团队的平等成员，因此他们的工作也是如此，要么他们不是，它不是。如果他们是团队的一部分，并且有一个可衡量的目标(你知道什么时候“完成”)，那么在Sprint中，这是一个可行的任务。

此外，用户故事是关于用户所要求的功能的故事。它本身并不是要做的工作清单。所以，你所说的并不是一个真正的“故事”。

因此，在实际方面，我建议您将具有业务分析技能的人员包括在您的团队中，并使用它们帮助完成您的故事。在开始一个故事之前，团队不会知道关于一个故事的所有事情--他们只是知道有一些东西需要他们去学习和解决。那些具有业务分析师技能的人在阐述故事和翻译业务时将会非常有帮助，因为它们可以被编码和测试。如果在sprint计划期间，您确定要完成分析任务，那么将它们添加到您的sprint待办事项清单中，并让人处理它们。

Answer 2

以我的经验..。

优点：

• 它给开发人员一种温暖的感觉，他们并不是唯一被期望透明的人。
• 它确实有助于产品负责人理解过程。

缺点：

• 它使产品负责人相信，他们所做的工作与开发人员所做的有一定的可比性。
• 它不必要地使工作板复杂化。
• 它几乎没有给任何人提供真正有用的信息。

就我个人而言，我认为这些优点可以通过其他方式来实现。但是这些缺点并不是不可接受的，所以如果产品负责人真的想要它，就让他们拥有它直到它证明是浪费时间为止。

Answer 3

故事是一小块功能，是一段可测试的代码，它提供了一些价值。因此，工作流应该是提出、分析、编码、测试和发布的。

因此，这些都是整个团队拥有的，并且作为工作管道的一部分，将从一个“纪律”/专家过渡到另一个。如果必须的话，你可以使用“挂起”故事的子任务，然后是“分析”、“编码”等等。或者你可以(我会)在你的待办事项中有“分析”、“编码”、“测试”、“完成”等列。

我一直处于您描述的情况，通常情况下，当我们试图对我们的故事中的任务有太多的细节时( JIRA和VSTS这样的工具不能很好地处理--即使他们这么说)。你需要问自己一个问题:你真的需要所有的细节吗?或者简单地让一个故事在它的生命过程中完美地浮出水面不是更清晰和容易吗？