了解Scrum

Question

我一直在使用瀑布模型作为.net开发人员。在工作时，比如12个月的项目，我的团队通常会遵循分析，设计，编码和测试阶段。但是当谈到Scrum流程时，我并不真正理解我需要如何处理它。

考虑冲刺4周，积压有10个项目。让冲刺现在开始。如果开发人员在前10天处理一些积压项目，我不知道测试（SIT和UAT）是否需要在剩余的10天内完成工作。现在我们的sprint没有时间做最后一分钟的错误修复，只有少数错误可以修复到计划的SPRINT中。

当我们进行开发时，我们如何才能确保我们让测试团队忙于准备测试用例并等待我们提供功能？

如果我们需要在sprint的前3天内提供第一个任务/功能，这就提出了一个问题，以便测试人员可以准备好测试用例来测试该部分。

我还需要教育我的客户帮助调整Scrum流程。

我需要一些指南，参考或案例研究，以确保我们的团队遵循适当的Scrum流程。任何帮助将不胜感激。

Answer 1

在一个理想的Scrum团队中，测试人员和开发人员 团队的一部分，并且测试应该与开发的并行，阶段重叠，而不是顺序（执行） Sprint内部的顺序是一种称为Scrumerfall的反模式。顺便说一句，与此处表达的一些观点相反，最终的Scrum实现产生DONE DONE故事，所以测试 - 包括IST，UAT - 应该在Sprint期间完成。

不，测试人员不必等待产品积压项目（PBI）完全实施以开始工作，他们可以开始编写验收测试scenarii，自动化它们（例如，一旦Sprint启动，FitNess），设置测试数据集等（这需要一些时间，特别是如果业务复杂）。

当然，这需要非常密切的协作，并且尽早释放界面或UI骨架将有助于测试人员的工作，但是，测试人员仍然不必等待PBI完全实现。实际上，开发人员应该使用验收测试作为DONEness指标（“我知道我在接受测试时已经完成了”） ¹ 。

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

我建议阅读Henrik Kniberg的Scrum And XP from the Trenches，这是非常好的实用指南。

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

Answer 2

你绝对不希望在sprint的前半部分进行所有开发，在下半部分进行所有测试。那只是一个较小的瀑布。

您的故事和任务应该分解为非常小的，独立的功能。 （可能需要一段时间才能习惯这样做，特别是如果您正在使用的软件是像我之前使用scrum的工作那样的整体野兽。）在sprint开始时，测试人员正在开发他们的测试和开发人员正在开发他们的代码，并在整个sprint中完成和测试任务和故事。他们之间应该有相当稳定的互动。

当你习惯了这种方法时，冲刺的结束可能会让你感到有些忙乱。开发人员在处理其余代码时会感到负担，同时还会被测试人员修复。测试人员会变得不耐烦，因为他们看到sprint的结束迫在眉睫，而且还有尚未经过测试的代码。有一个学习曲线，需要一些人习惯，业务需要意识到这一点。

开发人员和测试人员真正合作创建他们的估算值非常重要，而不仅仅是添加彼此的数字以形成总计。开发人员需要意识到他们不能计划在最后一刻之前编写新功能，因为这会让测试人员在周末离开他们的工作，这将最终落后于开发人员in and fix stuff等。

有些任务需要在此过程中重新定义。一些故事将在冲刺结束时失败。没关系，你会在下一个冲刺中得到它。每个sprint开始时的计划会议将定义这些故事/任务。记住要彼此保持耐心，并确保业务对过程中的变化耐心。从长远来看，它将获得回报，而不是第一次冲刺。

Answer 3

sprint并没有以完美的代码结束;如果有剩余的错误，他们可以进入下一个冲刺阶段，并且需要取出下一个冲刺中的其他一些项目。你并没有用一些完美的东西来阻止冲刺，但理想的情况是稳定的东西。

Answer 4

<讽刺的是，你对这个过程过于严谨。像scrum这样的敏捷过程的重点是时间表是动态的。在第一次sprint之后，您将与用户/测试团队一起评估进度。此时，他们会要求您更改第一个sprint中提供的详细信息和功能，否则他们会要求您执行更多工作。这取决于他们。

只有最终，一旦你确定了团队的速度（即，在sprint中可以合理完成多少个故事），你就可以开始估算大型项目的日期和事情了

Answer 5

首先，并非每个Sprint都会产生一个大版本（如果有的话）。第一次冲刺产生早期原型/ alpha版本是完全可以接受的，这些版本预计不会没有bug，但仍然能够向客户端演示某些东西。这个东西甚至可能不是一个功能 - 它可以只是一个骨架UI，只是为了让用户看到它的外观和工作方式。

此外，开发人员自己可以（并且通常会）编写单元测试，因此sprint中提供的任何内容都应该处于相当稳定的工作状态。如果新功能被半熟，团队就不应该提供它。大特征应该分成足够小的块以适应单个冲刺。

Answer 6

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

Answer 7

尝试进行持续集成。团队应该养成这种习惯并不断整合。此外，在每次签入/交付后构建并执行自动化单元测试套件应该可以为您的代码库提供一定程度的信心。这种做法将确保团队始终具有工作和理智的代码。此外，它还将在sprint的早期实现集成和系统测试。

定义和创建（自动化）验收测试将使初级QA /测试技能的人员在sprint开始时保持忙碌和参与。确保这是与产品负责人合作完成的，这样每个人都在同一页面上并参与其中。

Answer 8

我们在第一个sprint中首先与开发人员（在Enterprise Framework中进行了大量培训等）开始了我们的敏捷项目。然后我们将QA慢慢添加到第二个sprint中。在sprint 2结束时，QA开始测试。在冲刺结束时关闭3 QA已经加快了步伐，并且或多或少地与开发者并驾齐驱。从sprint 4开始，当开发人员完成故事时，QA或多或少完成了测试。通常需要测试的项目是大象，包括在新旧系统之间复制数据。它更像是“确保数据正常”而不是实际测试。

我们对Done的定义存在一些问题。例如。我们没有。我们正在开发一个全新版本的系统，现在我们正在接近sprint 6的最后阶段，我们正准备部署到生产环境。 Sprint 6实际上是我称之为小瀑布的东西。我们减少了要实施的项目数量，以确保我们有足够的时间来管理可能出现的新问题。我们有一个代码冻结，开发人员基本上会开始下一个sprint并修复必要的分支中的问题。

产品所有者是交付的最重要的，因此我预计在部署方面没有任何问题。

我可以看到Pascal写的关于成熟的sprint团队+ Done的定义。而且敏捷始终专注于“在冲刺结束后立即交付”。但是 - 我不确定世界上是否有很多球队真的在做这个？我们至少还没有：）

Answer 9

Scrum中没有任何测试团队。它的开发团队是跨职能的。 Scrum不鼓励团队中的专家，以避免依赖。因此，测试者在Scrum中的作用与在瀑布中的作用略有不同。它的另一个辩论，但现在让我们坚持手头的问题。

我建议你在sprint计划会议的一部分中尽可能小的垂直切片。建议将任务分解为小型单位，以便在一两天内完成。

在项目开始时定义DoD并继续对其进行优化。 一次完成一项任务并限制正在进行的工作。 按优先顺序工作，减少系统浪费。 不要进行详细的前期规划，并将最佳决策推迟到最不负责任的时刻。 介绍BDD和自动化等技术能力。

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