6

我们第一次尝试使用 TFS 2012 在我们的公司上实施 scrum。到目前为止，这个过程做得不是很好，因为我们有一些问题，到目前为止还没有人能找到答案。

我们主要关心的是如何处理测试阶段。以下是或场景（就人员/工作而言）：

  • 我们有6个程序员
  • 我们有一个 scrum master
  • 我们有 2 名测试人员（不是程序员）

这就是我们迄今为止所拥有的：

  • 所有的愿望都进入董事会
  • 我们召开了冲刺会议，在会议上我们将任务添加到这些愿望中
  • 我们准备冲刺
  • 人们开始做他们的工作

我们对完成的定义阐明了只有当故事交给测试人员并且其中一个人（在这种情况下，是我）说故事已经完成时，才能认为故事已经完成。到现在为止还挺好。

我们有一个测试服务器，所有测试都在其中执行，该服务器类似于生产服务器（Web 应用程序）。

正如我所说，主要关心的是如何处理测试：

  • 由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该何时提交？任务何时完成或积压项目何时完成？
  • 什么时候应该发布测试版本？
  • 测试应该什么时候开始？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？当我们应该开始测试时，我们如何获得通知？
  • 我们应该在每个积压项目上创建一个部署任务和一个测试任务吗？

你能帮忙的话，我会很高兴。

4

3 回答 3

8

- 由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该何时提交？任务何时完成或积压项目何时完成？

Ans：我认为您应该在代码准备好后立即提交。如果您在用户故事下创建了任务并且任务涵盖了一些小型开发，您可以提交并关闭该任务。因此，同样明智的是，您有更小的任务来开发用户故事。完成所有任务后，用户故事（积压项目）就完成了。

要测试这些提交，您可以做的是拥有一个针对 CI 环境运行的自动化测试套件。所以你可以涵盖冒烟测试和回归测试。可以根据时间确定运行哪种类型的测试套件。例如，您可以每周运行回归测试套件，每晚运行烟雾测试套件。

- 什么时候应该发布测试版本？- 什么时候开始测试？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？当我们应该开始测试时，我们如何获得通知？

答：不应该有严格的截止日期，例如发布测试版本。测试可以在用户故事发展的同时开始。测试人员如何提供帮助是测试人员可以对开发人员使用的代码进行“展示会话”并提供一些反馈。并在解决用户故事后开始功能测试（您可以在 tfs 中拥有此状态）。但请确保在 sprint 结束之前完成测试。

如果测试债务很高，您可以进行强化冲刺。

- 我们应该在每个积压项目上创建一个部署任务和一个测试任务吗？

答：是的，每个用户故事应该有两个不同的任务。一项任务涵盖功能测试（用户故事测试）。这对于估算和获得正确的团队速度很重要。

于 2012-11-22T06:14:22.993 回答
2

在 Scrum 中处理测试的方式并没有特定于 TFS。事实上，Scrum处理测试并没有什么特别之处！你的团队已经同意一个故事（或待办事项）是Done，只有在它经过测试之后，Scrum“关心”的唯一事情就是你满足你的 Done 定义。

关于您的具体问题：

  • 您应该尽早并经常提交您的更改。您提交的越多，您就越容易将更改传达给团队的其他成员，并且在发生灾难时（您搞砸了代码，或者您的硬盘驱动器出现故障） - 您就越容易恢复。根据我的经验，最好在您的代码足够稳定且足够安全以添加到存储库时提交。至少在您完成一项任务时应该这样做
  • 您应该尽早并经常发布（在这里看到一个反复出现的主题？）。这意味着只要您的产品有一个有价值的增量，并且它足够稳定和安全，就可以暴露给您团队之外的利益相关者。在您的第一个版本之后，您应该能够在完成积压项目时执行此操作- 每个最小可行产品增量。
  • 你应该尽早并经常测试——你猜到了。这意味着，只要对您的产品所做的更改足以进行测试。对于开发人员单元测试，这意味着几乎每次添加场景（如果您正在进行测试驱动开发）。对于“QA”测试，应该尽早完成——只要任务完成，如果你能管理它。事实上，如果有必要，您可能希望重新考虑如何将积压项目分解为任务，以提高任务的可测试性。例如，如果您按组件或代码层分解任务，则不可能在整个故事代码完成之前测试代码。另一方面，如果您按用例打破积压项目或场景，您将能够在完成任务时进行测试 - 开发人员将更快地获得他们的反馈 - 在他们完成任务后立即！
  • 如果您需要部署每个积压项目（并且您确实这样做了），则应考虑所涉及的工作。如果每个部署都略有不同（一个故事可能需要发布到网络上，另一个故事可能意味着将应用程序上传到移动应用商店），以一种不平凡和不明显的方式，那么你应该有一个任务它，解释如何部署。但是，如果每个部署任务的标题看起来像“部署”并且估计值相同，那么您应该考虑不要浪费您的时间，只需在待办事项的工作流程中添加一个状态（例如：待办事项 --> 在进度 --> 测试 -->部署--> 完成）
于 2012-11-21T08:01:34.830 回答
1

总的来说，Scrum 不会给你遵循的过程。它只提供了一个框架，您可以在其中凭经验试验您的流程，以找到最适合您的团队的方法。

由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该何时提交？任务何时完成或积压项目何时完成？你能在不提交的情况下实现一个集成的、完成的增量吗？如果没有，请在有意义的时候提交。选择一个并谈论它的影响。当您批量处理所有更改直到积压项目“完成”时会发生什么？可以在不提交的情况下完成积压项目吗？

什么时候应该发布测试版本？当产品负责人认为他们有足够的价值可以运送或有运送价值时。您在冲刺中创建的增量应该是可发布的。

也许你在问你能否在冲刺中发运。当然！将其视为在 Scrum 框架内执行的另一个经验实验。您可以尝试此实验并根据经验检查结果。

测试应该什么时候开始？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？再次，选择一个并使用 Scrum 来检查影响。作为建议，不要等待太久。尝试让自己处于并行构建测试/测试用例的位置。在这些技能之间进行协作。

当我们应该开始测试时，我们如何获得通知？您有 6 名开发团队成员。问对方。电子邮件，Skype，转过头，站起来走过去。也许您可以使用 Daily Scrum 作为计划一天的地方

我们应该在每个积压项目上创建一个部署任务和一个测试任务吗？同样，有些团队这样做。如果这对您有帮助 a) 了解剩余的工作 b) 执行您的流程，然后尝试一下。也许“可通过 xyz 脚本部署”是正在制定的完成项目的新定义。

于 2012-11-21T05:26:35.993 回答