我已经完成了一些通过使用甘特图管理的项目。其中一些具有大量任务，项目经理将所有时间都花在与MS Project搏斗上，而不是做出正确的选择。

我可以理解，是否有许多独立的团队致力于某些事情(例如法律，IT，市场营销)来整体管理一个项目。

有谁参与过使用甘特图取得成功的软件开发项目？

解决方案

甘特图仅在其具有足够的详细信息以供项目经理查看项目的状态以及正确考虑依赖关系和资源时才有用。

我们总是可以用胶带将几张纸粘在一起。

分析项目的学科将其分解为阶段，步骤，可交付成果，确定资源需求可能比打印漂亮的图表更为重要。

我的许多非平凡的开发项目都得益于项目计划工具的合理使用。

小于单个页面的GANNT图表有用吗？很少的信息可以很容易地放在白板或者便笺簿上，或者我们一直看到的任何东西上。当我们可以用铅笔在任何纸张上用铅笔在一分钟内指定所需信息时，我们实际上并没有任何理由要开始使用任何GANNT工具。

是的，我已经看到它成功了。在成功的情况下，他们使用了分层方法。

整个项目没有一个单一的大型甘特图，其中包含数百个任务，而是一个具有最高目标的主图表。然后有单独的图表来完成子目标。尽管这以一种方式限制了灵活性(我们无法在子目标团队之间自动平衡资源)，但它似乎与人类的良好运作方式更好地匹配：在中小型团队中。

使用MS Project进行软件开发项目的微管理是某人可以做的更愚蠢的事情之一，尤其是在敏捷环境中。太多的事情花费了我们预期时间的1/10或者10倍，太多的事情超支了，太多的项目计划会议占用了宝贵的工作时间。

此外，作为甘特图的奴隶，这是很常见的事情，尤其是对于来自不同学科的项目经理而言。

但是，它们对于确保在特定的期限内完成操作(获得设置XYZ帐户，建立合规性以检查网站上的措辞等)很有用。编程任务的粗粒度截止时间也很好。

在我看来，我敢肯定，有人从微管理编程三通中获得了成功的结果。

我们在项目计划中始终使用甘特图。说完一切之后，它们总是很有用的。Gannt图表是可视化项目的最佳工具之一。

但是，它是一种工具。如果正确使用该工具，则是有效的。如果不是这样的话，它可能会起反作用。

我们需要知道如何正确计划项目。我们需要了解任务列表中应包括哪些内容以及如何进行操作。例如，对于一个IT项目，下降到各个任务的级别(创建用于存储使用数据的表)几乎总是无用的。将其保持在故事级别(允许用户登录)，将整个团队分配给它，计划将变得更加容易。

以后，我们始终可以转到各个任务级别，并且可以创建一个单独的项目计划来处理单独任务的分配。

我发现甘特图对于计划项目的时间表以及允许X天的休假，延误等很有用。它们对于确保在整个项目中100％分配所有资源也非常有用。

在实际从事项目工作时，作为开发人员和团队负责人，我发现最好在短期迭代中为整个团队定义明确的任务。随着事情的发生，变化或者从项目中添加/删除人员，很高兴能够调整甘特图并查看项目更改的结果。

我曾在几个使用GANTT图表的项目中工作过。是的，它们很有用，是的，它们比一页还要大。我们要做的是将图表剪切(粘贴，用剪刀和胶水粘贴)成一张大图表，然后将其放在墙上。

McConnell在其出色的《软件项目生存指南》中建议，团队中的每个成员都应查看一些东西，以大致了解他们是否在轨道上，这就是我们的目标。

我完全同意关于GANTT图表不适合敏捷开发的评论，因为我们一开始对实现的细节还不清楚。

另一方面，我忍不住想起一个痛苦的周末，我花了一个甘特图来管理我正在管理的一个项目，该项目的技术和要求非常容易理解，进度很关键。

我们的隔间部分的入口墙部分覆盖有这张GANTT图表(5 A4页宽)，对于确保我们正朝着完成现在和现在需要完成的工作的关键路径进行工作非常有用。还使我有可能向项目委员会报告详细的报告，说明项目进度是否按计划进行。

GANTT图表的有用性绝对取决于上下文，但是我想说的是，如果我们了解自己的要求，尤其是如果我们对计划表非常重视，那么它们将非常有用。

Yes, I have seen it successful. In the cases where it was successful they used a hierarchical approach.
  
  ...

绝对地。我还建议，当层次结构也映射到团队层次结构时，效果最好，例如，项目经理创建高级图表，团队负责人管理中级图表，开发人员可能管理自己的甘特图，但更可能使用JIRA之类的东西，因为从开发人员的角度来看，这提供了一个单一的关注点，并且通常更加苍白(即，它看起来不像计划，所以不会吓them他们；))

我从MSProject的甘特图获得的最佳用途是在项目的初始阶段进行容量规划。我们可以进行广泛的画笔调度和假设操作，四处移动，移动人员，添加各个里程碑等。这可以使我们确信自己正在制定合理的计划。

但是，如上所述，然后每天使用它来跟踪人们实际上必须执行的无数小任务是在自找麻烦。我经常在Fogbugz的EBS东西上对在这种微观水平上管理时间尺度产生巨大的影响。我们必须努力工作，但是它确实有助于保持对事物的掌控。

通过重复进行总结，甘特非常适合开发软件计划，但不适用于日常的详细更新。

关于页面问题，我所做的大多数效果最好的计划(即以可理解的详细程度将计划传达给人们)可以适合A3打印输出。有时会有几张A3页面。但是根据我的经验，在大多数情况下，A4太小了。

我曾在一个项目中使用甘特图/ MS项目文件来成功管理该项目。项目信息由非开发人员维护，他与团队单独会面以获得状态更新。该系统似乎运行良好，并且甘特图可以快速查看整个团队的状态。与我的一个朋友在一家使用这种方法的公司工作时交谈，似乎对他们的团队非常有效。

在其他项目中，我曾负责开发负责人保持图表的工作，但没有成功。主管通常会花费额外的时间来尝试与MS Project进行角力。而且，如果文化专注于惩罚进度延迟而不是解决问题，那么可以轻松地操纵甘特图，以便按计划在交付日期之前显示项目。在这些情况下，甘特图成为一项额外的工作，对项目没有任何价值。

我认为关键是要让开发团队之外的人来更新MS Project文件。甘特图应被视为用于交流项目状态，进度延迟可能出现的问题以及规划资源需求的工具。有了这些项目后，甘特图会很有帮助。

我不是甘特图的忠实拥护者，尤其是在MS Project中创建的图表，因此占用了太多页面空间来容纳很少的信息，并且最多(像大多数图形一样)信息被扭曲或者隐藏了。如果甘特图可以帮助团队审查所需的内容，谁被分配给哪些任务，哪些任务正在滑移，风险在哪里，那么它很有用，但是大多数甘特图在项目开始时就已开发，之后再也没有看到或者再次使用过。那么，回到原始问题大小是否重要？？？？从最近的书中引用它是否愚蠢且有效，那么它就不是愚蠢的

我不是项目经理专业人士，但我负责复杂的开发项目
程序分析工具。

我在70年代后期绘制了甘特图的页面大小图表。他们从来没有
足够的细节，所以我放弃了。具有5个任务的甘特图是无用的。

从90年代开始，我使用过MS
在大约10个6-12个月长的真实项目中完成任务
大约1周大小，并且组织了50-250个任务之间的任何时间
与团队一起研究与软件架构元素相关的继承关系
5-10人。此类计划以3 x 5整页的网格形式打印
并且我们倾向于将其粘贴在可以看到它的墙上。

这些对于计划目的而言是很棒的，因为
他们迫使我们详细说明项目的主要活动，
向下的描述，顺序和优先级。团队可以看到任务，
看看是谁的，然后我们可以与团队进行审查
成员，以便每个人都可以提供有关工期的有用反馈
和任务排序。

他们没有用的是认真跟踪项目进度。
孙子告诉我们，没有任何计划能够在战场上完好无损，而甘特
图表也不例外。诚然，有人可以
每隔几周仔细修改计划并标记进度。
一个"真正的项目经理"可能已经做到了。我们足够小心
这样原始计划任务在整个过程中都可以很好地完成
项目的一半，到那时人们已经很了解了
问题和添加的重新计划是非正式的，而不是非正式的
与MS项目。

我还使用MS Project计划了许多类似的任务以应对严重的疾病
时间和估计目的。这有不幸的副作用
生成逼真的估算，并且大部分成本可见。
令人难以置信的是，现实的估算如何杀死项目建议。
工业界似乎希望低估项目的启动。
难怪会有如此多的超支时间和预算。

我与MS项目本身有爱恨交织的关系。它需要任务描述，
任务优先级和资源分配。但是我不能说："我希望这个任务比该任务先完成"，这会作为一个可选的任务优先条件出现，并且我不能为一个任务分配一部分资源，而对另一任务分配一部分资源，也无法获得任何合理的时间表。

但是对于复杂的项目估算，我不知道如果没有这些，我们将如何生活。
敏捷的人会告诉你你不能计划；我不知道他们有谁作为客户。
我从来没有找到过一个愿意让我工作的客户，没有他会抱着我的计划或者美元/时间的预算。