基于禅道做项目任务管理
背景
因为工作需要，最近学习了Gitlab Flow的流程，感觉更适合真正做软件研发的项目团队，主要面向交付物为代码的这种场景，基本上都是围绕着功能的需求分析、设计、开发、版本发布的敏捷式开发流程。
敏捷式开发模式强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、要求有紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
而我们这边的项目一般是面向企业的驻场实施开发，一般甲方的项目管理需求都是基于瀑布式开发模式的要求，实施周期的各个阶段需要有相应的交付成果，且交付物不限于代码，（需求文档、设计文档、程序代码、测试文档、上线方案等等）。敏捷式开发明显不适用，最多就是基于整体瀑布式开发模式，局部以迭代式开发方式来推动项目主体部分的推进。
同时，客户类项目实施过程中，除了项目本身的工作，还有类似与客户沟通、与第三方厂商沟通，甚至日常的加班、请假、住宿管理等等其他杂项任务，gitlab就更不能满足实这类管理的需要了。
基于以上的思考，又研究了专门的项目管理软件--zentoo（禅道）。
zentoo使用简介（非常简）
背景
因为工作需要，最近学习了Gitlab Flow的流程，感觉更适合真正做软件研发的项目团队，主要面向交付物为代码的这种场景，基本上都是围绕着功能的需求分析、设计、开发、版本发布的敏捷式开发流程。
敏捷式开发模式强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、要求有紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
而我们这边的项目一般是面向企业的驻场实施开发，一般甲方的项目管理需求都是基于瀑布式开发模式的要求，实施周期的各个阶段需要有相应的交付成果，且交付物不限于代码，（需求文档、设计文档、程序代码、测试文档、上线方案等等）。敏捷式开发明显不适用，最多就是基于整体瀑布式开发模式，局部以迭代式开发方式来推动项目主体部分的推进。
同时，客户类项目实施过程中，除了项目本身的工作，还有类似与客户沟通、与第三方厂商沟通，甚至日常的加班、请假、住宿管理等等其他杂项任务，gitlab就更不能满足实这类管理的需要了。
基于以上的思考，又研究了专门的项目管理软件--zentoo（禅道）。
zentoo使用简介（非常简）
zentoo的安装详细可见另一篇文章：禅道本地部署安装
zentoo是国产的开源项目管理软件，是一款非常完备的项目管理软件，覆盖了项目管理的核心流程，能够支持各类开发模式的管理流程。其开原版本身的功能已经很丰富，且初始化就定义了一些角色的工作流程的建议，可以给我们很好的参考，如其“我的地盘”推荐的内容：
我的地盘
zentoo的官网上提供了详细的使用说明文档，在里面有最简单的使用方式介绍，也有进阶的比较复杂的使用流程讲解。根据实际项目的特性，最简的使用方式肯定是不适用的，但是也不必所有的禅道上的功能都用起来，毕竟这个工具是为了方便我们的项目管理，如果太复杂，项目成员和项目经理花太多的精力来维护禅道上的内容反而就得不偿失了。
因此，我们基于禅道最简单的用于项目任务管理的流程，结合实际情况做一下具体的项目管理过程设计，更多的功能随着使用的深入再不断的探索。
项目管理的目标
项目管理目标最重要的一点当然是按期保质的完成项目的上线和交付，但实际上除了这个目标外还有一点附带的就是让项目团队成员在一个项目中获得相应的能力提升。
通常情况下，保证重点目标都已经非常困难了，所以另外的目标往往就被忽略了，然后整个项目周期内大家都是忙忙碌碌的一顿加班，项目上线后做个形式主义的总结后什么都没留下，或者留下一些应付公事的项目过程文档，翻都懒得翻。
在不断的项目实践中提升自身产品和技术方案的价值，提升项目实施工艺水平，提升团队整体的技术水平和管理水平，对我们实施团队来说才是最重要的，而保证项目按期保质交付是附带的执行目标，如果能团队项目管理做的足够好，项目质量不敢说决对，至少有很大的保证。
项目管理的原则
我自己总结了几个项目管理的原则，也包括对项目管理软件的使用原则：
- 项目管理以交付物为导向，以任务为管理单元，所有任务的最终目标都是要有相应的高质量交付物并需经过审核通过。
- 项目之中人人平等，不管是日常作息安排、请假制度、加班制度、工作流程，制定过程征求意见，制定之后后每个人都要严格遵守。
- 项目成员每天有必要的日常任务执行情况的总结登记，但流程设计不能过于复杂，每天用于实现合理项目管理的工作平均耗时不超过30分钟（可以更低，但不应该低于10分钟）。
- 不以单个任务的完成情况评判工作能力，但阶段性任务执行情况应能够作为考评的依据，并能指导改进。
项目角色分配
按照项目不同阶段对人员的需求分配，实施类项目应该包括以下几类人员：
项目经理、需求分析人员、系统设计人员、系统开发人员、系统测试人员等。
每一类人员可能根据所负责的模块或者子系统不同再分组,并且每一类角色还有对应的组长角色来分管,理论上的角色实在相当多。
实际的情况是这种分类方法不太实用，不管你认为合不合理，实际情况是除了模块分组，每个项目成员在不同阶段承担不同的角色是非常正常的情况，因此从任务分配和执行的角色分配上，我觉得只需要将人员分为以下几类就可以了：
- 项目经理（产品经理）
-
项目经理负责推动项目各阶段各项任务的分配和推进执行，对各阶段的交付物进行检查和组织评审，还包括对项目实施期间日常管理工作的内容，额外的还要面对各类甲方、乙方、第三方的工作扯皮工作，事情繁多琐碎是重要特点。所以使用禅道这种项目管理软件目的更多的是为了帮助项目经理将项目的一些日常管理、任务追踪、质量检查这些工作规范化、清晰化，更系统直观便捷的了解到项目的进展情况、项目成员的产出情况等，减少琐事上的精力投入。
-
实施类项目不太注重产品经理的角色，基本上没有专门的产品经理人员设计产品的功能这种形式。大多数情况是由项目经理来承担产品经理这个角色的职责，所以有时候像数据仓库这种本身就偏重实施类的项目，在项目完成后也很难提炼出比较完备的产品，而一般项目做的好的话也只是作为参考的解决方案案例存在，这是题外话。
- 模块分组组长（数据仓库、分析应用等等）
- 分组按照项目模块分组，承担分组组长的角色需要负责对本模块的任务分配、管理和审核工作，相当于分组的项目经理角色，分组任务的需求都是从项目经理分配的需求中获取到的，分组组长不能生成自己的需求。这主要是在一定程度上避免超越项目范围的任务发生。
- 项目经理和各分组组长同时也具备任务执行者的角色，比如在需求分析阶段，需求分析的计划制定和任务设计肯定是由项目经理带领各分组组长进行的任务。
- 项目总体需求、设计、测试等方案都需要分组组长负责各自模块部分的任务，并最终由分组组长提交交付物给项目经理以合并。
- 任务执行者（需求分析、系统设计、模型设计、程序开发、测试等）
- 具体任务的执行者，没有任务指派分配的权限，当任务需要拆分或者变更负责人时，需要通知分组组长。
- 任务的完成标准是有相应的交付物并经过了审核人员的通过。
禅道任务管理
项目初始化
一个新的项目启动后，基于禅道初始化项目的信息，包括成员、产品、计划、项目
1.创建权限、角色和用户
如果项目成员来自多个成员,用来标识项目组成员本身所属的部门，部门属于公司架构的管理范畴。
部门一般会分多级部门。
部门创建
创建三个权限：项目经理、分组组长和任务执行者，其中任务执行者只有任务视图和部分查询功能的使用权限；分组组长额外的有任务管理指派的功能，项目经理有产品、需求的管理操作功能。
权限创建
用户创建
2.创建产品
以数据仓库类项目为例，可以简单的将实施内容分为以下几块：
- ETL工具
- 数仓架构
- 数仓模型
- 数据服务
补充一个非实施内容的杂项工作类：
- 项目支持
这部分包括会议、租房、组织活动、突发事件等其他事情的任务
补充一个项目文档需求的类别：
- 过程文档
这部分指在项目过程中规定的需要提交的交付物，其中的代码部分为各个产品的production版本出来后打包的文件。
产品创建
3.创建项目并关联产品
创建项目
创建项目时，关联相应的产品，这样基于这些产品的需求就可以关联到项目中去。在项目中不细分功能模块，只针对需求分解任务。
4.添加项目团队成员
添加团队成员
然后进入项目列表，选中该项目编辑开始这个项目。
禅道的项目的初始化基本就完成了。
工作流程
工作流程根据角色不同，所需要负责的内容也不一样。
项目经理
项目经理角色日常主要为确定需求、审核交付物成果，以及使用图表统计功能检查人员投入产出比以推动项目管理决策。
1.创建需求
项目经理根据每个模块（产品）的特定，制定相应的需求，有一些需求时需要规划交付计划的，创建相应的时间计划，而有一些常规任务可以不用计划来预估工作安排。
以过程文档为例，过程文档中需求分析阶段需要有相应的交付物-需求说明书，因此在过程文档产品中创建相应的需求：
创建需求
需求创建完毕后，在需求列表中可以对分组长进行需求指派。
所有项目中的需求均由项目经理来创建。
需求创建完成后，在项目视图中对需求进行关联，需求关联也可以让分组组长执行。
2.任务监督
每日工作人员提交自己的任务工时后，项目经理可以从任务的视角查看投入情况，以评估效率和工作饱和度：
任务检查
也可以从人的视角查看每个人完成任务的多少：
成员视角
分组组长
分组组长接受指派的需求，对需求进行分析后分解任务，并指派任务给本组的成员。
创建任务
任务创建完成后分组组长可以对其进行修改调整，包括重新指派。
任务优先级设计
禅道中默认分了4个优先级，我们简单规定下：
| 任务类型 | 等级 |
|---|---|
| 紧急任务 | 1 |
| 优先任务 | 2 |
| 常规任务 | 3 |
| 次要任务 | 4 |
正常排期任务都设定优先级为3。
3.任务执行者
分组组长完成任务指派后（或由任务执行者自行创建任务），在任务列表可以查询指派给自己的任务。
任务列表
任务执行者点击任务开始图标以开启这个任务，任务开始时，需要对任务需要投入的时间进行一个预估，记录到剩余消耗时间中去。
之后每日或者完成时对任务的工时进行录入：
记录工时
要求每个任务执行者每日需要提交任务的投入时间和完成进度，并且对还需要的时间进行登记，最终任务完成需要填写完成总耗时，以便看到预估和实际消耗的差别。
任务完成时，在完成备注中写上该任务对应的交付物的gitlab的合并编号和名称。
gitlab交付物管理
团队协作方式参考文章gitlab使用详解
在禅道中我们将项目按照模块拆分成多个产品；
- ETL工具
- 数仓架构
- 数仓模型
- 数据服务
- 项目支持
- 过程文档
对应的在gitlab中项目团队下也建立多个project
gitlab团队+项目
每个project会包含文档和代码两部分，目录结构由项目负责人来统筹规划，其他成员只需要clone后按照要求提交交付物就可以。
分支设计
每个porject分支创建主要依循以下规则：
- 主分支master为实时最新版本，所有成员的合并请求都提交到master分支
- release分支为发布版本分支，发布版本分支包括评审分支（文档评审、代码评审）、sit测试分支、uat测试分支、投产分支。
- 多轮评审、测试情况下，每次评审和测试前都发布一个release分支，赋予版本号
- backup 备份分支，每周备份，保留近三周备份分支
项目开发人员只需要按照流程要求向master主分支提交合并申请，项目负责人负责对合并内容进行审核以及创建各类分支。
交付物开发
参考文章gitlab使用详解，项目成员使用fork方式，fork各个项目的master分支，然后clone到本地，使用git命令来提交自己所做的内容到fork后自己的分支之中，然后提交merge请求到项目负责人，由项目负责人来审核通过。
