我正在开发一个开发一些开源软件的个人项目。我想在这上面使用Scrum作为PM进程（因为我喜欢产品Backlog，优先级，如果我可以得到它们，那么我就不知道了）但在我看来，我不会得到全部价值，因为我不能从一开始就保证了我和我的合作者在特定冲刺期间能够承诺工作的时间。
我知道使用Scrum还有其他好处，但我是否有不同的变化或技巧和技巧，这将使我能够获得诸如燃尽图和时间盒迭代之类的价值？或者我只是太有希望了？
TIA。
Regs，Andrew
答案 0 :(得分：7)
由于这是一个爱好项目，你真的关心截止日期吗？事实上它会让你知道在Sprint之后会做多少钱？
如果您的答案是否定的，您可能希望将看板方法作为替代方案。
答案 1 :(得分：4)
我考虑软件开发的灵活性，并回到三个方面，提供真正的实用性：
在工作环境中，比如我的9到5，采用这种方法很容易。你有开发人员每周至少有40个小时，每周都有，所以参与敏捷练习的障碍很少，比如Scrum。
在“下班后”设置中，参与者的承诺水平通常会有所不同。这就是生活。所以你要用你所拥有的东西。如果Matt对这个项目感到兴奋，但他的日程安排很忙，他可以投入到项目中的时间会有所波动，那么呢？如果他“在船上”并认真考虑他愿意投资该项目的时间，那么这只是一种相应规划迭代的方式。
但是，我个人不会因此而缠绕在轴上。最后，Scrum或您采用的任何“敏捷”流程应该是达到目的的手段，而不是目的本身。特别是在条件与9-5世界不同的环境中，您需要在迭代计划中保持灵活性。你仍然计划你的工作和工作，你计划和参与定期沟通和“我们今天在哪里？”锻炼让每个人都在循环中。目标是可靠的软件 - 如果你不能从Scrum的某个特定方面或任何过程中获得很多实用工具，那么什么呢？无论如何，你可能会开发混合过程。我不会过于担心像燃尽图和速度这样的东西。老实说，我认为重点需要更多地放在正在开发的高质量软件上，而不是那些可能有助于下一次迭代或之后的工件的工件。这是我的意见。
我的建议是使用有效的东西并保持简单。积压很棒，每天与所有人联系的“会议” - 即使这是由IM完成的虚拟会议 - 也是找到真正价值的地方。业余爱好或边工作是艰难的事情，我希望你顺利。但请接受这样一个事实，即它可能不会像9到5那样有效。
答案 2 :(得分：1)
在书籍设置中，您不会使用实时计算燃尽图，而是使用故事点。在几次冲刺后，您将看到平均速度，从而能够生成燃尽图并使用此速度来提交冲刺项目。
我强烈不同意warrens post关于缩小规模的观点。我看到的主要问题是两个短跑之间的速度变化很大，因为它只是一个爱好。
答案 3 :(得分：1)
当团队在每次迭代时能够投入的时间变化太大时，速度无法真正帮助计划Sprint，因为它也会有所不同，特别是在开始时。但是，在几次Sprint之后，平均速度可能开始稳定。
然而，燃尽图仍然有用，因为它们显示当前迭代的准确状态。
您还将利用敏捷流程带来的估算“校准”。
答案 4 :(得分：1)
Scrum针对此类项目的问题更多的是Scrum旨在支持的开发团队结构类型，尤其是每日站立会议的团队托管。当你不在同一个物理位置时很难举行每日站立会议。此外，我怀疑您的团队中是否有产品负责人，您将成为Scrum Master和开发人员。除此之外，您和您的其他开发人员将在不同的时间工作，而且可能几天都没有完成任何工作。这可能使团队的协调变得困难。
每个项目，无论开发方法如何，都应该很清楚需要做什么（产品积压），需要尽快完成的工作（sprint积压）以及完成这些任务需要多长时间因此，您可以合理地估算项目需要多长时间（项目速度和燃尽）。 Scrum的其他部分可能会遇到问题 - 没有为会议而共处，没有产品负责人，使用告示板来显示冲刺状态等等。
这并不是说您无法修改Scrum流程以满足您的目的。例如：
因此，请尝试使用最有效的方法为您的会议服务。