4

我正在启动一个个人项目来开发一些开源软件。我想使用 Scrum 作为 PM 流程（因为我喜欢 Product Backlog、优先级排序，如果我能得到它们，那就是燃尽图），但在我看来，我无法获得全部价值，因为我不能一开始要保证我和我的合作者在给定的冲刺期间能够投入工作的时间。

我知道我仍然可以从使用 Scrum 中获得其他好处，但是是否有我不知道的变化或技巧和技术可以让我获得诸如燃尽图和时间盒迭代之类的东西的价值？还是我太有希望了？

TIA。

注册，安德鲁

4

5 回答 5

7

由于这是一个爱好项目，你真的关心截止日期吗？知道 Sprint 之后将完成多少工作，它实际上会给您多少价值？

如果您的答案是否定的，您可能希望将看板方法作为替代方案。

于 2008-11-21T23:47:57.053 回答
4

我考虑了软件开发中的敏捷性，然后回到提供真正实用性的三个方面：

  • 已知的待办任务积压
  • 定期有机会公开讨论正在处理的任务的现状和需要克服的障碍
  • 团队管理的迭代，导致最终完整产品的工作子集

在工作环境中，比如我的朝九晚五，采用这种方法很容易。您的开发人员每周至少要在那里工作 40 小时，因此参与敏捷实践（例如 Scrum）几乎没有障碍。

在“下班后”设置中，参与者的承诺水平通常会有所不同。这就是生活。所以你用你所拥有的东西工作。如果马特对这个项目很兴奋，但他的日程安排很忙，而且他可以投入到这个项目上的小时数会有一点波动，那又如何呢？如果他“参与”并且认真对待他愿意在项目上投入的时间，那么这只是一种相应地计划迭代的方式。

不过，我个人不会对此感到困惑。最后，Scrum 或您采用的任何“敏捷”过程应该是达到目的的手段，而不是目的本身。特别是在条件与朝九晚五的世界不同的环境中，您需要灵活地制定迭代计划。你仍然计划你的工作和你计划的工作并参与定期的沟通和“我们今天在哪里？” 锻炼让每个人都参与其中。

目标是可靠的软件——如果你不能从 Scrum 的特定方面或任何过程中获得大量实用程序，那又如何？无论如何，您可能会开发一个混合流程。我不会太担心获得诸如燃尽图和速度之类的东西。老实说，我认为需要更多地关注正在开发的高质量软件，而不是可能在下一次迭代或之后的迭代中帮助的工件。这是我的意见。

我的建议是使用有效的东西并保持简单。积压工作很棒，每天与每个人接触的“会议”——即使这是由 IM 完成的虚拟会议——才是真正有价值的地方。爱好或副业是很难承诺的事情，我祝你一切顺利。但要接受这样一个事实，即它可能不像朝九晚五的过程那样有效。

于 2008-11-22T13:46:46.267 回答
1

在书本设置中，您不会使用实时来计算燃尽图，而是使用故事点。在几个 sprint 之后，您将看到平均速度，因此能够生成燃尽图并使用此速度来提交 sprint 项目。

我强烈不同意沃伦斯在缩小点上的帖子。我看到的主要问题是两个 sprint 之间的速度变化很大，因为这只是一种爱好。

于 2008-11-21T12:52:16.703 回答
1

当团队在每次迭代中投入的时间变化太大时，速度就无法真正帮助计划 Sprint，因为它也会变化，尤其是在开始时。但是，平均速度可能会在几个 Sprint 之后开始稳定。

尽管如此，燃尽图仍然很有用，因为它们显示了当前迭代的准确状态。

您还将利用敏捷过程带来的估计“校准” 。

于 2008-11-22T13:05:01.017 回答
1

对于此类项目，Scrum 的问题更多地在于 Scrum 旨在支持的开发团队结构类型，特别是团队在日常站立会议中的托管。当您不在同一个物理位置时，很难举行每日站立会议。此外，我怀疑你的团队中是否会有产品负责人，你既是 Scrum Master 又是开发人员。最重要的是，您和您的其他开发人员将在不同的时间和日子里工作，可能根本没有任何工作完成。这可能会使团队的协调变得困难。

每个项目，无论开发方法如何，都应该很好地了解需要完成的工作（产品待办事项）、短期内需要完成的工作（冲刺待办事项）以及完成这些任务需要多长时间，这样您才能拥有对项目需要多长时间的合理估计（项目速度和燃尽）。您可能会遇到问题的是 Scrum 的其他部分 - 没有在同一地点参加会议、缺少产品负责人、使用公告板显示 sprint 状态等。

这并不是说您不能修改 Scrum 流程以适应您的目的。例如：

  • 每周在规定的时间举行几次视频会议/Skype 通话/IM 会议，即使什么都没做。对于这种类型的项目，每天可能过于频繁，但每周三次可能对您的团队有用。
  • 使用基于 Web 的问题管理系统，这样您就可以看到产品待办事项，知道 sprint 待办事项是什么，并知道人们在做什么
  • 已设定冲刺长度（例如 3-4 周），以便开发人员能够感知动力并了解最后期限
  • 了解在开发上花费了多少时间，这样您就可以计算出您的项目速度以及在下一个 sprint 中可以实现什么。这可能很难，因为可用时间会因冲刺而异。
  • 在每个 sprint 之后进行回顾，这样您就可以根据进展顺利和不顺利来调整您的开发过程。如果可能的话，这将是在同一地点见面的理想时间。

从本质上讲，Scrum 主要是关于有效的沟通，所以如果你做对了，你应该能够让它的修改版本为你工作。请记住，沟通效率会降低

  • 亲自
  • 视频会议
  • Skype/电话/语音通话
  • 即时通讯
  • 电子邮件

所以尽量使用最有效的方法来开会。

于 2009-01-06T01:22:05.250 回答