敏捷方法论是什么？ [关闭]

Question

您会为网站商店推荐哪种敏捷方法？

我们有各种各样的小项目和一些大项目，团队是跨项目的，他们是多任务的。我们对Scrum非常感兴趣，但它似乎不适用于小型项目（不到2周），这些项目目前占用了我们很多时间。

在我们的情况下，有哪些替代方案可以实施敏捷原则？

Answer 1

我们从Scrum开始，因为它的正式结构（估算，用户故事规划，任务规划，日常会议，回顾）帮助我们从旧方法中获得更灵活。我们现在发现，3个计划和会议会议可以在早上的会议中以任务/用户故事为基础进行。

我们在索引卡上有一个大针板和针脚，用于每个用户故事。董事会分为未开始，正在进行中。我们确保在分解任务时任务不会超过一天，并且我们会在每天早上会议中分解每个用户故事。这使我们保持敏捷，以便列出“特征”。因为用户故事可以在没有我们花时间分解成任务的情况下改变。这样可以确保两周项目的处理方式与大型项目相同。

为了估算速度，我们会在一周结束时统计卡片，看看我们完成了多少任务。缺点是发布计划和速度估算不如Scrum那么准确，但这种混合XP方法可以帮助开发人员在准备就绪时专注于任务，而不是在会议上浪费太多时间。

拥有较小的任务还可以促进对源代码控制的更多定期提交，并与构建服务器和部署脚本相结合，我们至少每天可以在应用程序中提供一次进展 - 非常适合从客户端获取反馈。我们也每周都会进行一次回顾，并且每隔3个月左右就会聘请敏捷顾问一周，以确保我们保持正确的轨道。

Answer 2

Scrum肯定适用于两周的项目。您可以缩短sprint持续时间，也可以每个sprint执行多个项目。

此外，没有任何内容表明您无法挑选和选择在项目中使用的不同方法的部分。

Answer 3

每个项目尝试一种方法，看看效果如何。

Answer 4

我认为使用TDD（测试驱动开发）会在这些项目中提供很多好处。它有助于开发和设计。单元测试也可以是“微文档”。用于实施细节和设计决策。

Answer 5

即使您的典型项目很小，我也会使用Scrum。看看你的冲刺是两天，三天或四天。您仍然可以合并“大量持续反馈”。 Scrum进入你的项目的基础。

你不想在两周内做一些事情，只是让客户在最后说“噢，这根本不是我们所追求的！”

在谈论Scrum href =“http://itc.conversationsnetwork.org/”rel =“nofollow noreferrer”> IT对话，其中包含很棒的播客BTW。

然后我会看Tim McKinnon的谈敏捷在 InfoQ 上，这里也充满了精彩的演讲和采访。

HTH。

欢呼声，

罗布

Answer 6

我认为你应该尝试凯文说一些方法来了解你当前的团队如何使用它。有些人不习惯尝试XP或其他新方法。您还应该为您的小项目和更大的项目尝试不同的方法。 2周项目2周项目的方法可以改变。在为期2周的项目中，您可以进行1次迭代，并且可以计划在开始时整整2周，这对于2年的项目来说是不可能的。

Answer 7

Scrum不适合这样的小项目。因为在它的定义中，scrum sprint是2周。 XP的一些变体，或极限编程将更适合。但是，如果项目很复杂，那么在2周内完成项目将需要您的开发人员非常专注。

此外，无论您选择何种方法，都不要害怕修改流程以更好地适应您的团队。

Answer 8

我会推荐Scrum。