在Scrum项目中，测试和同行评审是否应作为单个任务加入到每个冲刺中？

Question

这似乎是我工作的一个争论点。有些人抱怨Scrum项目中缺少验证结构，而Scrum纯粹主义者则认为这不是Scrum的内容。双方都提出了很多要点，但我希望看到圈外的人对这个问题的看法。你怎么看？为什么？

Answer 1

在一个Scrum项目中，任何需要完成的任务都应作为一个任务输入。

Scrum的关键之处在于能够准确预测团队在冲刺中可以完成的工作。为了做到这一点，你必须考虑将消耗开发人员时间的一切。

这意味着文档，测试和同行评审等内容都必须作为任务考虑在内。

编辑：基于Mendelt的文章，我将澄清一些事情。

从Wikipedia：

产品Backlog：产品积压是整个项目的高级文件。它包含了对所有必需功能，愿望清单项目等的广泛描述。它是将要构建的“什么”。它由任何人开放和编辑。它包含粗略估计，通常以天为单位。此估算有助于产品负责人衡量时间表，并在一定程度上优先考虑（例如，如果“添加拼写检查”功能估计为3天与3个月，这可能会影响产品负责人的愿望）。

Sprint积压：冲刺积压是一个非常详细的文档，其中包含有关团队如何实施即将到来的冲刺的要求的信息。任务分解成几小时，任务不超过16小时。如果任务超过16小时，应该进一步细分。 sprint backlog中的任务永远不会被分配，相反，团队成员会根据需要注册任务。在产品Backlog不会显示之类的东西文档或测试

项目，但对代办冲刺肯定应该的任务。

我举个例子。假设产品待办事项列表中有一个“功能A”，其预计时间为1周。在Sprint Backlog中，这可能被分解成以下任务：

 
Initial design document:    4 hours 
Development of subset 1 of Feature A: 8 hours 
Peer review of subset 1 of Feature A: 2 hours 
Testing of subset 1 of Feature A:  6 hours 
Development of subset 2 of Feature A: 8 hours 
Peer review of subset 2 of Feature A: 2 hours 
Testing of subset 2 of Feature A:  6 hours 
User Documentation for Feature A:  4 hours 
--------------------------------------------- 
Total time       40 hours 

编辑＃2： Sprint Backlog中背后的想法是要具体力所能及的究竟，你必须花时间。这就是为什么任务长度不能超过16小时，而且这就是为什么你的日程表预测非常可靠。

如果按照宗教Sprint Backlog中的指导方针，并确保包括一切你花费的开发时间，那么你将在你的计划如何准确是实践的几个冲刺后惊喜。

Answer 2

它应该，因为如果你没有明确地输入它们作为任务，那么它们可能不会完成。就如此容易。

Answer 3

认为是垂直而不是水平层。

如果考虑设计，编程和单元测试，测试等为层在发展蛋糕，我想你可以看到的功能（故事）您提交年糕片，每组由一个一小块设计，代码，测试，性能等等。这就像Pragmatic Programmer的“追踪子弹”一样。

Answer 4

在进行scrum之前，我们遵循了瀑布开发范例，其中包括在向版本控制提交任何内容之前的代码审查。自从转向Scrum以来，我们不会为代码审查分配单独的任务，因为它隐含在任何开发案例中。

Answer 5

Scrum内置的关键验证结构之一是产品负责人接受故事。该团队仅在提供业务价值的基础上获得速度信用。

Scrum团队的一个常用工具是定义产品积压项目的验收测试（通常这些积压项目以用户故事的形式出现）。

作为Scrum团队的一员，您需要回答团队将用什么工程实践来帮助提供高质量产品的问题。 Scrum本身在这些实践中保持沉默（我认为故意允许这些实践随着时间的推移而演化，因为我们学习如何更好地完成任务）。

这些实践可能是单元测试，结对编程，同行评审等等。通常这些都成为团队定义其要完成的事情的一部分。如果一个团队正在努力完成估算或者完成任务 - 将其作为sprint backlog中的任务进行调用会很有帮助。我的建议是保持流程轻量级 - 您不需要召集每一件小事（但您需要考虑在估计中执行常规项目所需的时间）。