Scrum可以用于测试项目吗？

Question

任何人都可以评论Scrum是否适用于测试项目？这意味着如果我的公司获得测试项目，我可以在其中实施Scrum吗？

Answer 1

测试项目意味着你现有的系统或应用程序，你的任务是找到它的故障和缺陷？ 我没有看到scrum无法使用。你可能需要一个好的scrum master。最后，选择最适合你的团队的东西。

Answer 2

我从来没有做过它，但它似乎是Scrum的将工作做好。每次迭代，您都应该确定需要测试的事情并将其添加到您的待办事项中。客户可以优先考虑重要部分，并且每次迭代都可以测试其中的许多部分。

Answer 3

您必须改编Scrum才能使其工作。也就是说，您所做的活动：计划，日常站立，评论，回顾，都可以用于几乎任何类型的项目，但您会发现很多关于Scrum的描述真的不适用。例如，您不会将新功能本身归入迭代中。你几乎有一套功能可以测试给你。但是，您可能正在做的是确定如何测试这些功能并确定哪些类型的测试需要编写/开发以及何时应用它们。

我的感觉，这适用于所有灵活的环境不只是测试，是你最终想要得到你需要的一组适用于您的情况和团队的做法点。从Scrum（或XP或DSDM或FDD）开始，并将其应用到您的组织是一项有价值的工作，尤其是如果您不熟悉敏捷方法，但不要陷入僵化的框架 - 敏捷或其他方面。制作框架，工作。

Scrum的（和其他敏捷方法）识别此和在反射的概念正式化。然而，很多时候，这是没有被采纳的一个部分，并且最终的结果是重量更轻，但是决定性的非敏捷过程。也就是说，你可以敏捷地开发软件，但你无法灵活地调整你的过程。对我而言，后者是真正的胜利之处，否则它会转变成开发软件的不同（尽管更好）流水线，而不是以前的计划驱动方法。

Answer 4

我的公司（一家全球性的互联网公司）使用它起到很大的作用。我们为需要测试的功能块创建故事，然后创建子任务以进一步细分工作量并使估算更容易。我们使用greenhopper（一个jira插件）来管理它。到目前为止，它运行良好。

Answer 5

我认为这可能工作得很好，如果你不看软件你提供的东西做的。

你的客户现在开发团队制作的代码，或谁反应你发现的bug。就像Scrum中的客户经常改变主意一样，开发人员也会改变代码，或者他们与你进行交互的方式。

你的交货是由缺陷和质量报告，让你的“橱窗”的设计应该让你的交付质量，从他们的反馈。你可以问问他们你的报告是否足够清楚，如果你的信息太多或太少，或者他们想与你互动的方式有所不同。也许他们希望能够为你的团队Skype，或者你有访问他们？也许他们想优先考虑他们想要测试的代码的哪些部分？他们的需求是否足够清楚 - 你是否理解他们的代码应该实现的是什么，或者你只是在不查看可用性的情况下寻找错误？

在您的团队范围内，您可以根据自己的需要来处理工作 - 举行回顾会议，研究痛苦的来源，并且可能会推出新工具来帮助克服这种痛苦。自动化回归测试看起来好像它们可能是测试团队的有用工具。毫无疑问，其他人。

理想的情况下，在Scrum中，团队是由每个人都需要参与到交付软件谁的，他们是同一地点。你不会得到像“测试项目”这样的东西。这种切换可能会很昂贵。如果你可以用Scrum来取得与该给你的代码摆在首位，以测试团队更好的沟通，我认为这可能是一个很大的区别。

祝你好运！