禅道使用手册

禅道使用说明禅道是第一款国产的优秀开源项目管理软件。

它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。

先进的管理思想，合理的软件架构，简洁实效的操作，优雅的代码实现，灵活的扩展机制，强大而易用的api调用机制，多语言支持，多风格支持，搜索功能，统计功能。

一、系统概述禅道的功能列表：1.产品管理：包括产品、需求、计划、发布、路线图等功能。

2. 项目管理：包括项目、任务、团队、build、燃尽图等功能。

3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。

4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。

5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。

6. 组织管理：包括部门、用户、分组、权限等功能。

7. 统计功能：丰富的统计表。

8. 搜索功能：强大的搜索，帮助您找到相应的数据。

9. 灵活的扩展机制，几乎可以对禅道的任何地方进行扩展。

10. 强大的api机制，方便与其他系统集成。

禅道使用流程图:二、最简使用说明禅道的定位不是简单的任务管理软件，而是专业的协同管理软件。

研发类的项目管理本身具有其复杂性，所以禅道提供的都是必备的功能。

但这并不意味着必须按照禅道的流程来使用，完全可以按照自己的实际情况来使用禅道。

下面将介绍使用禅道的最简单方式。

2.1 使用禅道来进行项目任务管理2.1.1创建项目1)进入项目视图，点击右侧的”新增项目“链接。

2)出现项目添加的页面在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标和项目描述等字段。

其中关联产品是可以为空的。

2.1.2设置团队1)点击保存按钮，会提示项目创建成功，然后可以选择设置团队。

2)或者从项目视图中的团队菜单，也可以进行项目的团队管理。

在维护项目团队的时候，需要选择都是哪些用户可以参与到这个项目中，同时需要设置这个用户在本项目中的角色（角色可以随便设置，比如风清扬，冬瓜一号等）。

可用工作日和可用工时每天需要仔细设置。

通常来讲，一个人不可能每天8小时投入，也不可能一星期七天连续投入。

3)设置完毕之后，系统会自动计算这个项目总得可用工时。

2.1.3分解任务设置了团队之后，下一步操作就是创建任务。

•在创建任务的时候，指派给是从项目团队成员中读取。

•姓名列表中的首字母可以用来快速筛选用户。

•任务的优先级、预计工时（单位小时）都需要进行设置。

•如果需要设置任务必须在某一个时间点截止，可以设置截止日期。

•可以上传附件。

2.1.4更新任务任务分解完毕之后，每个人就非常清楚自己做什么事情。

所以项目启动之后，对于项目团队的成员来讲，他要做的事情就是更新任务的状态。

1)任务的列表在任务的列表页面，可以看到系统中所有的任务列表，可以通过各种标签方便的进行筛选。

点击某一个任务的链接进入详情页面。

2)任务的详情页面在任务的详情页面可以看到任务的详细信息，包括历次的修改记录等信息。

同时也给出了各种操作的按钮。

3)开始任务。

开始某一个任务的时候，可以设置已经消耗的时间和预计剩余的时间。

单位都是工时。

4)完成任务。

完成任务的时候，需要设置下已经消耗的时间。

2.1.5验证关闭任务任务完成之后，会自动指派给任务的创建者，这时候任务的创建者可以验证任务是否完成。

如果完成，则可以将其关闭。

这件任务就结束了。

2.2 只使用禅道来做bug管理测试禅道的测试功能也可以独立出来单独使用。

这种方式很适合于测试团队使用。

禅道里面的bug最基本流程是：测试人员提出bug -> 开发人员解决bug -> 测试人员验证关闭。

2.2.1创建产品使用bug管理功能之前，需要先创建产品。

禅道里面设计的理念是bug主要附属在产品概念下面的，后面我们会详细讲述产品和项目之间的关系。

新增产品的时候，需要设置产品的名称、代码，几个负责人信息。

2.2.2提出bug有了产品之后，我们就可以来创建bug了。

•在创建bug的时候，必填的字段是影响版本，bug标题，重现步骤这些基本的信息。

•所属项目，相关产品，需求可以忽略。

•创建bug的时候，可以直接指派给某一个人员去处理。

如果不清楚的话，可以保留为空。

2.2.3解决bug当一个bug指派给某一位研发人员之后，他可以来验证解决这个bug。

1)通过各种标签和检索条件找到需要自己处理的bug在对bug进行出来之前，需要先要找到需要自己处理的bug。

禅道提供了各种各样的检索方式，比如指派给我，可以列出所有需要我处理的bug。

1)解决bug研发人员解决bug，选择解决方案，一般来讲有效的解决bug方案是”已解决“。

详细的解决方案，我们在后续的文章中会详细加以讲述。

2.2.4关闭bug当研发人员解决了bug之后，bug会重新指派到bug的创建者头上。

这时候测试人员可以来验证这个bug是否已经修复。

如果验证通过，则可以关闭该bug。

三、进阶使用说明3.1使用流程3.1.1 禅道使用流程图解在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。

如果您现在的团队是采用敏捷开发的话，那么可以对应到productowner, scrum master和team(dev and tester)。

这几种角色之间紧紧围绕产品的需求展开协作，取得成果。

禅道核心的管理流程全图如下所示：3.2产品经理篇3.2.1 维护产品产品管理对于公司来讲，至关重要。

只有做出好的产品或者服务出来，才能赢得市场，谋求发展和生存。

所以产品经理的这个位子对于公司来讲，是非常关键的，相当于公司的大脑，在决定着公司前进的方向。

在禅道里面，产品和项目这两个概念被明确的区分开来。

产品是需求方，决定做什么。

项目是执行方，解决的是如何做的问题。

而测试则是保障方，解决的是正确的做事情的问题。

所以在禅道中，所有的一切都是围绕产品展开的。

产品是整个项目管理活动的核心。

3.2.1.1创建产品1)用产品经理的角色登录禅道。

2)进入产品视图，然后点击页面右侧的“新增产品”链接，即可出现新增产品的页面。

3)如果系统中还没有添加产品，系统也会自动跳转到产品的添加页面。

添加产品时需要注意的地方：•产品代号相当于大家对这个产品的一个隐喻，比如禅道项目管理软件的代码是zentao。

•产品负责人负责整理和解释整个产品的需求，制定相应的发布计划。

•测试负责人，可以指定默认的测试负责人。

这样可以适用于公司人比较多，提交bug不知道该给谁的情况。

•发布负责人主要的职责是创建发布。

•访问控制，则可以控制访问该产品的人员列表。

比如可以将某一个产品设为私有，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才可以访问。

我们产品经理可能都习惯了写需求设计文档，或者规格说明书，通过一个非常完整的word文档将某一个产品的需求都定义出来。

但在禅道里面，我们提倡按照功能点的方式来写需求。

简单来讲，就是将原来需求设计文档中的每一个功能点摘出来，录在禅道里面，作为一个个独立的功能点。

如果按照scrum标准走的话，我们可以称之为用户故事(user story)。

所谓用户故事，就是来描述一件事情，作为什么用户，希望如何，这样做的目的或者价值何在，这样有用户角色，有行为，也有目的和价值所在，非常方便与团队成员进行沟通。

3.2.2 创建和评审需求3.2.2.1创建需求1)使用产品经理角色登录系统。

2)进入产品视图。

3)在页面右侧，有“新增需求”菜单，点击菜单，出现新增需求的页面。

4)o需求的标题是必填项。

o所属计划和模块，可以暂时保留为空。

o需求审核那块，我们选上不需要审核，这样新创建的需求状态就是激活的。

只有激活状态的需求才能关联到项目中，进行开发。

o需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。

o可以设置关键词，这样可以比较方便的通过关键词进行检索。

3.2.2.2评审需求在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建是激活中的。

但大部分情况下面，需求还是需要评审的。

即使产品完全有一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。

新增需求的评审流程如下：下面我们来看下具体的需求评审页面：•评审结果可以选择确认通过、有待明确、拒绝等操作。

如果选择“确认通过”，则需求的状态改为“激活中”，然后就可以关联到项目中进行开发了。

•如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，有其继续进行完善。

•如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：••由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。

一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。

3.2.3 变更和评审需求变更是需求管理必不可少的流程，禅道项目管理软件对需求的变更提供了全面的支持。

其实需求的变更并不可怕，但不清楚影响范围的变更是很可怕的。

在传统项目管理中，由于没有有力工具的支撑，产品经理在变更需求的时候，无法知晓该需求的影响范围，会有很大的随意性。

禅道项目管理软件将需求、任务、bug和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给产品经理更好的指导。

禅道里面需求变更的基本流程如下：下面我们来看下具体的操作：3.2.3.1变更需求禅道专门提供了需求的变更流程。

凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。

变更之后的需求状态为变更中。

•编辑操作是无法修改需求的标题、描述、验收标准和附件的。

•在变更需求的时候，如果选择了“不需要评审”，则需求状态自动变成激活，不需要再走评审流程。

•在变更需求的时候，会列出该需求的影响范围：3.2.3.2评审需求1)通过需求的详情页面查看变更前后的变化2)评审需求，给出评审结果•评审结果可以选择确认通过，撤销变更，有待明确或者拒绝。

如果选择确认通过，则需求的状态从“已变更”变为“激活中”。

•如果选择撤销变更，则取消当前的变更，并回退到之前的版本。

•如果选择有待明确，需求被打回到需求的变更者，继续进行完善。

•如果选择拒绝，则需要给出相应的拒绝原因。

•同样在评审需求的时候，也会列出相应的影响范围，评审者可以参考。

3.2.3.3确认需求变更当需求变更被确认之后，研发团队和测试人员需要确认需求的变更。

1)任务确认需求变动：2)缺陷确认需求变动3)用例确认需求变动3.2.4 需求的状态和研发阶段禅道软件设计的需求有两个字段来跟踪它的变化，一个是需求的状态字段，一个是需求的研发阶段字段，下面来看下这两个字段。

3.2.4.1需求的状态需求状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。