优化甘特图

本文目录一览：

• 1、如何用project制作甘特图
• 2、project软件怎么制作甘特图
• 3、甘特图的做法及用途
• 4、甘特图的做法及用途是什么？
• 5、Atlassian In Action-Jira之核心插件（三）

如何用project制作甘特图

先编制计划步骤：

设置工作间项目起始（或结束）期并新任务设置自任务（便自调整）；

资源工作表列项目所用资源详细信息；

键入任务名称、资源名称、工期；并用摘要任务进行组织（详见WBS代码）；

设置任务间关系（主要前置任务）；必要部任务设置程限制；

项目计划进行调整、优化

二

视图切换甘特图能看软件自甘特

project软件怎么制作甘特图

一

先编制计划，步骤：

设置工作时间和项目的起始（或结束）日期，并将新任务设置为“自动任务”（方便自动调整）；

在资源工作表中，列出项目所用资源的详细信息；

键入任务名称、资源名称、工期；并用摘要任务进行组织（详见WBS代码）；

设置任务间关系（主要是前置任务）；有必要的话，为部分任务设置日程限制；

最后对项目计划进行调整、优化。

二

将视图切换到甘特图，就能看到软件自动生成的甘特图。

甘特图的做法及用途

在项目管理中，甘特图是通过图形的方式更直观的表现出任务安排以及任务之间的关联性，有了甘特图，可以使项目经理从大量的密密麻麻的表格中解脱出来。

如果你使用的专门的项目管理软件（推荐MS Project），其实不需要特别编制甘特图，只需要你将任务填写清楚，包括：任务名称，工期，开始和完成时间，前置任务，资源名称等基本内容，软件会根据你录入的内容自动生成甘特图，在今后的阅读中十分方便。

甘特图（Gantt chart）又称为横道图、条状图(Bar chart)。其通过条状图来显示项目，进度，和其他时间相关的系统进展的内在关系随着时间进展的情况。以提出者亨利·L·甘特（Henrry L. Ganntt）先生的名字命名。

甘特图的做法及用途是什么？

1、计划评审技术是用来安排大型、复杂计划的项目管理方法。是一种规划项目计划

(project)的管理技术，它利用作业网(net-work)的方式，标示出整个计划中每一作业

(activity)之间的相互关系，同时利用数学方法，精确估算出每一作业所需要耗用的时间、经费、人力水平及资源分配。

计划者必须估算：在不影响最后工期(project

duration)的条件下，每一作业有多少宽容的时间，何种作业是工作的瓶颈

(bottle

neck)，并据此安排计划中每一作业的起记时刻

(scheme)，以及人力与资源的有效运用。PERT的内容包含了「管理循环」中的三个步骤：计划(planning)、执行(doing)、和考核(controlling)。

2、甘特图，也称为条状图(Bar

chart)。是在1917年由亨利·甘特开发的，其内在思想简单，基本是一条线条图，横轴表示时间，纵轴表示活动(项目)，线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。

管理者由此极为便利地弄清一项任务(项目)还剩下哪些工作要做，并可评估工作是提前还是滞后，亦或正常进行。是一种理想的控制工具。

甘特图的含义

甘特图包含以下三个含义：

1、以图形或表格的形式显示活动；

2、现在是一种通用的显示进度的方法；

3、构造时应包括实际日历天和持续时间，并且不要将周末和节假日算在进度之内。

甘特图具有简单、醒目和便于编制等特点，在企业管理工作中被广泛应用。甘特图按反映的内容不同，可分为计划图表、负荷图表、机器闲置图表、人员闲置图表和进度表等五种形式。

3、最早出现于20世纪50年代，它是通过分析项目过程中哪个活动序列进度安排的总时差最少来预测项目工期的网络分析。其通常做法是：

1）

将项目中的各项活动视为有一个时间属性的结点，从项目起点到终点进行排列；2）

用有方向的线段标出各结点的紧前活动和紧后活动的关系，使之成为一个有方向的网络图；3）

用正推法和逆推法计算出各个活动的最早开始时间，最晚开始时间，最早完工时间和最迟完工时间，并计算出各个活动的时差；4）

找出所有时差为零的活动所组成的路线，即为关键路径；5）

识别出准关键路径，为网络优化提供约束条件；

特点：

关键路径上的活动持续时间决定了项目的工期，关键路径上所有活动的持续时间总和就是项目的工期。

关键路径上的任何一个活动都是关键活动，其中任何一个活动的延迟都会导致整个项目完工时间的延迟

关键路径上的耗时是可以完工的最短时间量，若缩短关键路径的总耗时，会缩短项目工期；反之，则会延长整个项目的总工期。但是如果缩短非关键路径上的各个活动所需要的时间，也不至于影响工程的完工时间。

关键路径上活动是总时差最小的活动，改变其中某个活动的耗时，可能使关键路径发生变化。可以存在多条关键路径，它们各自的时间总量肯定相等，即可完工的总工期。

关键路径是相对的，也可以是变化的。在采取一定的技术组织措施之后，关键路径有可能变为非关键路径，而非关键路径也有可能变为关键路径。

另外,站长团上有产品团购,便宜有保证

Atlassian In Action-Jira之核心插件（三）

Jira的道在于构建了整个环境和思维模式，也赢得了市场的认可，成了一种势。无数的厂家便成了Jira的海洋生态当中的重要组成部分。有些厂家的插件是提升了Jira的体验，有些则是强化了特定功能。这里只推荐三个算得上 必须 使用的插件。

围绕这三个插件，我们能够搭建起研发管理的整体路线和迭代管控视图，简化流程，完善管理制度。接下来就介绍每个插件的场景和使用方式。

我们通过一张图形成一个大概的印象

我们当时选择这个插件期望满足的场景有下面几个：

我们项目管理常用的软件就是微软的Project，所以我们选项目标也是按照这样的思路来挑选的。最简化的概念就是 甘特图 。

当中有设置的必要的应该是Working schedule了

设置放假和周末，这样在计算任务起止的时候能够在甘特图中正确的显示，其他我没有做过多的设置。

从上图可以看出甘特图的组织形式分为4层。

1. 项目（Project）

2. 版本（fixVersion）：注意是根据父任务的修复版本确定的

3. 父任务（Story/Task）

4. 子任务（Sub-Task）

在甘特图的界面可以进行任务的管理。

可以拖动任务的两端进行开始和截止日期的调整，也可以直接拖动整个任务进行任务的调整。

任务的进度是通过下面的三角标识进度，这个计算是使用实际投入的工时与预计工时直接的比例。

蓝色的线是在日期栏直接左击，就可以设置一个时间线，默认是设置在选择日期的开始。可以用于设置迭代里程碑。

显示内容的设置界面如下：

可以看到有四种方式可以混合使用：

1. 面板

2. 过滤器

3. 项目

4. JQL查询语句

任务列表界面上元素都是可以根据实际系统中设置的字段进行调整的，如下图所示：

绿色的是自定义字段，灰色的是系统字段。自定义字段基本都是单纯的显示，系统字段会有一些其他的效果。

这个插件在前端没有任何感知，知道Jira系统中存在这个插件的基本也只有管理员了。但是对于管理员来说，这是流程推进、串联的最重要的工具了。

它的作用是在工作流的流转过程中可以附加其他的操作，列表如下：

可以看到主要有赋值、分配人员、评论、触发其他流转环节、自定义脚本等等，而且可以针对问题本身、父问题、关联问题。基本能够涵盖日常应用的场景了。

我讲一下我实践过程中，比较常用的几种场景：

使用到 Assign to last role member 或者Assign to role member 。场景例如bug，当测试发现一个bug时，可能并不直接指定具体研发，而是 提交给研发管理小组 确认之后再分配给具体研发，具体研发人员修改完成后，点击 修改完毕 按钮，转发给测试。测试若发现bug没有完全修复，点击 退回研发 按钮，直接退回对应研发（而且可以累积退回次数）。

这里面的几个步骤：

1. 修改完毕，会追溯到测试角色的最后一个经办人，并且将问题分配给他

1. 退回研发，会追溯到研发角色的最后一个经办人，并且将问题分配给他

为何要追溯某角色的最后一个经办人？因为内部可能还存在多次指派，甚至对bug进行分析后发现不是后端bug要指定给前端研发。测试不用自己分析要退回给谁，让流程来判断。

使用到 Transition linked issues 和Transition parent issue 。我们最早就讲过，整个系统是子任务驱动的，具体人员只用关心和管理自己的子任务（子任务只有开始和结束两个简单状态），但是父任务涉及多人合作和角色含义，状态和节点可能会有几十个，无论让谁来管理都是很困难的。场景，一个父任务需要UI、产品、前端、后端、测试共同完成。其中可能产品先行，完成之后交付给UI，完成就可以前后端介入，研发全部完成后才能交付给测试执行。

这里面思想其实很简单，就是子任务工作流+角色。首先对于不同角色要区分出合理的用户组，当每个人完成任务时，判断他自身的角色从而触发父任务的状态流转。比如产品完成任务时，转至 方案设计完成 ，研发完成时可以判断当前父任务下是否存在测试子任务，若存在转至 研发完成待测 ，若不存在说明不需要测试转至 研发完成无需测试 。

这里给大家一个小小的建议

当你添加自动化工作流时，这里时可以选择名称或者id的，id就是一串唯一数字，当你需要精确触发工作流时可以指定。但是像上面描述的那种情况，其实并不能完全判定当前的状态是什么。比如需要产品协助时，产品会先完成任务之后研发才开始，这时候研发介入的上一环节是 设计方案完成 ，但是也存在不需要产品研发直接开始比如研发内部优化，这种情况下研发介入的上一环节是 待办 。如果这时候指定的具体的工作流，起始状态不正确就无法执行。所以建议是使用名称，而且建议规范是 转至+下一环节名称 ，比如到研发这个环节，无论从待办或者方案涉及完成，甚至测试退回，都成为 转至研发 ，这样我们只要写一次post function就可以满足多种情况了。

注意 ：即使使用名称流转，也必须满足该流转的起始和中止状态满足当前情况。例如如果我 方案设计中 如果没有指向 研发进行中 节点，即使我尝试触发该流转也是无法执行的。

研发在质问我，已经9012年了我们还要使用工时这种low爆的形式来做绩效管理么？每天凑满8小时工作时间对于管理层就这么重要么？你们的能力仅仅就是看着这个人工时有没有记录好么？

如果你这么想，说明你没有想过研发管理到底该做什么。研发管理控制三要素：时间、成本、质量。控制的目的是提升，如何提升？必然是发现问题，改进才能提升。最简单发现问题的地方是 工时分配 ，而不是某个员工8小时工时本身。某个迭代中，那个story投入的工时超出成本，哪些人的bug工时投入超出正常比例、哪些人的线上问题投入工时较高、整体研发部门投入在非研发工作上的比例是多少，要不要优化。这些才是我们应当去关注并改进的。当所有人员只有3-5个人，可能这个数据受个人影响比较大，但是当人员超过30-50人时，个人少报或者没有正确填写的影响就已经比较小了，我们要观察的是趋势，大项的时间投入正常都是有记录的，这样基本就能够反应真实情况了。

所以Tempo作为目前时间管理最好的工具，在研发管理中重要性相信各位管理人员都有认知了。

tempo当前最新是9.4.2版本，我使用的是8.15.3 。我尝试升级过一次插件，结果大家都不习惯新的界面，我不得不退回老版本。

全局配置中有几点说明，我们是子任务驱动所以工时不允许记录在父任务。但是只有一个任务下有子任务的时候才是父任务，否则就可以记录工时。

Work Attributes是设置工时填写面板的自定义字段

注意 ：这里的字段只有通过记录工时按钮呼出的界面才有，比如完成任务时填报工时的界面是没有自定义字段的。

v9去掉的就是这个工时表，这个基本上是我们最常用的功能了。所以去掉之后大家都不知道怎么用了。

用户这个地方的下拉框可以选择如下几种选项。其中比较难理解的是账户这个概念，tempo里面实际上是有成本概念的，就是通过账户当中的金额来管理，不过我们没有使用过。

常用的几个是用户（分析单个用户的工时分布），团队（每个小组整体任务工时分布），高级（指定过滤器查看任务工时分布），问题（查看单个问题的人员工时分布）

时间区间可以任意指定，查询出的结果可以直接导出excel用于做透视图之类的。

v9主推的就是Reports操作的内容和界面形式应该是更加优化，上面的时间区间、过滤器设置（可以多选），分组可以多选和排序。

这个我们用的比较少，主要会针对某个具体问题、或者较大的Epic相关的项目站会、总结会时，分析人员工作进度和使用。

上述三个插件加入到Jira之后，我们完成了迭代整体控制、工作流实施、研发管理规范与提升三方面配置，基本已经可以开始组织一个研发团队为了同一个既定目标按照统一规范流程进行开发，而且尽量简化过程降低研发非研发类工作的占比。但是我们还是可以使用一些其他的插件来提高研发管理整体效率。另外必须说一句，这些插件的仪表盘可用插件没一个能用的。