禅道使用说明.docx
《禅道使用说明.docx》由会员分享，可在线阅读，更多相关《禅道使用说明.docx（25页珍藏版）》请在冰点文库上搜索。
禅道使用说明
禅道使用说明
禅道是第一款国产的优秀开源项目管理软件。
它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。
先进的管理思想，合理的软件架构，简洁实效的操作，优雅的代码实现，灵活的扩展机制，强大而易用的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,scrummaster和team（devandtester）。
这几种角色之间紧紧围绕产品的需求展开协作，取得成果。
禅道核心的管理流程全图如下所示：
3.2产品经理篇
3.2.1维护产品
产品管理对于公司来讲，至关重要。
只有做出好的产品或者服务出来，才能赢得市场，谋求发展和生存。
所以产品经理的这个位子对于公司来讲，是非常关键的，相当于公司的大脑，在决定着公司前进的方向。
在禅道里面，产品和项目这两个概念被明确的区分开来。
产品是需求方，决定做什么。
项目是执行方，解决的是如何做的问题。
而测试则是保障方，解决的是正确的做事情的问题。
所以在禅道中，所有的一切都是围绕产品展开的。
产品是整个项目管理活动的核心。
创建产品
1）用产品经理的角色登录禅道。
2）进入产品视图，然后点击页面右侧的“新增产品”链接，即可出现新增产品的页面。
3）如果系统中还没有添加产品，系统也会自动跳转到产品的添加页面。
添加产品时需要注意的地方：
∙产品代号相当于大家对这个产品的一个隐喻，比如禅道项目管理软件的代码是zentao。
∙产品负责人负责整理和解释整个产品的需求，制定相应的发布计划。
∙测试负责人，可以指定默认的测试负责人。
这样可以适用于公司人比较多，提交bug不知道该给谁的情况。
∙发布负责人主要的职责是创建发布。
∙访问控制，则可以控制访问该产品的人员列表。
比如可以将某一个产品设为私有，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才可以访问。
我们产品经理可能都习惯了写需求设计文档，或者规格说明书，通过一个非常完整的word文档将某一个产品的需求都定义出来。
但在禅道里面，我们提倡按照功能点的方式来写需求。
简单来讲，就是将原来需求设计文档中的每一个功能点摘出来，录在禅道里面，作为一个个独立的功能点。
如果按照scrum标准走的话，我们可以称之为用户故事（userstory）。
所谓用户故事，就是来描述一件事情，作为什么用户，希望如何，这样做的目的或者价值何在，这样有用户角色，有行为，也有目的和价值所在，非常方便与团队成员进行沟通。
3.2.2创建和评审需求
创建需求
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需求的状态和研发阶段
禅道软件设计的需求有两个字段来跟踪它的变化，一个是需求的状态字段，一个是需求的研发阶段字段，下面来看下这两个字段。
需求的状态
需求状态（status）字段，总共有四种状态，分别是草稿（draft）、激活（active）、已变更（changed）和已关闭（closed）。
对应为需求的流程操作共有：
创建、变更、审核、关闭、激活，其状态流转图如下：
需求的研发阶段
需求还有一个阶段（stage）字段，用来描述激活的需求在研发过程中所处的阶段。
目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。
那么需求的研发阶段是如何变化的呢？
一种方案是通过编辑操作，来修改研发阶段。
但我们更提倡另外一种方案，就是在创建任务的时候，仔细设置任务的类型，比如开发，测试。
禅道的程序会自动根据不同类型任务的变化来自动计算需求的研发阶段，其规则如下：
1）如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是"等待"。
2）如果需求关联到了计划，还没有关联到项目中，则需求的研发阶段是"已计划"。
3）如果需求关联到了项目中，但还没有分解任务，则需求的研发阶段是"已立项"。
4）如果需求关联到了项目中，且进行了任务分解:
如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段为“研发中”。
如果所有的开发任务已经完成，并且所有的测试任务还没有开始，则为“研发完毕”。
如果有一个测试任务进行中，则视为“测试中”。
如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为"测试中"。
如果所有的测试任务已经结束，并且所有的开发任务已经结束，则视为"测试完毕"。
5）"验收"阶段是需要产品经理手工来进行确认的。
6）如果需求关闭，且关闭原因是“已发布”，则需求的研发阶段是“已发布”。
3.2.5建立发布计划
古人云，凡事预则立，不预则废。
产品需要做规划，才能有轻重缓急，才能正确的做事。
因此对于产品经理而言，计划是必需的。
∙对于产品经理自己而言，发布计划可以帮助他规划产品，制定发布的节奏，调整需求的优先级。
∙对于公司其他部门的同事以及外部的客户而言，发布计划可以让他们知晓产品的进展情况，以便做好相应的安排。
∙同时在项目关联需求的时候，计划可以帮助需求的关联。
创建计划
1）进入产品视图，选择某一个产品。
2）点击“计划列表”
3）出现计划列表页面，点击页面右侧的“创建计划”，即可出现计划增加页面。
关联需求
创建完计划之后，可以为计划关联需求
也可以在添加需求的时候指定计划（已经过期的计划不会列出）
计划和项目之间的关系
禅道软件中并没有对计划和项目并没有非常强的对应关系。
如果某一个开发团队的计划和执行都非常好，那么一个计划可以对应一个项目。
但这是非常理想的状态。
一般情况下面是这样，在项目关联需求的时候，大部分的需求都关联自一个计划，但同时也关联了其他计划的部分需求。
3.2.6建立发布
项目结束后产品人员的一个工作就是创建发布，通过创建发布，可以告诉公司其他相关的部门，他们可以在新版本产品的基础上开展工作。
同时也是鼓舞团队士气非常好的一个手段。
3.2.6.1创建发布的前提
创建发布有两个前提：
1）该产品有关联过项目。
2）该项目有创建过版本。
3.2.6.2如何创建发布
1）进入产品视图，选择发布列表。
2）然后点击“创建发布”，即可出现创建发布的页面。
∙选择了版本之后，系统会自动计算这个版本所对应的项目中完成的需求和解决的bug，可以进行关联选择。
∙如果系统自动计算的需求和bug不完整，可以在描述字段里面补充。
5.2.7文档管理
禅道软件内置了基本的文档管理功能，这样禅道没有覆盖到的流程就可以通过文档管理功能来补充。
禅道文档库共分为三种类型：
产品文档库、项目文档库和自定义文档库。
其中产品文档库用来存储产品层面产生的文档，项目文档库用来存储项目过程中产生的文档。
自定义文档库则可以用来存储知识库、公司管理规范等文档。
下面让我们来看下具体的操作。
维护分类
1）进入文档视图。
2）选择产品文档库。
3）然后选择页面下方的“维护分类”链接，即可出现维护分类的的页面。
4）
5）
6）
添加文档
在产品视图，点击页面右侧的“创建文档”，即可进入文档的创建页面。
∙文档共有文件、链接和网页三种类型。
∙文件类型的文档可以上传一个附件。
∙链接类型的文档可以是一个网页链接。
∙网页型的文档可以直接使用富文本编辑器撰写。
浏览文档
文档添加之后，可以在文档库里面查看相应的文档列表。
也可以在产品视图的文档库里面查看这个产品下面的所有文档。
3.3项目经理篇
3.3.1建立项目
创建项目
1）进入项目视图，点击右侧的”新增项目“链接。
2）出现项目添加的页面
在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标和项目描述等字段。
其中关联产品是可以为空的。
注意事项：
1.项目代号是一种隐喻，也就是团队内部可以互相了解和知晓，比如禅道项目曾经使用过“opensesame"来作为项目的代号。
2.团队名称，可以自己定义，比如叫做“禅道开发团队”等等。
3.在添加项目的时候，可以选择关联与之相关的产品，以便后续进行需求的关联。
4.项目可以控制它的访问权限，分为默认、私有和自定义白名单三种。
3.3.2组建项目团队
项目组建之后要做的事情就是设置团队。
很多朋友经常问，为什么我在创建任务的时候，只能指派给自己呢？
其实原因很简单，是因为没有设置团队。
当项目创建成功之后，可以根据提示设置团队。
或者从项目视图中的团队菜单，也可以进行项目的团队管理。
在维护项目团队的时候，需要选择都是哪些用户可以参与到这个项目中，同时需要设置这个用户在本项目中的角色（角色可以随便设置，比如风清扬，冬瓜一号等）。
可用工作日和可用工时每天需要仔细设置。
通常来讲，一个人不可能每天8小时投入，也不可能一星期七天连续投入。
设置完毕之后，系统会自动计算这个项目总得可用工时。
当团队设置完毕之后，整个项目的可用资源就已经确定了：
起止时间确定了，参与的人员也确定了。
下面就是来确定项目中要做的事情了。
3.3.3确定项目要完成的需求列表
项目团队组建完毕之后，接下来要做的一个工作就是确定这期项目要做的需求。
这项任务其实是整个团队，包括产品在内，共同完成的。
3.3.3.1关联产品
如果在创建项目的时候，已经关联过产品，可以忽略这个步骤。
1）以项目经理身份登录。
2）进入项目视图。
3）点击“关联产品”按钮。
然后点选该项目相关的产品即可。
4）
3.3.3.2关联需求
1）在关联需求的时候，可以按照优先级进行排序。
2）关联的需求状态必须是激活的（评审通过，不能是草稿）
3.3.4组织进行任务分解
需求确定之后，项目中几个关键的因素都有了：
周期确定、资源确定、需求确定。
下面我们要做的事情就是为每一个需求做wbs任务分解，生成完成这个需求的所有的任务。
3.3.4.1访问项目的需求列表页面：
∙在项目的需求列表页面，可以很方便地对某一个需求进行任务分解。
∙同时还可以查看这个需求已经分解的任务数。
3.3.4.2分解任务
∙这时候创建任务的时候，就可以选择需求了。
∙我们同时提供了需求查看的链接。
∙如果需求和任务的标题是一样的，可以通过”同需求“按钮快捷的复制需求的标题。
3.3.4.3任务分解的几个注意事项
1）需要将所有的任务都分解出来。
这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等。
2）任务分解的粒度越小越好，比如几个小时就可以完成。
3）如果一个任务需要多个人负责，继续考虑将其拆分。
4）事务型的事务可以批量指派，比如需要让团队里面的每一个人都写个项目总结，可以选择类型是事务，然后批量指派给团队里面的所有人员。
5）任务的类型请仔细设置，这个会涉及到需求研发阶段的自动计算。
后面我们会有讲解。
6）任务的分配最好是自由领取，这样可以最大程度上调动大家的积极性。
7）任务的分解最好是由团队共同完成，不要由项目经理一人包办。
3.4开发团队篇
3.4.1领取任务，并每天更新任务
当项目的任务分解完毕之后，项目团队成员需要领取自己喜欢做的任务，开始每天的开发。
除了日常的编码工作之外，还应当每天花点时间在禅道里面更新下任务的状态以及消耗情况。
3.4.1.1领取任务
领取任务可以通过两种方式，一种是通过“指派”操作，一种是通过“编辑”操作。
3.4.1.2更新任务状态
项目开始之后，每个人每天应当及时更新自己所负责的任务的状态。
禅道提供了几个快捷的操作按钮：
开始、完成、关闭、取消和激活。
开始、完成和取消没有什么歧义。
解释下关闭和激活。
禅道有一个可选流程，就是当任务完成之后，会自动指派回任务的创建者头上，这时候任务的创建者可以验证任务是否完成。
如果完成，则将任务关闭。
如果任务没有完成，则激活任务。
这个流程是可选的，不是必须的流程。
适用于传统的命令-控制式的管理。
如果对于敏捷开发团队来讲，忽略这个流程即可。
3.4.1.3更新任务的消耗
除了更新自己负责任务的状态之外，还应该及时更新任务的工时消耗情况：
最初预计，即创建任务的时候的最初预计。
该字段在任务开始之后，不应该再进行修改。
这个字段当任务结束之后，可以和已经消耗字段进行对比，以纠正自己的估计。
已经消耗，则是你在这个任务上所有花费的工时数。
预计剩余，则是你预计这个任务完成大约还需要多少时间。
如果预计剩余为0，则表示任务完成。
这里面需要特别强调的是，最初预计≠已经消耗+预计剩余。
一定要每天更新自己所负责的任务，因为燃尽图的绘制，就是通过预计剩余这个字段来计算的。
3.4.2创建版本
当完成若干功能之后，就可以创建版本了。
版本的概念在英文里面是build，可以对应到软件配置管理的范畴。
这是一个可选流程，但还是建议团队能够实施版本管理。
这个版本主要的作用在于明确测试的范畴，方便测试人员和开发人员的互动，以及解决不同版本的发布和bug修复等问题。
流程如下：
1）首先是团队经过开发，完成了若干需求，或者解决了一些bug。
2）这时候某一位发布负责人在subversion中创建了一个tag（标签），比如禅道的tag目录如下：
3）创建了tag之后，这位发布负责人就可以在禅道里面创建一个版本了。
4）
说明：
1）名称编号，团队应该有自己的配置管理规范。
比如可以是产品名_版本号_状态（stble,beta之类）_日期
2）不同开发语言其版本的存在形式也不同，有的需要编译，有的只需要源代码。
请根据公司的实际情况来填写源代码地址，或者是存储地址。
3）在创建版本的时候，可选择这次版本完成的功能和解决的bug。
这样提交给测试人员进行测试的时候，就可以明确这次测试的范畴，测试可以更加有针对性。
4）描述字段可以填写一些测试的注意事项、重点内容等。
3.4.3申请测试
当版本创建完毕之后，就可以提交给测试人员进行测试了，提交测试会生成一个测试任务。
在这儿需要和大家解释下这个测试任务的概念。
其实英文里面里面比较合适的单位是testrun，但翻译到中文里面没有太贴切的词语，我们暂时用了测试任务的概念。
但这个测试任务和项目里面创建的类型为“测试”的任务没有直接关联。
请大家在使用的时候，注意这个细节。
一般来讲，我们在分解任务的时候，可以创建若干测试类型的任务，比如测试某某，测试某某，大概估计下测试需要的时间。
然后具体的测试工作通过测试视图的测试任务来跟踪。
申请测试的步骤：
1）进入项目视图，点击“测试申请”。
2）然后选择“提交测试”，即可出现提交测试的页面。
说明：
1）负责人为本次测试的负责人。
2）可以指定这次测试预计起止的时间。
3）任务描述里面，可以注明此次测试需要注意的地方。
4）还需要说明的一点是，目前测试任务还没有指派的功能，所以需要大家线下通知测试团队的负责人，由他来负责组织相应人员来进行测试。
3.4.4解决bug
提交测试之后，测试人员展开测试，便会有bug产生。
这时候研发团队的一个重要职责便是解决bug。
禅道里面bug的处理流程比较简单：
测试人员提交bug=>开发人员解决bug=>测试人员验证关闭，这是比较正常的流程。
还有一个流程是激活流程：
测试人员提交bug=>开发人员解决bug=>测试人员验证未通过=>激活bug=>重新解决=>验证关闭。
开发人员所需要做的事情便是处理自己负责bug，并在禅道中登记解决方案：
1）项目视图中的bug列表
2）bug的详情页面也可以找到“解决”操作的按钮
升级会员 