什么敏捷方法?[关闭]

我们从Scrum开始,因为它的正式结构(评估、用户故事规划、任务规划、日常会议、回顾)帮助我们从旧方法中获得更敏捷的方法。我们现在发现,3个计划和电子化会议可以在上午会议的任务/用户故事基础上完成。

我们为每个用户故事提供了一个大的钉板和钉上索引卡。该板分为“未启动”、“正在进行”和“完成”。我们确保没有任何任务需要一天以上的时间来分解它,并且我们在每天的晨会上分解每个用户故事,在我们需要它的那一天。这使我们保持了敏捷,这样用户故事中的“特性”列表就可以改变,而不必花时间将其分解成任务。这就确保了两周的项目可以像大型项目一样轻松地处理。

为了估计速度,我们在周末统计卡片,看看我们完成了多少任务。缺点是,发布计划和速度估计不如Scrum准确,但是这种混合的XP方法可以帮助开发人员在准备好时集中精力完成任务,而不会在会议上浪费太多时间。

拥有较小的任务还可以促进对源代码管理的更常规的提交,并结合构建服务器和部署脚本,我们可以至少每天在应用程序中提供一次进展—这对于从客户机获得反馈非常有用。我们也有每周回顾,并且每3个月左右就雇佣一个敏捷顾问一周,以确保我们走上正确的轨道。

Scrum当然可以应用于两周的项目。您可以缩短冲刺持续时间,也可以对每个冲刺执行多个项目。

此外,没有什么可以说明您不能在项目中选择不同方法的一部分。

每个项目尝试一种方法论,看看哪些方法有效。

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

尽管您的典型项目很小,但我还是会使用scrum。把你的短跑看成是两天、三天或四天。您仍然可以将Scrum的“大量持续反馈”基础纳入到您的项目中。

你不想花两个星期的时间做什么事情,只想让顾客在最后说:“哦,这根本不是我们想要的!”

听听肯·施瓦伯的短篇小说 talk about Scrum 在 IT Conversations 里面有很多很棒的播客。

那我就看蒂姆·麦金农的 talk on Agile 在 InfoQ 这里也充满了精彩的谈话和采访。

Hth.

干杯,

抢劫

我认为你应该试着像凯文所说的一些方法论来看看你现在的团队是如何使用它的。有些人不太愿意尝试XP或其他新方法。您还应该为您的小型项目和大型项目尝试不同的方法。为期2周的2年项目的方法可能会改变。在一个2周的项目中,你可以有1次迭代,并且你可以在开始时计划整个2周,这对于一个2年的项目来说是不可能的。

Scrum不适合这样的小项目。因为在它的定义中,Scrum冲刺需要2周的时间。XP的一些变体,或者极端编程,将更适合。然而,在2周内完成一个项目,如果这很复杂,将需要开发人员非常专注。

此外,无论您选择什么方法,不要害怕修改流程以更好地适应您的团队。

我推荐Scrum。