甘特图表在敏捷软件开发中有作用吗？

Question

我听说甘特图是瀑布项目管理技术的遗物。

我通常使用一种类似敏捷的方法来进行项目规划和跟踪进度，这将在项目进展过程中提供对功能时间权衡的良好能见度。

我们正处于一个项目的开始阶段，在这个项目中，虽然在这个早期阶段，确切的前端用户交互设计有些不明确，但是后端需求是相当清楚的(与各种第三方API、服务器基础设施等通信的组件)。

我们将经历一个为前端开发良好的用户交互设计的过程(从用户故事开始，从那里开始工作)，但我们也想知道后端需要多长时间。

我认为最好的方法是将其分解为子组件，其中每个组件都由紧密耦合的代码组成，这些代码可能需要在连续的一段时间内处理。

我给每个组件和子组件分配了粗略的时间估计，通常从1天到10天不等。然后，我使用OmniPlan来指示这些不同组件之间的依赖关系，并为每个任务分配开发人员，目的是尽可能平均地分配工作。

然后我使用OmniPlan的水准工具。我认为，这是使用OmniPlan的一种相当标准的方法，而且我认为有合理的方法可以得出粗略的时间估计。

我应该澄清的是，我们的意图不是想出一个硬性的蓝图，说明谁将在什么时候、什么时候进行工作，而是更多地想出至少一种可行的办法，使我们能够在两个月内建造我们需要的建筑。甘特图表明这是可行的。

令我惊讶的是，我收到了另一位熟悉敏捷开发过程的团队成员的强烈反对，他们指责我采用了瀑布式方法。

他们更具体的批评是，甘特图是根据建筑组件而不是用户可见的特征来指定的。他们感到沮丧的是，它并没有说“我们应该在Y日期前拥有X功能”。

我哪里出错了？

Answer 1

我在使用甘特图时遇到的最大问题是这个。他们并不能很好地说明项目的总工作量随着每次迭代的变化而变化。尽管如此，我们组织中的大多数企业主都熟悉甘特图。这使得它们比首选的(在我看来)烧坏的图表更容易沟通进度。烧毁确实显示了团队的进展以及整个项目生命周期中项目范围的变化。因此，我认为有妥协的余地，但我总是会有一个燃烧准备，以帮助填补一些缺失的信息，从甘特图。

如果你只是用它来做初步估计，我看不出有什么大问题。用它来追踪进度对我来说是过时的，也是“水到渠成”的。

Answer 2

您想要的是有一个结束日期的概念，有一个固定的资源集和一个固定的范围。这通常是甘特图的用途，但绝对不是敏捷的。

“敏捷宣言”指出：

我们已经有了价值:响应改变而不是遵循一个计划，也就是说，当右边的项目有价值时，我们会更多地评价左边的项目。

来源：http://www.agilemanifesto.org/

这意味着敏捷实践者更希望能够轻松地对多个重要的范围变化做出反应，而不是能够提前一个月(并致力于)预测(其他方法无论如何都做得不好，但他们的目标是解决这一问题)。

如果您的客户/管理人员更重视左边的项目，那么执行敏捷和解决他们的问题将是棘手的。

如果您对具有明确和固定规范的组件有固定的需求集，并且需要提供交付日期，那么敏捷方法可能不是最适合您的情况。

所以，为了回答你的问题，你没有做错什么，但你没有以敏捷的方式去做。正如quickly_now在一篇评论中所说的，陷入方法论是很糟糕的，所以一切都很好，你只是务实而已。

对于前端用户交互，似乎没有期望您提供一个交付日期，而且范围也不清楚，那么在这里，毫无疑问，敏捷似乎是正确的做法。

Answer 3

在现实世界里，严格的时间线是强制性的！

你觉得你的车换了油后，商店里的人说：“我明天下午4点就能给你换油了。”或者“我明天下午4点就能给你拿回来，但我可能只有时间把旧油抽干”。

最后期限是管理的必要条件。他们必须计划，协调和预算的各种东西，除了你的项目，他们需要知道什么时候准备好！

由于几乎不可能为任何相当大的软件项目提供准确的估计，这将使您陷入不可能的境地。

最好的工具仍然是经验和直觉。甘特图表，项目计划等是必要的烟雾和镜子，以使管理远离你的背后。