甘特图概念

本文目录一览：

• 1、软件工程各种图的区别
• 2、Atlassian In Action-Jira之核心插件（三）
• 3、Microsoft Project 入门

软件工程各种图的区别

1.完成患者监护系统功能级的数据流图、实体联系图、软件结构图。2.网上书店系统,其外部用户主要有游客、会员和管理员。其中,游客进行注册后,可以成为系统的会员,会员享有订购图书及订单和书籍等信息查询的功能,管理员可对系统的各种信息进行管理和维护。根据上述描述,请画出网上书店系统的:①基本系统模型(第0层);②功能级的数据流图(第1层);③底层的订购图书数据流图。1.把如下统计空格程序的Jackson图改画为等价的程序流程图和盒图。2、用Jackson图描述下述的一列火车的构成:一列火车最多有两个火车头。只有一个火车头时则位于列车最前面

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

Microsoft Project 入门

该日程设置可以选择对本项目或者所有项目有效

跟踪甘特图概念： “跟踪甘特图”视图来显示项目的进度情况

任务缩进：父任务自动由【手动任务】变成【自动任务】，因为子任务的持续时间和依赖性决定了父任务何时开始和结束

子任务折叠，显示几级任务 ：

任务周期

里程碑

删除任务，非活动任务

The Codependent Nature of Tasks（任务的依赖性）：由以下方式决定

1. The nature of the task:

2. A best practice or preference

3. Resource availability

4. Reliance on a resource or an action outside the project

Dependency types：依赖类型

Making the dependency connection : 建立依赖连接

最佳实践：只连接表示实际执行工作的子任务，而不是那些摘要任务，通过 Ctrl + click 跳过摘要任务

添加外部项目依赖

Tips：

除了第一个和最后一个任务之外的每个任务都有一个前置任务和后置任务，如果一个任务没有前置任务，将任务连接到项目的开始里程碑。如果这个任务没有后置文物，将任务连接到阶段的结束或者项目的完成里程碑

移除依赖：

方法一

方法二：

Task Types：任务类型

Project 处理 effort-driven 的任务时的行为限制

Estimating Effort and Duration：评估工作量和工期

Effort（工作量）： 工作量是完成一项任务所需的人工数，工作量通常表示为小时（ staff hours ），日（ staff days ），周（ staff weeks ）

Duration（工期）： 工期是完成任务所需的工作时段的总数（不包括假期或者其他非工作时段）。工期通常表示为工作日（ workdays ）或工作周（ workweeks ）

Estimating techniques

计算加权平均值最常用的方法是： 最可能发生的情况可能性大于最佳情况和最坏情况

t e = (t o + 4t m + t p ) / 6

Setting the task duration

Controlling Timing with Constraints

Splitting task：拆分任务：有时候一个任务开始后，需要暂停几天然后才能继续开始。

Reaching a specific spot in your plan：到达计划中的指定位置

Gantt Chart view： 甘特图有两部分，左侧的工作表窗格和右侧的图标窗格。其中左侧的工作表可以是以下9种预设工作表种的一种（操作方式：通过 View - Data group - Tables 进行工作表的切换，通过列的显示隐藏进行列的自定义显示）

Resource Sheet： 在资源工作表视图中，可以在你的项目中添加处理工作的资源，在单元格中输入条目按下 Tab 和箭头方向键进行修改信息

Team Planner：

Network Diagram view：

网络图视图 没有时间刻度 timescale ，不用用于查看特定时间（ specific timing ），而是用于查看计划中任务大体的逻辑顺序。任务框（节点）中包含每个任务相关的时间信息，例如：开始时间，结束时间和周期（ duration ）- 这些信息可以自定义 。

默认情况下时间轴视图（ timeline view: View - Split View group - click timeline checkbox ）显示在网络视图的顶部