Scrum如何适应志愿者设置？

我最近加入了一个年轻的hackerspace，但仍处于自我设置过程中。我们很幸运，因为该空间有一些需要开展的内部项目，并且不乏志愿者来开展工作。

关于如何组织这些项目已经进行了一些讨论。我最近的专业经验是在Scrum上工作的，因此我正在考虑为我们的软件项目推荐一种Scrum方法，但是我不确定这是否合适。

尽管我已经看到Scrum在小型全职团队中表现良好，但该组织的性质却有所不同：

• 成员是志愿者。有些是全日制学生。其他人全职工作。我们不能指望任何人会持续不断地贡献自己的生命，因为他们的现实生活被放在首位。
• 尽管几乎每个人都有多年编写软件的经验，但很少有成员以专业或团队的方式这样做。
• 目前没有任何商品所有者。这些项目的要求由委员会确定。该委员会的成员还将致力于实施。这意味着我们将没有一个专门的产品负责人。
• 我们没有最后期限（无论是硬性还是硬性）。项目完成后将完成。

这些是相当大的差异，但是我不相信它们会阻碍应用Scrum。我认为一些小的调整可以使我们克服这一障碍：

• 如果我们将Sprint更改为具有固定的故事点大小，但持续时间（时间）固定，我们仍然可以从迭代发布中受益，而不会给志愿开发人员带来不切实际的交付压力。
• 我们可以抛弃燃尽图和速度计算。如果我理解正确，那么这些工具和指标可以充当开发团队和管理层之间的桥梁。它们以对开发人员和利益相关者都有意义的形式报告进度。考虑到我们没有人要报告（没有项目经理，没有产品负责人，也没有外部利益相关者），我相信我们可以完全放弃。

我认为我们可以从中受益的事情不需要进行调整：

• 在需求收集会议（一个或多个）。每个人都围坐在一张桌子旁讨论用户故事，草拟UI模拟，并建立产品待办清单。
• 冲刺回顾。对于我们来说，这将是一种有趣的方式，使其可以汇聚成一个对我们作为志愿者团队有效的开发过程。

我不确定的事情：

• 每日站立训练应如何治疗？我想知道它们在我们的环境中是否会具有很大的价值。我对站立仪式的理解是，它可以通过在团队中自然传播信息来帮助交流。考虑到我们的Sprint所提供的复杂性可能比普通Sprint少得多，因此与其他团队成员的进度/发展并驾齐驱的需求可能会更少。
• 我应该为XP推动诸如持续集成，代码审查和TDD之类的事情吗？我担心这会要求很多。一旦人们更加熟悉Scrum并以团队的方式工作，我会更倾向于将这些概念引入未来的项目中。

我的问题：

Scrum是否可以适应基于志愿者的环境？
而且，到目前为止，我计划的方法是否朝着正确的方向发展？

看看看板。对于您的约束，它比SCRUM更合适。

编辑：SCRUM（非常粗略地）是有冲刺和仪式的有序积压工作，以确保“进行中”的工作量处于受控状态，并且在每次冲刺结束时都有可靠的东西。如果放弃了仪式和冲刺节奏，您将得到看板：有序的积压订单，并着重强调直接限制“进行中”的工作，并确保所有标记为“完成”的工作都已完成，而不是在工作结束时施加稳定性。每个冲刺。

您仍然会获得敏捷的好处：随时随地发布，具有灵活性，某种程度的可预测性-尽管SCRUM可以使您在这方面稍有提高-并且没有SCRUM的仪式或方面无法很好地适应松散的，分散的团队而没有承诺。抓住？放弃仪式需要更多的纪律，因此您确实需要注意测试，代码质量，当前进行中的工作，并确保充分准备了待办事项的顶部（准备由人拿起的东西）。

您可以进行基于投票的积压工作，尽管在志愿人员中，有些人只是从事他们想要的工作。

（是的，所有TDD，CI，评论和同行编程思想都是好主意）。

要解决差异，您首先要注意：

• 您的成员是志愿者并不意味着您不能要求他们做出承诺。特别是在Scrum中冲刺的持续时间相对较短的情况下，每个成员必须有可能知道他们在接下来的几周中可以花多少时间参与该项目。每个冲刺让团队成员有不同的时间可供使用会使规划变得更加困难，因为很难确定多少个故事点是现实的，但这不会使Scrum变得不可行。
• 产品负责人负责将利益相关者对产品的愿景（和要求）巩固并传达给开发团队。合并部分可能已经由“指导”委员会涵盖。在交流方面，他们可以只委派一名成员作为其主要发言人。那么，出于所有实际目的，那个人就是产品所有者。
• 对于Scrum来说，没有外部截止日期并不是真正的问题。它只是更多地归功于团队对产品的自豪感以使其完成。Scrum本身对每个冲刺都有一个自然的截止日期。

关于您建议的改编，尤其是在与志愿者合作时，我强烈建议您保持固定的冲刺长度。这样，志愿者就明确知道他们在哪个时期内做出承诺。

我也不会立即放弃燃尽图。它们对于团队本身查看自己的承诺表现也很有用。我将由团队决定保留还是放弃他们。速度计算也是如此。尤其是在每个冲刺可用工时变化很大的情况下，它们可以证明在估计未来冲刺时非常有用（特别是如果您计算每个工时完成的分数）。

关于日常站立，如果只是让每个人知道每个人都在做什么或有什么问题（这与复杂性无关），它们在您的设置中仍然有用。但是可能很难实现每日站立，因此您可能需要在那里妥协。

您提到的XP惯例可以独立于Scrum的使用而引入或不独立，也可以在回顾期间提出。

没人指出这一点让我感到惊讶，但是您的项目似乎像大多数开源项目一样。如果您查看一些更受欢迎的开源项目，则可能会找到一些启发。而且我认为您应该忘记SCRUM，并从一般敏捷性的角度考虑这一点。

敏捷是沟通与协作的全部内容。有理由在《敏捷宣言》中有4分之2谈论它。

个人与流程和工具之间的互动

客户合作而非合同谈判

而且按照您描述项目的方式，很难与项目中的每个人进行面对面的交流，这既敏捷又鼓励SCRUM。因此，我首先要关注的是建立整个团队（志愿者和产品委员会）的沟通渠道。诸如Wiki，论坛，视频会议以及适当的积压，任务和错误跟踪系统之类的东西是确保每个人都知道发生了什么以及需要做什么的好方法。

我要指出的第二件事是，不仅仅围绕敏捷的技术部分。许多人（包括我自己）相信他们是敏捷工作的人，而不是事物的过程方面。代码审查非常重要，并且大多数开源工作都是通过让了解项目的人员审查提交/推送来确保足够高的质量来进行的。对于任何敏捷项目，实际上都会给出TDD。它可以确保对代码的任何更改都不会破坏以前的功能，这在您的志愿者无法打扰解决其他人的错误和错误的情况下显得尤为重要。这也使代码检查更加容易，因为检查者可以在测试中看到添加了什么功能，并且通过运行它们，可以确保功能按预期运行。持续集成与TDD相同。

最后一件事是，我认为您应该至少有几个人专职从事该项目。这些人应该扮演特定的角色：

• 产品负责人：很高兴您有一个专门负责此工作的委员会，但应该有一个人负责将该委员会的词语解释为规范或用户故事，并确保它们得到正确实施。
• 协调员和Scrum主管：此人应对整个过程负责，并确保每个人都知道项目中正在发生的重要事情。此外，他还维护Wiki和任务与错误跟踪工具。如果有人对项目有疑问，这是他们应该问的第一人。
• 主要开发人员和架构师：最了解代码的人。他进行代码审查，并确保代码质量足以进行敏捷开发。

您无法按照描述的方式进行调整，而仍将其称为SCRUM。但我认为，您可以按照以下说明使用Scrum进行设置。

1. 有固定的迭代。这样您就可以衡量自己的进度。这不仅是为了管理层，也是为了团队“了解”他们的绩效。
2. 要求志愿者在迭代开始时分享能力。所有团队都需要成员承诺的内容，否则某些成员可能会离开团队去从事更专业的工作。
3. 没有截止日期就可以了。Scrum不会强制您在每次迭代结束时所做的操作都应该是可移植的。这样一来，您就可以根据自己之前所做的事情（正在运行）来决定下一步要做什么。
4. 没有产品所有者也可以工作。.您可以使用某种投票系统来堆叠排名积压和接受/拒绝完成的工作。
5. 需求收集不是Scrum的一部分。您可以按照自己的意愿进行操作。但不要将其作为迭代范围的一部分。有单独的能力。因此，对于迭代，仅计划明确要求的工作，例如团队知道接受标准。
6. 回顾性很好。因此，从头开始Scrum，然后使用回顾性的方法查看有效的方法和无效的方法，例如，您可能需要更改迭代大小，您可能需要摆脱一些拖累其他所有人的志愿者。
7. 每日状态是必须的。这为团队提供了彼此同步的机会，即他们将调整工作力度，从而不会因其他成员的交付物不可用而不必要地阻止任务。
8. XP是好的。对基于XP的完成有严格的定义，例如，除非经过审查，否则不得输入任何代码。少做多

我可能会建议另一种方法。由于您要与志愿者打交道，因此您需要考虑一些事项。您的团队的营业额可能很高，生活会受到阻碍，人们会分心。在剩下的一些人中，他们将持续做出贡献，但贡献不大，最后，您将拥有真正致力于该项目的核心团队。我在这里对您的工作人员做出许多假设，如果您认为我的评估没有反映出您所工作的人员，则可以忽略其余部分。

现在，您需要一种策略，该策略将使那些工作量不大的人能够独立自主地工作，他们只有太多的时间专门用于此工作，并且您不想让他们花费大部分时间在沟通中。参与度更高的人应该负责整合并清除一些更复杂的想法。

这使我想到了一个更围绕线框和原型的开发过程。

您可以拥有一个可用的工作项目池，并鼓励人们为这些项目编写线框。您可以将这些作为Tracer Bullets（从Pragmatic程序员借来的术语）使用，以磨练想法，并为人们提供灵感。从那里您可以将成功的想法分解成原型，这些都是很小的项目，旨在帮助人们更多地了解项目。之后，您现在会看到一小部分由许多人建立的可靠构想，您可以将其移交给一些更活跃的团队，他们可以将这些构想集成到您的系统中。

我认为看板将更适合这种情况。

Scrum有一些不合适的东西。时间或范围的测量是不必要的，并且所有人开发的会议都具有相同的产品愿景。问责制和遵循一致的短期计划是业务目标。

看板提供了许多与Scrum相同的优点，但没有缺点。它可以为您提供快速的原型制作。原型可以在会议之前运行。它还为可更改的代码和回归测试提供了TDD。结对编程可以通过转移知识来缓解新手和非常规用户进入代码库的麻烦。

看板还具有独特的优势。如果正在并行开发关于用户操作的愿景，则看板将运行良好。小型企业计划的成功就是证明。同样，对于像三个人这样的志愿者很少的日子，看板仍然可以正常工作。尽管是轻量级的，但Scrum仍然是太多的黄色胶带。