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

我们有各种各样的小型项目，有几个大型项目，团队是跨项目的，而且它们是多任务的。我们对Scrum确实很感兴趣，但是它似乎不适用于小型项目(少于2周)，目前这些项目占用了我们很多时间。

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

解决方案

在每个项目中尝试一种方法，然后看看哪种方法效果很好。

Scrum当然可以应用于两个星期的项目。我们可以缩短sprint的持续时间，也可以每个sprint进行多个项目。

而且，没有什么可以说我们不能选择要在项目中使用的不同方法的一部分。

Scrum不适用于这样的小型项目。因为在定义上，Scrum冲刺是2周长。 XP的一些变体或者极限编程将更适合。但是，如果要在2周内完成一个项目(如果很复杂)，将需要开发人员高度专注。

另外，无论我们选择哪种方法，都不要害怕修改流程以更好地适应团队。

我认为我们应该像凯文(Kevin)所说的那样尝试一些方法，以了解我们当前的团队如何使用它。某些人不太愿意尝试XP或者其他新方法。我们还应该为小型和大型项目尝试不同的方法。 2年项目的2周项目的方法可以更改。在一个2周的项目中，我们可以进行1次迭代，并且可以在开始时计划整个2周的时间，而这对于2年的项目来说是不可能的。

即使典型项目很小，我还是会第二次使用Scrum。将冲刺看成是两天，三天或者四天的时间。我们仍然可以将Scrum的"大量持续反馈"基础整合到项目中。

我们只想让客户在最后说："哦，那根本不是我们要做的事情！"，我们不想花两周的时间来工作。

在IT对话中收听Ken Schwaber关于Scrum的简短演讲，其中充满了很棒的BTW播客。

然后，我将在InfoQ上观看Tim McKinnon关于敏捷的演讲，该演讲也充满了精彩的演讲和访谈。

HTH。

干杯，

抢

我认为使用TDD(测试驱动的开发)将为这些项目带来很多好处。这将有助于开发和设计。单元测试也可以是实现细节和设计决策的"微型文档"。

我们从Scrum开始，因为它的正式结构(估计，用户故事计划，任务计划，日常会议，回顾)有助于我们从旧方法中获得更大的敏捷性。现在，我们发现可以在早上的会议中根据任务​​/用户故事来完成3个计划和评估会议。

我们为每个用户故事提供了一个大的针脚板和索引卡针脚。董事会分为未开始，进行中和完成。我们确保分解任务的时间不会超过一天，并且会在每天需要它的那一天的早晨召开会议，分解每个用户的故事。这使我们保持敏捷，以便可以更改用户故事的"功能"列表，而无需花费时间将其分解为任务。这样可以确保两个星期的项目可以轻松地以与大型项目相同的方式进行处理。

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

拥有较小的任务还可以促进对源代码控制的更多常规提交，并与构建服务器和部署脚本相结合，我们每天至少可以一次在应用程序中交付进度，至少可以很好地从客户端获得反馈。我们也有每周的回顾展，并且每3个月左右聘请一位敏捷顾问一周，以确保我们步入正轨。

我会推荐Scrum。