agile - 敏捷开发能否弥补项目中期失去三名测试人员的损失？

Question

由于预算限制，在一个采用敏捷开发实践的项目中间，我们不得不解雇 3 个软件测试承包商。管理态度是投入同等数量的全职机构来弥补这一点。敏捷开发是否允许这种中断？我想知道有没有人遇到过类似的情况，是怎么处理的？

Answer 1

我在一个项目中，有 9 个开发人员进展顺利。由于种种原因，我们不得不在两个月内裁掉 5 个人并增加 3 个新人。我们遵循大多数 XP 实践（不能说我们是 100% XP，但我们很接近）。我们的速度下降了一段时间，但没有归零。

• 缺乏代码所有权意味着离开的人没有没有相对较好地共享的特殊知识。
• 单元测试很好地以可执行的方式记录代码，以便新人可以看到正在发生的事情并以更安全的方式进行更改。
• 结对编程帮助我们让人们快速上手。
• 短暂的迭代让我们能够证明，虽然速度下降，但它确实开始迅速回升，并让业务用户相信我们仍在创造价值。
• 迭代计划会议帮助新人了解需求并专注于迭代目标，而不是仅仅跑遍代码库。

这不是一个理想的情况。敏捷帮助它变得更好，但它仍然受到伤害。仍然需要所有相关人员的大量努力。如果不是他们都是真正优秀的开发人员和团队成员，它就不会奏效。我只能推测，但团队足够好，即使没有敏捷，我们可能也会成功，但我认为因为敏捷，它变得更加顺利。如果它是一群笨蛋，什么都不会起作用。

Answer 2

好吧，任何方法都必须考虑到团队损失的中断或根本不现实。无论是下岗、辞职还是干脆死去，人们都会离开。新人不会有过往记录，这会影响团队的速度，至少在开始时是这样。分析你的项目——继续做过去证明自己成功的事情。假设（这就是我所做的）他们将在第一个月的工作效率提高 1/2，并根据他们正在从事的项目的复杂性将它们向上滑动。

Answer 3

你做什么类型的敏捷？

如果我们笼统地说，我会说他们没有任何问题。您只需要更改您的团队任务即可继续进行测试。不要停止测试！您只需要花时间进行最初计划开发的测试。

Answer 4

我们使用 Scrum 方法，这当然允许这样做。事实上，它正是围绕这种情况而构建的。因为业务决定了您想要处理积压工作的哪些部分，取决于您可用于该 sprint 的资源量，您可以逐个 sprint 更改可用资源，这仍然是可行的，尽管可能不可行建议