甘特图比单页大是否有用?

使用MS项目对软件开发项目进行微观管理是人们可以做的更愚蠢的事情之一,尤其是在敏捷环境中。太多的事情花费了你预测时间的1/10或10倍,太多的事情超出了预期,太多的项目计划会议占用了有用的工作时间。

此外,作为甘特图的奴隶也是一件很常见的事情,尤其是对于来自不同学科的项目经理。

但是,它们对于确保在特定期限内完成操作(使用XYZ设置帐户、遵守网站上的检查措辞等)非常有用。编程任务的粗粒度截止日期也很好。

在我看来,我确信有些人已经从微观管理编程工具中取得了成功。

我们总是在项目规划中使用甘特图。它们总是有用的-在所有的事情都说了做了之后,gannt图表是可视化您的项目的最佳工具之一。

然而,它是一种工具。如果工具使用得当,它是有效的。如果不是这样,它可能会起反作用。

你需要知道如何正确地计划你的项目。您需要了解任务列表中应该包含什么以及如何包含。例如,对于一个IT项目来说,它几乎总是无用的,一直到单个任务的级别。 (创建使用数据存储的表 )保持故事水平( 允许用户登录 )将整个团队分配给它,这样计划就会变得容易得多。

稍后,您可以一直转到单独的任务级别,并且可以创建单独的项目计划来处理单独任务的工作分配。

是的,我看到它成功了。在成功的案例中,他们采用了分层的方法。

整个项目有一个具有顶级目标的主图表,而不是一个包含数百个任务的大型Gannt图表。然后有单独的图表来完成子目标。尽管这在某种程度上限制了灵活性(您不能自动平衡子目标团队之间的资源),但它似乎更符合人类良好运作的方式:在中小型团队中。

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

我在70年代后期绘制了页面大小的甘特图。 足够的细节,所以我放弃了。有5个任务的甘特图是无用的。

从90年代开始,我就用过MS 约10个6-12个月的实际项目和任务 大约1周的时间,组织了50-250个任务 与软件体系结构元素相关的体系结构,以及团队 5-10人。这样的计划打印成3×5整页的网格。 我们倾向于把它贴在可以看到的墙上。

这些对于计划的目的来说是很好的,因为 他们强迫你详细说明一个项目的主要活动, 向下描述、顺序和优先顺序。团队可以看到任务, 看看哪些是他们的,你可以和团队一起回顾 成员,以便每个人都可以提供有关持续时间的有用反馈 以及任务排序。

他们没有用的是认真跟踪项目进展。 孙子告诉我们,没有计划能完整地生存在战场上,甘特 图表也不例外。诚然,小心一点,你可以 每隔几周仔细修改一次计划,并标出取得的进展。 一个“真正的项目经理”可能会这样做。我们非常小心 所以最初的计划任务在 一半的项目,到那时人们已经很清楚了 问题和额外的重新规划是非正式的,而不是非正式的 使用MS项目。

我还使用MS Project计划了许多类似的任务 时间和估算目的。这有不幸的副作用 在大部分成本可见的情况下做出现实的估计。 令人惊讶的是,现实的评估会扼杀项目提案。 业内人士似乎想严重低估启动项目的能力; 难怪有这么多人超支时间和预算。

我和微软项目本身有爱恨关系。它需要任务描述, 任务优先级和资源分配。但我不能说,“我 更喜欢 这个任务要先完成那个任务”,这是一个可选的任务先例,我不能将一个资源部分分配给一个任务,一部分分配给另一个任务,并得到任何合理的时间表。

但是对于复杂的项目评估,我看不出没有这个你怎么能活下去。 敏捷的人会告诉你你不能计划;我不知道他们的客户是谁。 我从来没有找到一个客户愿意让我在没有一个计划或一美元/时间预算的情况下工作。

一张比一页小的干图有用吗?这些小信息可以很容易地放在白板上,或者贴在上面,或者你一直看到的任何东西上。当你能在一分钟内用铅笔在任何纸上指定必要的信息时,你真的没有任何理由开始与任何一种干净利落的工具搏斗。

我曾在一个项目中工作过,其中使用了甘特图/MS项目文件来成功管理该项目。项目信息由非开发经理维护,该经理单独与团队会面以获取状态更新。这个系统似乎工作得相当好,甘特图为整个团队提供了一个快速的状态查询。和我在一家使用这种方法的公司工作的一位朋友交谈时,他们的团队似乎工作得很好。

在我所从事的其他项目中,开发主管希望维护图表,但没有成功。该负责人通常会花费额外的时间与微软项目进行角力。如果文化关注的是惩罚进度延迟而不是解决问题,那么可以很容易地操纵甘特图,在交付日期之前按计划显示项目。在这些情况下,甘特图变成了一个额外的工作,对项目没有价值。

我认为关键是让开发团队之外的人更新MS项目文件。甘特图应被视为一种工具,用于沟通项目状态、可能出现的进度延迟问题和资源需求计划。有了这些项目,甘特图会很有帮助。

我发现甘特图对于计划一个项目的时间线和允许X天的休假、延误等都很有用。它们还可以确保在整个项目中100%地分配所有资源。

作为开发人员和团队领导,在实际工作项目时,我发现最好在短迭代中工作,为整个团队定义清晰的任务。在项目中添加/删除内容、更改或人员时,最好能够调整甘特图并查看项目更改的结果。

我在几个项目中使用了甘特图。是的,它们很有用,而且它们比一页大。我们所做的就是把图表剪切粘贴(用剪刀和胶水)成一张大图表,然后贴在墙上。

麦康奈尔在他的出色 软件项目生存指南 建议团队中的每一个成员都能看到一些东西,以大致了解他们是否在正轨上,这就是我们要做的。

我全心全意赞同关于甘特图不适合敏捷开发的评论——在这种情况下,我们一开始就不清楚实现的细节。

另一方面,我情不自禁地回忆起一个痛苦的周末,我花了很多时间为一个我正在管理的项目准备了一个甘特图,在这个项目中,技术和需求都被很好地理解了,并且进度非常关键。

我们的隔间部分的入口墙部分覆盖了这个甘特图(5A4页宽),这对于确保我们正朝着关键的方向努力——完成现在需要做的事情——是非常有用的,同时也使我能够向项目委员会报告如何实现这一目标。他正在按计划进行工程。

甘特图的有用性当然取决于上下文,但我想说的是,如果你知道你的要求,特别是如果你对你的日程安排很重视,它们会非常有用。

我不太喜欢甘特图,尤其是在MS Project中创建的图表——太少的信息占用了太多的页面空间,最多(像大多数图表一样)信息被扭曲或隐藏。如果甘特图有助于团队审阅所需内容、分配给谁的任务、哪些任务正在下滑、风险在何处-那么它很有用-但是-大多数甘特图都是在项目开始时开发的,然后再也看不到或使用过。那么,回到最初的问题——尺寸重要吗????从最近的书中引用- 如果它是愚蠢的并且有效,那么它就不是愚蠢的。

只有当甘特图具有足够的详细信息,项目经理才能查看项目的状态,并且能够正确说明依赖项和资源时,甘特图才有用。

你可以用胶带把几张纸粘在一起。

分析项目的原则——将项目分解为阶段、步骤、可交付成果、确定资源需求可能比打印出一张漂亮的图表更重要。

我的许多重要的开发项目都得益于项目规划工具的合理使用。

是的,我看到它成功了。在成功的案例中,他们采用了分层的方法。

…

当然。我还建议,当层次结构也映射到团队层次结构时,它最有效,例如,项目经理创建高级图表,团队领导管理中级图表,开发人员可能管理自己的甘特图,但更可能使用类似jira的工具,因为这从开发人员的角度提供了单一的关注点。E,通常更苍白(即它看起来不像一个计划,所以不会吓到他们;)

在MSProject中,我从甘特图中得到的最佳用途是在项目的初始阶段进行容量规划。你可以做粗略的日程安排,如果,移动的东西,移动的人,添加各种里程碑等。这可以给你信心,你正在制定一个合理的计划。

但是,像前面提到的那样,在日常跟踪人们实际需要做的无数小任务时使用它,是在自找麻烦。在这个微观层面上,我对管理时间尺度的巨大影响是 Fogbugz's EBS的东西。你必须努力,但这确实有助于你处理事情。

通过重复总结-甘特是伟大的软件计划开发,但不是它的日常详细更新。

关于页面问题,我所做的大多数最有效的计划(即,以可理解的详细程度将计划传达给人们)都可以制作成A3打印输出。偶尔几页A3纸。但根据我的经验,A4在大多数情况下都太小了。