Process 理解Scrum

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

考虑为期4周的sprint，backlog有10项。让我们现在就开始冲刺吧。如果开发人员在前10天处理一些待办事项，我不知道测试（SIT和UAT）是否只需要剩余的10天来完成工作。现在我们的sprint没有时间在最后一分钟修复bug，在计划的sprint中只有很少的bug可以修复

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

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

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

---

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

sprint不会以完美的代码结束；如果还有剩余的bug，它们可以在下一个sprint中使用，而在下一个sprint中使用的一些其他项目将需要删除。你不是在用完美的东西来阻止冲刺，而是在理想情况下，用稳定的东西来阻止冲刺。

讽刺的是，你对冲刺过程太过严格了。像scrum这样的敏捷过程的全部要点是日程安排是动态的。在第一次冲刺之后，您与用户/测试团队一起评估进度。在这一点上，他们会要求您更改在第一次sprint中交付的细节和功能，或者要求您做更多的工作。这取决于他们

---

只有最终，一旦你确定了团队的速度（即一个sprint可以合理地完成多少故事），你才能开始估计更大项目的日期和事情。首先，不是每个sprint都会产生一个大的发布（如果有的话）。对于第一批sprint来说，完全可以接受生成早期原型/alpha版本，这些原型/alpha版本预计不会没有bug，但仍然能够向客户演示一些东西。这甚至可能不是一个特性——它可以只是一个框架UI，只是让用户看看它的外观和工作方式

---

此外，开发人员自己也可以（而且通常是这样）编写单元测试，因此sprint中交付的任何东西都应该处于相当稳定的工作状态。如果一个新特性是半生不熟的，那么团队就不应该提供它。大功能应该被划分成足够小的块，以适应单个sprint。

您肯定不希望在sprint的前半部分进行所有开发，在后半部分进行所有测试。那只是一个较小的瀑布

您的故事和任务应该分解为非常小的、独立的功能部分。（这可能需要一段时间才能习惯，尤其是如果你正在开发的软件是一个单一的野兽，就像我以前的工作一样，后来改用了scrum。）在sprint的开始，测试人员正在开发他们的测试，开发人员正在开发他们的代码，在整个冲刺过程中，任务和故事都会被完成和测试。他们之间应该有相当持续的互动

冲刺结束时，你可能会感到有点忙碌，因为你正在习惯这种方法。开发人员在处理代码的其余部分时会感到负担沉重，同时测试人员会给他们一些bug来修复。测试人员会变得不耐烦，因为他们看到冲刺即将结束，还有一些代码尚未测试。这是一个学习曲线，需要一些时间来适应，企业需要意识到这一点

重要的是，开发人员和测试人员真正合作创建他们的评估，而不仅仅是将彼此的数字相加形成一个总数。开发人员需要意识到，直到最后一刻他们才计划编写新特性，因为这使得测试人员在周末匆忙地完成他们的工作，最终会依赖开发人员来解决问题，等等

---

在此过程中，有些任务需要重新定义。有些故事在冲刺结束时会失败。没关系，你会在下一个冲刺中得到它。每个sprint开始时的计划会议将定义这些故事/任务。记住要彼此耐心，并确保企业对流程中的变化有耐心。在一个理想的Scrum团队中，测试人员和开发人员是团队的一部分，测试应该在开发过程中并行进行，阶段是重叠的，而不是顺序的（在一个sprint中按顺序做事是一种被称为Scrumerfall的反模式）. 顺便说一句，与这里表达的一些观点相反，一个最终的Scrum实现产生了一些已经完成的故事，所以测试——包括IST、UAT——应该在Sprint期间完成

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

当然，这需要非常密切的协作，尽早发布界面或UI框架将促进测试人员的工作，但测试人员不必等待PBI完全实现。实际上，验收测试应该由开发人员使用