了解Scrum

Question

我一直在按照瀑布模型作为.NET开发人员工作。比如，在一个12个月的项目中，通常我的团队会遵循分析、设计、编码和测试阶段。但是当涉及到遵循Scrum流程时，我真的不知道我需要如何处理。

考虑一个4周的Sprint和待办任务有10个。让Sprint现在开始。如果开发人员在前10天工作于某些待办任务，我不知道测试（包括SIT和UAT）是否仅需要剩下的10天来完成工作。现在我们的Sprint没有时间做最后一分钟的漏洞修复，只有极少数的漏洞可以在计划的Sprint内修复。

而且，在开发过程中，我们如何确保测试团队除了准备测试用例和等待我们交付功能外还保持忙碌？

这引出一个问题，我们是否需要在Sprint的前3天内交付第一个任务/特性，以便测试人员可以准备好他们的测试用例来测试该部分。

我还需要教育客户来帮助他们适应Scrum流程。

我需要一些指导方针、参考资料或案例研究，以确保我们的团队遵循正确的Scrum流程。任何帮助都将不胜感激。

- SARAVAN

---

一个4周的冲刺是相当长的时间。我强烈建议先从2周开始，如果需要可以进行调整。 - Shane Courtrille

在一个迭代周期中，设计需要在迭代开始时完成，还是假定在迭代开始之前已经有了设计，这意味着开发人员可以从迭代的第一天开始编码？ - SARAVAN

在可能的情况下，应该在冲刺开始之前完成详细设计。提供的细节越多，估算和故事点等就会更可靠。然而，分析也可以是冲刺的一部分。同意ShaneC的观点-4周有点长。尝试2周。这一切都关乎反馈-周期越短，您获得反馈的时间就越早。 - ratkok

Answer 1

在理想的Scrum团队中，测试人员和开发人员是团队的一部分，测试应该与开发并行进行，阶段重叠而不是顺序进行（在Sprint内顺序完成任务的做法被称为Scrumfall反模式）。顺便说一下，与此处表达的某些观点相反，最终的Scrum实现会产生DONE DONE stories，因此测试 - 包括IST、UAT - 应该在Sprint期间完成。

不，测试人员不必等待产品待办事项（PBI）完全实现才开始工作，他们可以开始编写验收测试场景，自动化它们（例如使用FitNess），设置测试数据集等（如果业务复杂，这需要一些时间），只要Sprint开始即可。

当然，这需要非常紧密的协作，并且提前发布接口或UI框架将有助于测试人员的工作，但是，测试人员实际上不必等待PBI完全实现。实际上，开发人员应该将验收测试用作DONE指标（“当验收测试通过时，我知道我已经完成了”）。

我并不是说这很容易，但这是成熟的（即精益的）Scrum实现和成熟的Scrum团队所做的事情。

我建议阅读Henrik Kniberg的在战壕中的Scrum和XP，这是非常好的实践指南。

_{¹正如Mary Poppendieck所写，测试人员的工作应该是预防缺陷（必要的），而不是发现缺陷（浪费）。}

- Pascal Thivent

---

我喜欢你关于Scrum中测试的评论。感谢你提出这个问题。 - SARAVAN

当我在infoQ注册以阅读Scrum文档时，它总是告诉我“会话超时”。还有其他关于“Scrum入门”的建议吗？ - Clay Nichols

Answer 2

你绝对不希望在迭代的前半段做所有的开发工作，而在后半段进行所有的测试。那只是一个更小的瀑布流模型。

你的故事和任务应该被分解成非常小、离散的功能块。(这可能需要一些时间来适应，特别是如果你正在处理一个像我的以前的工作中使用Scrum的庞大软件系统。) 在迭代开始时，测试人员正在开发他们的测试，开发人员正在开发他们的代码，在整个迭代过程中，任务和故事都会完成并进行测试。它们之间应该有相当不断的互动。

在迭代结束时，你可能会感到有点忙乱，因为你还没有习惯这种方法。开发人员会感到负担很重，因为他们正在同时处理其余的代码和测试人员提出的错误修复。测试人员会变得不耐烦，因为他们看到迭代即将结束，但仍有未经测试的代码。这是一个学习曲线，需要一些时间来适应，业务部门也需要意识到这一点。

重要的是，开发人员和测试人员真正合作估算时间，而不是简单地把彼此的数字加起来得出总数。开发人员需要意识到，他们不能计划在最后一刻编写新功能，因为这会让测试人员在周末匆忙地完成工作，这最终会落到开发人员头上来修复问题等。

有些任务需要在途中重新定义。有些故事可能在迭代结束时失败。这没关系，你可以在下一个迭代中解决它们。每个迭代开始时的计划会议是定义这些故事/任务的地方。记得要相互耐心，并确保业务部门能够耐心接受流程的变化。这将在长期内产生回报，而不是在第一次迭代中。

- David

---

好的，我可以使用您的评论来为客户辩护。谢谢！ - SARAVAN

Answer 3

冲刺并不意味着代码完美无瑕；如果还有剩余的漏洞，它们可以在下一个冲刺中解决，而原本将进入下一个冲刺的其他项目则需要被取出。你并不是要让冲刺达到完美，而是理想情况下，实现稳定。

- Dean J

Answer 4

您（具有讽刺意味）在过程中应用了过多的严格要求。像Scrum这样的敏捷流程的整个重点是进度表是动态的。在第一个迭代后，您将与用户/测试团队一起评估进展情况。此时，他们将要求您更改在第一个迭代中交付的细节和功能，或者要求您做更多工作。这取决于他们。

只有在确定团队速率（即在一个迭代中可以合理完成多少故事）之后，您才能开始为较大的项目估计日期和其他事项。

- Joel Martinez

---

这非常重要。你的过程可能一开始不完美，但如果你严谨、有一个好的Scrum Master可以挖掘问题，并且有开放和诚实的回顾，你将非常快速地识别浪费（“测试人员闲置了一周！”），然后提出解决方案（几乎肯定会看起来像Pascal + David的评论）。 - Cowan

Answer 5

首先，不是每个Sprint都会产生一个大版本（如果有的话）。对于前几个Sprint产生早期原型/Alpha版本是完全可以接受的，这些版本不必完全没有错误，但仍然能够向客户展示一些东西。这些东西甚至可能不是一个功能 - 它只能是一个骨架UI，仅供用户查看它将如何工作和显示。

此外，开发人员本身可以（并通常会）编写单元测试，因此在Sprint中交付的任何内容应该处于相当稳定的工作状态。如果一个新功能还没有完全完成，团队就不应该交付它。大型功能应该分成足够小的块以适合单个Sprint。

- Péter Török

---

所以我认为这个人（可能是团队领导）应该具备真正的技能，将需求/特性分解为任务，并应用传统的分而治之的规则来完成它们。 - SARAVAN

@SARAVAN，在Scrum中，整个团队（与产品负责人一起）通常会协作工作，而不仅是单个团队领导（实际上在Scrum中没有这样的角色）。当然，团队成员拥有不同的技能水平，但整个团队仍然会共同计划、估算和设计，以及解决在迭代期间出现的所有问题。 - Péter Török

我理解你的观点。希望我们的印度项目经理能够明白这一点，而不是仅仅要求我们在更短的时间内完成更多的工作 :) - SARAVAN

Answer 6

Scrum团队通常是跨职能的，这意味着整个团队负责在每个Sprint中构建完成的功能块。因此，如果QA测试人员没有完成测试，那只意味着Scrum团队没有完成测试。Scrum指望每个人都尽自己的一份力。当需要任何技能时，拥有这些技能的人会带头，但他们都必须尽自己的一份力。

- Srikar Doddi

Answer 7

尝试进行持续集成。团队应该养成这个习惯并保持持续集成。此外，在每次提交/交付后构建和执行自动化单元测试套件应该为您的代码库提供一定程度的信心。这种做法将确保团队随时拥有正常工作的代码。同时，它还将使得集成和系统测试在冲刺早期得以实现。

定义和创建（自动化）验收测试将让主要QA / 测试技能的人员从冲刺开始就忙碌和参与其中。请确保与产品负责人合作完成，以便所有人都在同一页面并参与其中。

- ratkok

Answer 8

我们的敏捷项目是从第一个迭代周期开始先让开发人员（进行了大量的企业框架培训等）参与进来的。然后在第二个迭代周期中逐渐加入QA。到了第三个迭代周期末，QA已经跟上了开发人员的步伐。从第四个迭代周期开始，当开发人员完成需求时，QA基本上已经完成了测试。通常留给QA测试的项目都是一些大型的数据复制和传输问题，更多的是确保数据的正确性，而不是实际的测试。

我们在“完成”的定义上遇到了一些问题，例如我们没有明确的定义。我们正在开发一个全新版本的系统，现在我们即将进入第六个迭代周期并准备部署到生产环境。第六个迭代周期实际上是我所谓的小型瀑布模型。我们减少了要实现的项目数量，以确保有足够的时间来处理可能出现的新问题。我们有一个代码冻结期，开发人员将在必要的分支上开始下一个迭代周期并修复问题。

产品负责人掌控着交付进度，因此我相信在部署方面不会出现任何问题。

我看到Pascal谈到了成熟的冲刺团队和“完成定义”。而敏捷开发总是关注于“在冲刺结束后立即交付”。然而，我不确定世界上有多少团队实际上正在这样做？至少我们还没有达到那个水平 :)

- sonstabo

Answer 9

Scrum中没有测试团队。它的开发团队是跨职能的。Scrum鼓励团队成员不要过于专业化，以避免依赖性。因此，在Scrum中，测试人员的角色与瀑布模型中有所不同。这是另一个讨论话题，但现在让我们集中于手头的问题。

我建议您在Sprint计划会议的how部分垂直地将故事切片为尽可能小的任务。建议将任务分解为尽可能小的单元，以便可以在一两天内完成。

在项目开始时定义DoD，并不断完善它。 一次只处理一个任务，并限制进行中的工作量。 按优先级顺序工作，并减少系统中的浪费。 不要进行详细的前期规划，并将最佳决策推迟到最后负责的时刻。 引入BDD和自动化等技术能力。

请记住，质量是整个团队的责任，因此不必担心由专门的人员进行测试。

- Usman Ghani Thakur