Scrum 流程管理 - 技巧、陷阱、想法 [关闭]

Question

我和一个团队一起做 Scrum 一段时间了，但由于某些原因事情看起来很混乱。我一直在思考如何改变它们，并有几个问题想在这里提出。

首先，测试人员、设计人员和非开发人员作为一个整体在 Scrum 流程中应该扮演什么角色？如果他们与其他团队成员平等，就会出现一些问题。设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分规划冲刺。

其次，我们有最后期限。这些都很严格，并且对优先级有很大影响。最终结果是由于截止日期的变化而在冲刺中期发生积压变化，或者在冲刺结束时出现糟糕的结果。我们还有很多非技术工作，例如客户支持，必须同时完成，并且无法计划，因为它变化很大。所以我认为团队结构、文化和实践与 Scrum 不太兼容。Scrum 对我来说是一个流程管理工具，适用于开发单个软件产品的团队。

你们对于将其应用到更具体、更复杂的场景有什么看法？您有什么经验可以分享吗？

Answer 1

一般来说，测试人员和文档人员（以及其他非开发人员）都是 Scrum 团队的平等成员。其背后的想法是最大限度地降低风险。

需要对完成进行定义，其中包括经过充分测试和记录的潜在可交付产品，迫使项目在每个冲刺结束时聚集在一起。

如果测试在开发之后才开始。完成后，开发人员完成任务后会发现很多错误。所以现在你必须修复这些错误，这是非常缓慢且昂贵的，因为错误会相互作用，而且一般规则是：“修复错误的费用随着时间的推移而成倍增长。”您提早发现的虫子便宜且易于修复，较晚的虫子是一场噩梦。

这就是为什么您希望测试（和文档）与开发同步进行。现在你应该问，如何！测试速度很慢，到底如何才能与开发同步进行呢？

答案是自动化，即 SCRUM 始终位于 XP 或 Agile 之上，两者都需要出色的单元测试覆盖率和 TDD。这是另一个需要注意的问题。功能开发人员应该是编写单元测试和系统测试的人。所有测试自动化应该由功能开发人员完成。团队。有些地方分割功能开发。来自自动化开发人员。这很糟糕。

好的，现在您已经有了很好的自动化测试，并且每天至少运行一次。显然你实践了持续集成，对吗？这大大减少了测试人员的工作量。这就是测试如何与开发保持同步的方式。另一件事是，测试人员现在致力于真正困难和创造性的工作，这些工作是不可能或非常难以自动化的，每次他们以这种方式发现错误时，暴露错误所需要的工作都是自动化的，并成为日常回归测试的一部分。唷，这是一个很长的答案！

现在回答你问题的第二部分。Scrum 是关于纪律的。冲刺时间很短，冲刺期间不应发生积压变更。非技术工作应该划分给客户支持团队，他们可以围绕这一点进行 Scrum。你说得对，听起来你的文化和实践与 Scrum 不相容。

根据我的经验，过渡到 Scrum/Agile 是一个非常痛苦、压力很大的过程，大多数过渡尝试都会失败。成功的关键之一是执行团队中 Scrum/Agile 的拥护者。从你的描述来看，你好像没有。

Scrum 有成本也有好处，但如果你做得不好，你可能会产生成本而几乎没有好处或根本没有好处。如果您使用 Scrum 的方式是错误且糟糕的，那么您最好根本不使用 Scrum。

Answer 2

首先，测试人员、设计人员和非开发人员作为一个整体在 Scrum 过程中应该扮演什么角色？如果他们与其他团队成员平等，就会出现一些问题。设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分规划冲刺。

如果设计人员和测试人员由于开发依赖性而无法计划冲刺，则意味着您的开发计划不正确。这是一个需要解决的问题。

您的团队应该能够说“任务 B 需要首先完成任务 A。任务 A 需要 8 小时，任务 B 需要 4 小时”。如果您的任务估计是准确的，那么依赖关系根本就不是问题。

其次，我们有最后期限。这些都很严格，并且对优先级有很大影响。最终结果是由于截止日期的变化而在冲刺中期发生积压变化，或者在冲刺结束时出现糟糕的结果。我们还有很多非技术工作，例如客户支持，必须同时完成，并且无法计划，因为它变化很大。

如果发生这种情况，那么问题就在于你没有采用 Scrum。Scrum 发挥作用的唯一方法是管理层完全接受该流程。这意味着让您的开发人员在 30 天内进行计划的冲刺工作，并通过 Scrum 现有的方法添加新工作。您将愿望清单项添加到产品待办事项列表中，然后在冲刺计划期间，开发人员和利益相关者就下一个冲刺中将要开展的工作达成一致。

如果您始终遇到客户支持问题干扰正常开发，那么您应该认真考虑划分团队，并让一个小组专门从事 Scrum 开发，并让另一组负责客户支持问题。然后，您可以在每个冲刺结束时来回轮换人员。

Answer 3

您确实不应该根据 Sprint 中期提出的更改将更改添加到 Sprint 待办事项列表中，它们应该只进入产品待办事项列表并忽略，直到 Sprint 结束。

您应该将截止日期与 Sprint 保持一致。我认为在 Sprint 中期放弃一项任务但不引入新任务是可以接受的。

如果您发现在 Sprint 中期添加了大量任务，则您的 Sprint 可能太长。请记住，您的目标是在每个 Sprint 中完成大约 20 天的工作，如果时间更长，您就会开始遇到您所描述的问题！

测试人员对于任何敏捷过程都很重要，但并不真正适合 Scrum，因为 Scrum 的理论是任何没有活动任务的人都会选择下一个任务。尝试选择任务和人员之间的关联开始进入日程安排，而整个事情都在试图避免！

测试人员如果与开发人员密切合作，可以帮助确定一项工作是否真正完成！

Answer 4

首先，你根本没有使用Scrum，你可能正在使用一些Scrum实践，但不是整个过程。

设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分规划冲刺。

任务依赖性（很少发生）与正确计划的能力没有关系。在冲刺计划中，团队应该评估有关“完成的定义”的故事。如果它包括并且确实应该设计和测试故事，则完成故事验收标准所需工作的估计必须包括设计和测试任务。

最终结果是由于截止日期的变化而在冲刺中期发生积压变化，或者在冲刺结束时出现糟糕的结果。

看来你的冲刺长度比你需要的要宽。你为什么不尝试让它变得更短呢？良好的冲刺长度是您可以承诺将更改排除在冲刺之外的长度。我想1周就可以了。

这种行为表明你的 Scrum Master 没有正确完成他的工作，因为他没有消除障碍。