这似乎是我工作的重点。一些人抱怨Scrum项目缺乏验证结构，而Scrum的纯粹主义者则说这不是Scrum的目的。双方都提出了要点，但我想看看我圈子之外的人对这个问题的看法。你觉得呢？你有没有什么想法？为什么？

解决方案

回答

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

回答

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

Scrum的关键点之一是能够准确预测团队可以在sprint中完成什么。为此，我们必须考虑所有将消耗开发人员时间的事情。

这意味着诸如文档，测试和同行评审之类的事情都必须作为任务考虑在内。

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

从维基百科：

Product Backlog:  The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if "add spellcheck" feature is estimated at 3 days vs 3 months, that may affect the Product Owner's desire).
  
  Sprint Backlog: The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.

产品待办事项列表上的项目不会显示文档或者测试之类的内容，但Sprint待办事项列表上的任务肯定可以。

我举一个例子。假设产品待办事项列表上有一个"功能A"，估计时间为1周。在Sprint待办事项列表上，这可以分解为以下任务：

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待办事项列表背后的想法是人为地明确要在哪里花费时间。这就是为什么任务不能超过16小时的时间，这就是为什么我们可以使自己的时间表预测非常可靠的原因。

如果我们认真地遵循Sprint待办事项指南，并确保包括我们花费在开发时间上的所有内容，那么我们将对经过几次练习后的调度准确度感到惊喜。

回答

垂直思考，而不是水平思考。

如果我们将设计，编程和单元测试，测试等视为开发蛋糕的各个层，那么我想我们可能会看到作为蛋糕片交付的功能(故事)，每个部分都由一小部分设计，代码，测试，性能组成等等。这有点像务实程序员的"追踪项目符号"。

回答

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

回答

Scrum内置的关键验证结构之一是产品负责人负责接受故事。团队仅基于交付业务价值而获得速度认可。

Scrum团队的常用工具是定义产品积压项目的验收测试(通常这些积压项目以用户案例的形式出现)。

作为Scrum团队的一部分，我们需要回答该团队将使用哪些工程实践来帮助其交付高质量产品的问题。 Scrum本身对这些实践保持沉默(我认为有意让这些实践随着我们学习如何做得更好而随着时间而发展)。

这些实践可能是诸如单元测试，结对编程，同行评审之类的事情。通常，这些实践已成为团队对完成某件事的含义的定义的一部分。如果团队正在努力估算或者完成估算，则将其作为冲刺积压工作中的任务会有所帮助。我的建议是使流程轻巧，我们无需大声疾呼(但我们需要在估算中考虑到处理常规项目所花费的时间)。