我已经和团队进行了一段时间的争吵，但是由于某些原因，事情看起来很混乱。我一直在思考如何更改它们，并想在这里提出几个问题。

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

第二，我们有最后期限。这些都是严格的，对优先级有很大影响。最终结果是由于截止日期更改而导致的sprint中间积压更改，或者sprint结束时的不良结果。
同时，我们还有很多非技术性工作，例如客户支持，这些工作必须同时进行，并且由于其变化很大而无法计划。
因此，我认为团队的结构，文化和实践与Scrum不兼容。对我来说，Scrum是一个过程管理工具，用于开发单个软件产品的团队。

你们如何考虑将其应用到更具体，更复杂的场景中？我们有什么经验可以分享吗？

解决方案

回答

我们实际上不应该基于在Sprint中期提出的更改将更改添加到Sprint积压，它们应该只进入Product积压，而在Sprint完成之前将其忽略。

我们应该使最后期限与Sprint保持一致。我认为在Sprint中期退休一项任务是可以接受的，但不引入新任务。

如果我们发现要在Sprint中间添加很多任务，则Sprint可能太长了。请记住，我们打算将每个Sprint的工作时间再延长20天，这样我们就会开始遇到我们要描述的问题！

测试人员对任何敏捷过程都非常重要，但实际上不适合Scrum，因为理论上任何没有活跃任务的人都会选择下一个任务。试图选择任务和人员之间的关联会开始进入计划，这是整个过程都在努力避免的事情！

测试人员(如果在开发人员附近工作)可以帮助确定某项工作是否真正完成！

回答

First, what should be the role of testers, designers and non-developers as a whole in the scrum process? If they are equal to other team members a couple of issues arise. Designers and testers usually work on a task after development is done, so they cannot adequately plan for a sprint because of this dependency.

如果设计人员和测试人员由于对开发的依赖性而无法计划冲刺，那么这意味着开发没有正确的计划。这是一个必须解决的问题。

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

Second, we have deadlines. These are strict and have a lot of impact on prioritization. The end result is backlog changes in the middle of a sprint because of deadline changes, or bad results in the end of the sprint. We also have a lot of non-technical work like customer support that has to be done in the meantime and cannot be planned as it varies a lot.

如果发生这种情况，那么问题就在于我们没有在做Scrum。 Scrum工作的唯一方法是管理层完全将其纳入流程。这意味着开发人员在进行计划的sprint时将其闲置30天，并通过Scrum已有的方法添加新的工作。我们将愿望清单项目添加到产品积压中，然后在sprint计划期间，开发人员和利益相关者就下一次sprint的工作达成一致。

如果我们始终遇到中断正常开发的客户支持问题，则应认真考虑划分团队，并有一个小组专门负责Scrum的开发工作，而另一个小组则负责解决客户支持问题。然后，我们可以在每个冲刺结束时来回旋转人员。

回答

通常，测试人员和文档编制人员(以及其他非开发人员)都是Scrum团队的平等成员。其背后的想法是使风险最小化。

要求完成的定义包括经过全面测试和记录的潜在可运输产品，这会迫使项目在每次冲刺结束时合并在一起。

如果直到AFTER dev才开始测试。完成后，发生的事情是在开发人员完成一项任务后发现了许多错误。因此，现在我们必须修复这些错误，这是非常缓慢且昂贵的，因为错误会相互影响，并且因为一般规则是："修复错误的费用随时间呈指数增长。"早发现的错误很便宜且易于修复，晚发现的错误是一场噩梦。

这就是为什么我们希望测试(和文档)与开发同步进行的原因。现在，我们应该问，如何！测试很慢，它如何与开发人员步调一致？

答案是自动化，即SCRUM始终位于XP或者Agile之上，两者都要求出色的单元测试覆盖范围和TDD。这是另一个需要提防的陷阱。开发人员的功能应该是同时编写单元测试和系统测试的功能。所有测试自动化应由功能开发人员完成。团队。有些地方拆分了功能开发人员。来自自动化开发那很糟糕。

好，现在我们可以进行出色的自动化测试，并且每天至少运行一次。显然，我们练习持续集成对吗？这极大地减少了测试人员的工作量。这就是测试可以与开发人员保持同步的方式。还有一件事，测试人员现在正在处理不可能或者很难实现自动化的真正困难和创造性的工作，每次他们以这种方式发现错误时，暴露该错误所花费的一切都是自动化的，并成为每日回归测试的一部分。 ew，这是一个很长的答案！

现在到问题的第二部分。 Scrum与纪律有关。冲刺很短，冲刺期间的积压更改不应该发生。非技术工作应分支到客户支持团队，他们可以围绕该团队进行Scrum。当我们说这听起来像文化和做法与scrum不相容时，我们说对了。

以我的经验，过渡到Scrum / Agile是一个非常痛苦，压力很大的过程，大多数过渡尝试都失败了。成功的关键之一是执行团队中的Scrum / Agile冠军。根据描述，听起来好像我们没有人。

Scrum有成本和收益，但我们做得不好，可能会产生成本，而收益很少或者没有收益。如果我们做错了Scrum并且表现得很糟糕，那么最好根本不做Scrum。

回答

首先，我们根本没有使用Scrum，可能正在使用某些Scrum练习，但没有使用整个过程。

Designers and testers usually work on a task after development is done, so they cannot adequately plan for a sprint because of this dependency.

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

The end result is backlog changes in the middle of a sprint because of deadline changes, or bad results in the end of the sprint.

看来冲刺长度比我们需要的要宽。我们为什么不尝试将其缩短。良好的冲刺长度是我们可以承诺将更改保持在冲刺之外的长度。我想1周就可以了。

而且这种行为表明Scrum Master不能正确执行工作，因为他没有消除障碍。