-2

我们有非结构化的 QA 和开发团队成员。我们正在制定以下战略来实施：

QA scrum 团队和 Dev scrum 团队一起工作。当一个模块或一个特性的开发完成时，一个或多个 dev scrum 团队成员加入 QA scrum 团队。他们在 QA 程序员维护的 QA 框架上工作，并准备好测试程序。一旦完成 QA 程序员所需的提升，他们就会回到 Dev scrum 团队进行下一个开发任务。通过这种方式，QA scrum 将更有效率，并将改善产品交付。

有人对我们的策略有更多建议吗？

4

2 回答 2

1

在我看来，所描述的方法不是很敏捷，也不像 Scrum。

在 Scrum 中，重点是团队和整个团队的承诺。不应该有 QA scrum 团队或 DEV scrum 团队。

可能有一个 QA 团队/组/公会和 DEV 团队/组/公会。对于一个项目、任务或产品，你可以组成一个由一些 DEV 和一些 QA 人员组成的 Scrum 团队，这个团队将是一个具有共同目标和共同承诺的 Scrum 团队。

最困扰我的是::

当一个模块或一个特性的开发完成时，一个或多个 dev scrum 团队成员加入 QA scrum 团队。

这是因为一个功能一旦真正完成（完成就完成了！）并且没有等待任务的 QA 就应该被认为是完整的。

我并不是说你的方法是“错误的”，因为没有对错之分。但是，我可以说它不符合 Scrum 的性质。

于 2017-06-16T21:28:32.987 回答
-1

首先，“Scrum”是一种思考和行动的框架或思维方式，它有自己的价值观和方法，可以在任何层面与敏捷组织的明确战略和目标相结合。敏捷的本质是以简单快速的方式为客户创造和最大化价值。因此，正如上面答案中正确提到的那样，没有人可以说您的方法是对还是错，因为它是一个模型，并且每个模型只能被判断为好或坏。从我的角度来看，你的方法中有些地方违背了 Scrum 和敏捷思维的精神。请注意以下事项：

  • 您始终跟踪 QA 活动，包括代码审查实践和测试。这些活动是团队一起学习、创造改进和努力优化的机会。它们不仅是某些团队成员亲自或部分完成的任务。所有活动都以团队为导向，旨在培养所有团队成员。因此，至少您必须修改您的方法以将团队的所有成员都包括在 QA 活动中。

  • 精确性、正确性和完整性是质量保证的三个主要因素。由于灵活性和 RAD 成为软件开发团队的重要价值，并且他们需要在旅途中开发、更改和适应，因此在冲刺中，将速度优先于上述三个质量因素是非常诱人的。因此，有时开发人员倾向于偷工减料以期赶上最后期限。关于您没有将 QA 作为一个完整的团队来关注，您的团队将很容易出现这个问题。偷工减料肯定会带来更多成本，因为它们可能会变成大的技术问题，会降低整体质量，而开发人员经常会错误地检测到真正的角落，最终会因为缺乏扎实的开发而错过最后期限。为了解决这个问题，您必须始终作为一个整体来跟踪 QA 活动。

要就问题进行沟通，您需要：

  • 根据报告的技术债务、错误和投诉，可视化已发布产品质量的增加/减少。这提高了团队的透明度，并强调了每个团队的每个成员对质量的责任。
  • 关注产品负责人定义的用户接受标准，否则您将与 PO 合作为产品待办列表中的每个项目提供它们。每个团队成员都需要清楚地了解这些标准，否则将没有机会达到预期的质量。
  • 在积压工作细化和计划会议中处理用户故事的质量，主要提高他们的质量和团队工作的结果。同样，每个团队成员都应该了解用户故事以成功实施它们。
  • 密切关注可能的偷工减料（如果有），以突出它们和相关的未来成本。每当在敏捷过程中实现该问题时，应通知每个团队成员。
  • 清楚地表明团队一起赢或输。因此，如果 Scrum 团队中的某个人偷工减料，他/她会增加整个团队失败的机会（社会压力）
  • 采取长期的方法，通过培训、指导和指导团队成员来创建一个更加自组织的团队。目前您可能会失去这个机会。
于 2019-01-02T15:25:37.313 回答