禅道使用手册22020年4月19日文档仅供参考禅道使用说明禅道是第一款国产的优秀开源项目管理软件它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程先进的管理思想，合理的软件架构，简洁实效的操作，优雅的代码实现，灵活的扩展机制，强大而易用的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指派给某一位研发人员之后，她能够来验证解决这个bug1) 经过各种标签和检索条件找到需要自己处理的bug在对bug进行出来之前，需要先要找到需要自己处理的bug禅道提供了各种各样的检索方式，比如指派给我，能够列出所有需要我处理的bug1) 解决bug研发人员解决bug，选择解决方案，一般来讲有效的解决bug方案是”已解决“详细的解决方案，我们在后续的文章中会详细加以讲述2.2.4关闭bug当研发人员解决了bug之后，bug会重新指派到bug的创立者头上这时候测试人员能够来验证这个bug是否已经修复如果验证经过，则能够关闭该bug三、 进阶使用说明3.1使用流程3.1.1 禅道使用流程图解在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。
如果您现在的团队是采用敏捷开发的话，那么能够对应到product owner, 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) 在页面右侧，有“新增需求”菜单，点击菜单，出现新增需求的页面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)对应为需求的流程操作共有：创立、变更、审核、关闭、激活，其状态流转图如下：3.2.4.2需求的研发阶段 需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段当前总共有。