理解 Scrum [关闭]答案

【问题标题】：Understanding Scrum [closed]理解 Scrum [关闭]
【发布时间】：2010-06-24 14:55:56
【问题描述】：

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

考虑 4 周的 sprint，积压工作有 10 项。现在就开始冲刺吧。如果开发人员在前 10 天处理一些待办事项，我不知道测试（SIT 和 UAT）是否只需要剩下的 10 天来完成工作。现在我们的 sprint 没有时间在最后一刻修复错误，在计划的 Sprint 中只能修复少数错误。

而在我们进行开发时，除了准备测试用例和等待我们交付功能之外，我们如何确保让测试团队保持忙碌？

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

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

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

【问题讨论】：

顺便说一句，4 周的冲刺相当长。我强烈建议您从 2 周开始，如果您觉得需要进行调整。
所以在 sprint 中是否需要在 sprint 开始时完成设计，或者 sprint 假设设计在 sprint 开始之前可用，这意味着开发人员可以从第一天开始编码冲刺？
尽可能在 sprint 开始之前进行详细设计。可用的细节越多越好（更可靠的估计、故事点等）。但是，分析也可以是 sprint 的一部分。同意 ShaneC - 4 周开始有点长。尝试 2 周。一切都与反馈有关 - 周期越短，您越早获得反馈。

标签： process agile scrum

【解决方案1】：

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

不，测试人员不必等待产品待办事项 (PBI) 完全实施即可开始工作，他们可以开始编写验收测试场景，将它们自动化（例如，使用FitNess），设置测试数据集等（这需要一些时间，尤其是在业务复杂的情况下），一旦 Sprint 开始。

当然，这需要非常密切的协作，尽早发布界面或 UI 框架将有助于测试人员的工作，但测试人员仍然不必等待 PBI 完全实现。实际上，开发人员应该将验收测试用作完成度指标（“当验收测试通过时，我知道我已经完成了”）¹。

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

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

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

【讨论】：

我喜欢您关于 Scrum 测试的评论。感谢您提出这个问题。
当我注册 infoQ 以阅读 Scrum 文档时，它总是告诉我“会话超时”还有其他关于“SCRUM 介绍”的建议吗？

【解决方案2】：

您绝对不想在 sprint 的前半部分进行所有开发，而在后半部分进行所有测试。那只是一个较小的瀑布。

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

当您习惯这种方法时，冲刺结束时可能会感觉有点忙。开发人员在处理其余代码时会感到负担重，同时还要让测试人员修复错误。测试人员会变得不耐烦，因为他们看到 sprint 即将结束并且还有代码没有经过测试。有一个学习曲线，需要一些时间来适应，企业需要意识到这一点。

重要的是，开发人员和测试人员必须真正一起工作来创建他们的估算值，而不是仅仅将彼此的数字相加来形成一个总数。开发人员需要意识到，直到最后一刻，他们才能计划编写新功能，因为这会让测试人员在周末匆忙完成他们的工作，最终将不得不依赖即将到来的开发人员在和修复东西等。

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

【讨论】：

好吧，我可以告诉你用你的 cmets 来证明客户的合理性。谢谢！！！

【解决方案3】：

冲刺不会以完美的代码结束；如果还有剩余的错误，它们可以在下一个 sprint 中进行，而其他一些本应在下一个 sprint 中出现的项目将需要删除。你不是用完美的东西来停止冲刺，而是用稳定的东西来停止冲刺。

【讨论】：

【解决方案4】：

您（讽刺地）对流程过于严格。像 Scrum 这样的敏捷过程的全部意义在于日程安排是动态的。在您的第一个 sprint 之后，您将与用户/测试团队一起评估进度。那时，他们会要求您更改在第一个 sprint 中交付的细节和功能，或者他们会要求您做更多的工作。这取决于他们。

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

【讨论】：

这非常重要。你的流程一开始可能并不完美，但如果你很严谨，有一个可以梳理问题的优秀 Scrum 大师，并且有公开和诚实的回顾，你会很快识别浪费（ '测试人员坐了一个星期无所事事！'）然后想出解决它的方法（这几乎肯定会最终看起来像 Pascal + David 的 cmets）

【解决方案5】：

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

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

【讨论】：

所以我认为这个人（可能是团队负责人）应该有真正的技能来对任务进行需求/功能分解，并应用传统的分而治之的规则来完成它们。
@SARAVAN，在 Scrum 中，更像是整个团队（与产品负责人一起），而不是一个团队领导（实际上在 Scrum 中没有这样的角色）。当然，团队成员的技能水平不同，但整个团队仍然在计划、估算和设计方面共同努力，并解决冲刺期间出现的所有问题。
我明白你的意思。希望我们的印度项目经理需要了解这一点，而不是仅仅要求我们在更短的时间内完成更多的工作:)

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

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

【讨论】：

【解决方案8】：

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

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

产品负责人负责交付，因此我预计我们的部署不会有任何问题。

我可以看到 Pascal 写的是成熟的 sprint 团队 + 完成的定义。敏捷始终专注于“冲刺结束后立即交付”。但是 - 我不确定世界上是否有很多团队实际上在这样做？我们至少还没有:)

【讨论】：

【解决方案9】：

Scrum 中没有任何测试团队。它的开发团队是跨职能的。 Scrum 不鼓励团队中的专家，以避免依赖。所以测试人员在 Scrum 中的角色与在瀑布中的角色有些不同。这是另一场辩论，但现在让我们坚持手头的问题。

我建议您在 sprint 计划会议中将故事纵向分割成尽可能小的任务。建议将任务分解为小单元，以便在一两天内完成。

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

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

【讨论】：