问scrum能为传统的开源项目工作吗？

EN

开源项目非常多样化。有些情况下，类似Scrum的方法可以奏效，但在一般情况下则不然。

Scrum时间盒工作在固定大小的sprint中。有许多开源项目都有固定的发布计划。但通常情况下，这个计划是关于集成已经完成的工作，而不是开发。

Scrum期望团队致力于冲刺目标。但大多数开源项目都是由志愿者推动的。捐款是自愿和波动的。如果这些项目感到有资格得到志愿人员一再作出的可靠承诺，那将是有害的。这个项目不能告诉志愿者该做什么。当然，它可以拒绝接受不属于sprint待办事项的捐款，但这是对善意和开发资源的愚蠢浪费。作为一个开源的维护人员，使用错误修复的一次性请求是非常有价值的。但这一贡献绝不是可以规划的。

当然，在某些情况下，这不会成为一个问题。例如，一些发展可以通过赠款支付。这些赠款可以指定目标和/或时间框。但赠款通常只发放给一个人，而不是一个团队。有时项目由付费贡献者领导，例如由公司启动的项目。当然，公司可以使用Scrum来计划他们的贡献。

我假设，通过开放源码项目，您并不指由有报酬的员工进行工作的项目。“按部就班”Scrum通常行不通，因为有一些困难：

• 冲刺需要坚定的时间承诺，并从定期和反复的坚定时间承诺中获益良多。
• Scrum从频繁的团队互动中受益，如果团队的大多数成员都在同一个办公室或至少在一个类似的时区，这就更容易了。
• 根据我的经验，如果产品负责人不积极地为项目编写代码，那么他们--平均来说--会有更好的表现。
• 相当多的贡献者对他们想要开发的特定特性特别感兴趣，对其他一些特性很少或根本不感兴趣，也没有动机去听任何想要告诉他们要开发哪些特性的人的意见。
• 不同的时间承诺会给安排每日起立会议带来困难。

这些问题可以解决，只要有合适的项目和合适的人，Scrum无论如何都可以发挥作用。但即便如此，也可能有更好的过程。

我建议你分解Scrum，拿出你需要的东西，然后以适合项目和团队的方式实现：

• 有一个明确的项目远景，这是众所周知的和被大家接受的。
• 有一个共享的优先事项清单，这些事情应该比其他事情做得更快。
• 确保人们知道现在是谁在做什么。
• 有定期的短期至中期共同目标，并在达到目标后进行审查。

说Scrum不能工作，因为这些论点就像说Scrum不能在一家公司工作，因为他们目前正在使用瀑布。虽然Scrum和瀑布不能很好地相互配合(或者更确切地说是自相矛盾)，但这并不意味着如果每个人都支持Scrum，就不能在那里建立Scrum。同样，我也不会说Scrum本身不能在开源项目中工作，但是它有它自己的缺点。

人们倾向于不全职从事开源项目

虽然这是真的，Scrum也包含这种不确定性。考虑到我们有一个很短的周期一周，每个想要贡献的人都必须承诺至少一个星期，并计划他们能在这个项目上花费多少时间。根据每个撰稿人能负担多少时间，就有可能计划好故事来写下去。无论如何，如果贡献者倾向于远离强制性会议，那么做Scrum是不可能的。

当然，这并不局限于每周的冲刺周期。

虽然有些项目有一组核心贡献者，但许多拉请求都是临时的，提交拉请求的人很可能不会对任何商定的sprint目标做出贡献。

开源并不一定意味着每个人都能按自己的意愿做出贡献。有一些开放源码项目，对于如何贡献有非常严格的规则(例如Linux)。计划对项目做出贡献的人将被要求参加冲刺计划等。您可以将此作为对项目做出贡献的一个要求。当然，不喜欢这个的人可能会创建一个叉子，然后按照他们喜欢的方式工作，但是这将是另一个项目。

社区通常通过消息传递系统、博客和论坛来运行，而不是像计划会议、回顾和sprint评审这样的正式会议。

你可以通过电话或视频会议举行正式会议。虽然这并不能使Scrum变得更容易，但这是很有可能的。仅仅因为它没有在项目中完成，并不意味着它不能完成。

项目的方向通常更多的是民主(或谁贡献最多)，而不是由产品负责人集中精力。

是的，你必须有一个作为产品所有者的人。同样，通常的做法并不能阻止你以不同的方式去做。此外，还有一些例子表明，单身人士推动一个项目朝着一个方向前进(再一次，想想Linux)。

长话短说，虽然你可能是正确的，这不是什么规则，我不认为这是不可能的。如果您有一个称职的所有者选择并优先考虑愿意这样做的用户故事和贡献者，那么没有什么可以阻止您执行Scrum。

编辑

不管怎么说--正如评论员所指出的--这很可能是一场混乱，可能不是个好主意。只想提几点为什么它可能失败的原因：

• 很难得到一个核心的贡献者-没有它，Scrum就不会发挥它的优势
  • 如果没有一个非常稳定的团队，你就可以掷骰子来估计故事要点--这可能同样有效。

• 由于Scrum的开销，招募足够多的贡献者将更加困难。
• 承诺水平很可能不够高。

(附带说明:如果您想给您的开放源码软件项目提供一些结构，看板式的方法可能会更好。它不依赖于角色，收购量要低得多，而且时间更灵活，但仍然可以很好地概述WiP。)