如何使Scrum为具有定义角色的团队工作？

Question

一些背景信息

我是内部软件开发团队的一员。它由

• 5名开发人员(有2至5年的经验，我是其中之一)
• 3名执行工作人员(他们负责软件部署和培训)
• 1名项目经理。

我们开发了大量的中小型项目，它们的时间表通常是重叠的。发展是这样的：

1. “客户”为我们提供了一组初始需求。
2. 我们开发的系统符合上述规格。
3. 向“客户”提交上述系统
4. “客户”根据上述陈述给我们额外的要求。
5. 重复2-4，直到“客户端”用完新的需求或部署目标日期接近为止。
6. 建立和部署系统

这一点，再加上大多数时间处理截止日期的是“客户端”(从我在程序员和PM.SE中看到的情况来看，这是一个危险的标志)，而且我们没有遵循明确的开发方法，导致牛仔编码、几乎不可维护的代码，以及通过生产而产生的bug等。这就是为什么我们选择采用一种基于敏捷的方法，比如Scrum。

为什么是Scrum?

这是我们经理的主动权，考虑到我们目前的情况，大家似乎都同意。

与Scrum

的问题

Scrum的一些元素与我们当前的设置存在冲突，我们很难解决这些问题，特别是敏捷开发人员的“千篇一律”的特性。部署团队不知道如何编程，开发人员的沟通和培训技能低于平均水平。而且这个阵容不会很快改变。

问题

它会影响Scrum作为一种方法的有效性吗？是否还需要作出其他修改来进行补偿？还是干脆放弃这个想法，考虑另一种方法呢？

Answer 1

实际上，您目前的工作方式与Scrum的距离并不像您想象的那么远。

在Scrum中，您还可以获得一组初始的需求，实现这些需求并演示结果，在演示的基础上，可以向您提供新的需求，或者涉众可以决定产品是否足够好，不需要进一步开发。

在您的情况下，您所讨论的“客户”可能会在Scrum中被赋予产品负责人的角色(他们似乎已经通过设置项目中的优先级并决定项目何时推出来填补这个角色)。

一个很大的变化可能是迭代的长度。在Scrum中，迭代应该持续1到4个星期。

至于团队的组成和无所不包的谬论: Scrum并不要求每个人都是万能的。Scrum只是要求团队作为一个整体拥有从需求列表到已经/可以部署的产品的所有所需能力。

在您的情况下，我可以很容易地看到每个项目由一个或多个开发人员(主要从事实现和测试工作)和一名“实现人员”组成的团队，他们主要致力于为开发人员正在实现的特性创建手册和培训材料。

在客户/产品负责人批准部署后，scrum团队的工作将大部分完成，因此开发人员可以转到另一个项目(并且只有在需要解决部署后的问题时才可用)，并且实现人员可以切换到执行培训和支持推出。

有最后期限这一事实并不是一个真正的问题，只要在该版本中需要有足够的灵活性。

Answer 2

您需要选择，所以我要说的是eXtreme编程(XP)。具体来说，我认为这对编程可能会对你有所帮助。

通过将具有不同技能的人配对在一起，并不重要的是什么技能:煮咖啡、测试、培训等等，你可以在团队中传播这些技能。

但老实说，这听起来不像是SCRUM，对你来说太远了。SCRUM的一部分是保持灵活性，并找到对您的团队最好的方法。XP的一部分是尊重您的团队并进行调整。也许100年后，我们可能会有一个更加成熟的职业，有着严格而快速的规则(尽管我对此表示怀疑)，但就目前而言，我们所拥有的就是为你工作的一切。重要的是要有反馈回路。如果有些东西不起作用，那么团队需要讨论这个问题，并尝试新的东西，直到他们找到一些有用的东西。

Answer 3

如何使Scrum为具有定义角色的团队工作？

就这么做。根据scrum指南的说法，每个人都是开发者，但在地球上，不同的人会带来不同的东西。当我建议有些人是真正的测试人员，而另一些人编写软件时，我会差点被私刑。

有些事情您可能需要解决：

Sprints

听起来你有一个初步的开发阶段，然后是一系列表面上的冲刺。考虑拆散这件事。客户端不仅会提前看到一些东西，而且在开发里程碑发生时会有更好的感觉。

固定的截止日期

这会一次又一次地出现，确实是我目前工作的devs方面的一个持续的荆棘。Scrum为sprint设定了估计值--仅此而已。是的，在一系列sprint之后，您可能会击中目标，但一旦客户端关注了早期版本，范围可能会明显爬行。这本身并不是一个问题，但是应该让客户意识到，在以后的sprint中将进行进一步的工作，并且超出了已知的需求。