我正在启动一个个人项目来开发一些开源软件。我想使用 Scrum 作为 PM 流程（因为我喜欢 Product Backlog、优先级排序，如果我能得到它们，那就是燃尽图），但在我看来，我无法获得全部价值，因为我不能一开始就保证我和我的合作者在给定的冲刺期间能够投入工作的时间。
我知道我仍然可以从使用 Scrum 中获得其他好处，但是是否有我不知道的变体或技巧和技术可以让我获得诸如燃尽图和时间框迭代之类的东西的价值？还是我太有希望了？
TIA。
注册，安德鲁
【问题讨论】：
由于这是一个爱好项目，您真的关心截止日期吗？知道 Sprint 之后将完成多少工作实际上会给您多少价值？
如果您的答案是否定的，您可能希望将看板方法作为替代方案。
【讨论】：
我想到了软件开发中的敏捷性，然后回到提供真正实用性的三个方面：
在工作环境中，比如我的朝九晚五，采用这种方法很容易。您的开发人员每周至少要在那里工作 40 小时，因此参与敏捷实践（例如 Scrum）几乎没有障碍。
在“下班后”设置中，参与者的承诺水平通常会有所不同。这就是生活。所以你用你所拥有的东西工作。如果马特对这个项目很兴奋，但他的日程安排很忙，他可以投入到这个项目上的小时数会有一点波动，那又怎样？如果他“参与”并且认真对待他愿意为项目投资的时间，那么这只是一种相应地计划您的迭代的方式。
不过，我个人不会为此纠结。最后，Scrum 或您采用的任何“敏捷”过程应该是达到目的的手段，而不是目的本身。特别是在条件与朝九晚五的世界不同的环境中，您需要灵活地制定迭代计划。你仍然计划你的工作和你计划的工作并参与定期的沟通和“我们今天在哪里？”锻炼让每个人都参与其中。
目标是可靠的软件 - 如果您无法从 Scrum 的特定方面或任何流程中获得大量实用程序，那又如何？无论如何，您可能会开发一个混合流程。我不会太担心获得诸如燃尽图和速度之类的东西。老实说，我认为需要更多地关注正在开发的高质量软件，而不是可能在下一次迭代或之后的迭代中帮助的工件。不过这是我的看法。
我的建议是使用有效的东西并保持简单。积压工作很棒，每天与每个人接触的“会议”——即使这是由 IM 完成的虚拟会议——才是真正有价值的地方。爱好或副业是很难承诺的事情，我祝你一切顺利。但要接受这样一个事实，即它可能不像 9 到 5 的过程那样有效。
【讨论】：
在书本设置中，您不会使用实时来计算燃尽图，而是使用故事点。在几个 sprint 之后，您将看到一个平均速度，因此能够生成燃尽图并使用此速度来提交 sprint 项目。
我强烈反对warrens post 在缩小点上的观点。我看到的主要问题是两个 sprint 之间的速度变化很大，因为这只是一种爱好。
【讨论】：
当团队能够在每次迭代中投入的时间变化太大时，速度并不能真正帮助规划 Sprint，因为它也会变化，尤其是在开始时。但是，平均速度可能会在几个 Sprint 之后开始稳定。
尽管如此，燃尽图仍然很有用，因为它们显示了当前迭代的准确状态。
您还将利用估算“校准”敏捷流程带来的优势。
【讨论】：
对于这类项目，Scrum 的问题更多地在于 Scrum 旨在支持的开发团队结构类型，尤其是团队在日常站立会议中的托管。当您不在同一个物理位置时，很难举行每日站立会议。此外，我怀疑你的团队中是否会有产品负责人，你既是 Scrum Master 又是开发人员。最重要的是，您和您的其他开发人员将在不同的时间和日子里工作，可能根本没有任何工作完成。这可能会使团队的协调变得困难。
每个项目，无论采用何种开发方法，都应该清楚了解需要完成的工作（产品待办事项）、近期需要完成的工作（冲刺待办事项）以及完成这些任务需要多长时间所以你对项目需要多长时间有一个合理的估计（项目速度和燃尽）。您可能会遇到问题的是 Scrum 的其他部分 - 没有在同一地点参加会议、缺少产品负责人、使用公告板显示 sprint 状态等。
这并不是说您不能修改 Scrum 流程以适应您的目的。例如：
从本质上讲，Scrum 主要是关于有效的沟通，所以如果你做对了，你应该能够让它的修改版本为你工作。请记住，沟通效率会降低
因此，请尽量使用最有效的方法来召开会议。
【讨论】：