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

一些背景资料

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

• 5位开发人员（经验从2到5年不等，我是其中之一）
• 3名实施人员（他们进行软件部署和培训）
• 和一名项目经理。

我们开发了大量的中小型项目，它们的时间表通常重叠。开发过程如下：

1. “客户”给我们提出了一系列初步要求
2. 我们按照上述规范开发系统
3. 向“客户”展示所述系统
4. “客户”根据上述介绍向我们提出了其他要求
5. 重复2-4，直到“客户”用完新要求或部署目标日期临近
6. 设置和部署系统

这与事实是，大多数情况下都是由“客户”来处理最后期限（这是一个危险信号，根据我在Programmers和PM.SE中的了解），我们没有遵循明确的开发方法牛仔编码，几乎不可维护的代码以及通过生产而产生的错误等。这就是为什么我们选择采用像Scrum这样基于敏捷的方法。

为什么是Scrum？

这是我们经理的倡议，鉴于我们目前的情况，每个人似乎都对此表示同意。

Scrum的问题

Scrum的某些元素与我们目前无法轻松解决的设置存在冲突，特别是敏捷开发人员的“万事通”性质。部署团队不知道如何编程，开发人员的沟通和培训技能低于平均水平。而且这个阵容不会很快改变。

问题

它会影响Scrum作为一种方法的有效性吗？是否需要进行其他更改以补偿？还是完全放弃这种想法而考虑另一种方法会更好吗？

实际上，您当前的工作方式与您可能想到的Scrum距离并不远。

在Scrum中，您还将获得一组初始需求，实施这些需求并演示结果，并在演示的基础上，可以向您提供新的需求，或者利益相关者可以确定产品足够好而无需进一步开发。
在您的情况下，可以将您所讨论的“客户”赋予Scrum中的“产品负责人”角色（他们似乎已经通过设置项目中的优先级并确定何时准备推出该产品来填补该角色）。
一个大的变化可能是迭代的长度。在Scrum中，迭代应该持续1到4周。

而对于球队的组成和自升式的，全行业的谬论：Scrum的并没有要求每个人都成为一个千斤顶的，全行业。Scrum仅要求团队整体具有所有必需的能力，才能使产品从需求列表到已经/可以部署的产品。
在您的情况下，我很容易看到每个项目都有一个团队，这个团队由一个或多个开发人员（主要负责实施和测试工作）和“实施人员”的成员组成，他们主要致力于为这些功能创建手册和培训材料。开发人员正在实施。

在客户/产品所有者批准部署之后，scrum团队的工作将大部分完成，因此开发人员可以转到另一个项目（并且仅在需要时才能解决部署后的问题）并进行实施。工作人员可以切换到进行培训和支持推广。

只要在该版本中需要什么功能方面具有足够的灵活性，存在截止期限的事实就不是真正的问题。

您要求替代方案，所以我要说的是极限编程（XP）。具体来说，我认为结对编程可能会在这里为您提供帮助。

通过将具有不同技能的人配对在一起，什么技能都没关系：煮咖啡，测试，培训等。您可以在团队中传播这些技能。

但是说实话，听起来像SCRUM并不是那么遥不可及。SCRUM的一部分是保持灵活性，并找到最适合您的团队的东西。XP的一部分是尊重您的团队并进行调整。也许在100年的时间里，我们可能会拥有更加完善的专业，并制定了严格的规则（尽管我对此表示怀疑），但就目前而言，我们所要做的只是为您做的事情。重要的是要有反馈回路。如果某件事不起作用，则团队需要讨论该问题并尝试新事物，直到发现有用的事物为止。

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

去做就对了。根据Scrum指南，每个人都是开发人员，但是回到地球上，不同的人会带来不同的事物。当我建议有些人确实是测试人员，而其他人编写软件时，我几乎被私刑了。

您可能要解决的一些问题：

冲刺

听起来您已经处于最初的开发阶段，然后是一系列表面看来是短跑的项目。考虑分手。客户不仅会及早看到一些东西，而且随着发展里程碑的出现，您会感觉更好。

固定期限

这一次又一次地出现，确实对我目前工作的开发人员来说是一个持久的难题。Scrum为冲刺设置估算值-仅此而已。是的，经过一系列的冲刺，您可能会达到目标，但是一旦客户关注早期版本，范围可能会显着扩大。这本身不是问题，但是应该使客户知道，进一步的工作将在以后的sprint中进行，并且超出了已知的要求。

您的情况可能更适合看板，因为您可以从那里开始并从那里进行迭代。这意味着您不会有一个大爆炸的介绍，而这不会破坏您当前的项目-只需从可视化董事会上的任务并采用某些做法（例如回顾和日常会议）开始。

您必须比使用Scrum更加谨慎，因为它不是那么规范性的：因此它倾向于回到以前的版本，而不是灌输适当的敏捷心态。

Scrum在重叠的单独项目上不能很好地工作，因为您没有稳定的团队来为整个sprint工作。因此，详细程度等概念可能只会使您沮丧。

但是，在处理下一个故事之前，首先考虑为客户提供最佳成本/收益的故事，并实施包括全自动测试在内的质量，使其足以被部署，这是一个有用的概念。同样，在故事被视为“完成”之前，要求故事编写的所有代码都必须由其他开发人员进行审查。

我假设您的实施人员必须编写培训和参考文件，可以在编写代码之前为每个故事编写它们（初稿），从而成为验收测试。

我希望您会发现，在每个项目开始时，实施人员的投入将对开发人员最有帮助，他们100％致力于上一个项目的部署。因此，请考虑在开发人员为当前项目编写代码的同时，实现人员是否可以为下一个项目编写故事和用户文档。

由实施人员编写测试中使用的示例的“行为驱动的开发”可能会起作用。

因此，有一些Scrum可以为您提供帮助，但是请尝试从Scrum中学习而不是使用Scrum。