了解Scrum

Question

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

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

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

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

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

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

Answer 1

你肯定不想在sprint的前半部分做所有的开发，在后半部分做所有的测试。那只是一个较小的瀑布。

你的故事和任务应该被分解成非常小的、离散的功能。(可能需要一段时间才能习惯这样做，特别是如果您正在处理的软件是一个整体的野兽，就像我以前的工作一样，它使用了scrum。)在冲刺的开始，测试人员正在开发他们的测试，开发人员正在开发他们的代码，在整个冲刺过程中，任务和故事都是完成和测试的。它们之间应该有相当持续的互动。

当你正在习惯这种方法的时候，冲刺的结束可能会让你感觉有点忙碌。开发人员在处理代码的其余部分时会感到负担过重，同时测试人员也会给他们一些需要修复的bug。测试人员会变得不耐烦，因为他们看到冲刺的尾声迫在眉睫，仍然有代码没有经过测试。有一个学习曲线，需要一些时间来适应，业务需要意识到这一点。

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

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

Answer 2

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

Answer 3

具有讽刺意味的是，你在这个过程中应用了太多的严谨。像scrum这样的敏捷过程的全部要点是时间表是动态的。在您的第一次冲刺之后，您将与用户/测试团队一起评估进度。在这一点上，他们要么会要求您更改在第一个sprint中交付的细节和功能，要么会要求您做更多的工作。这取决于他们。

只有最终，一旦你确定了团队的速度(即。一个人可以在一个冲刺中合理地完成多少个故事)，你可以开始为更大的项目估计日期和事情