3.禅道进阶使用
3.1.使用流程
在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。如果您现在的团队是采用敏捷开发的话，那么可以对应到product owner, scrum master和team(dev and tester)。这几种角色之间紧紧围绕产品的需求展开协作，取得成果。禅道核心的管理流程全图如下所示：
3.2.个人管理
3.2.1. 使用待办进行个人事务管理
禅道设计的目标是团队协作工具，但其实个人使用禅道也可以派上很大的用场。笔者在开发禅道过程中，从2009年10月开始，用禅道来管理禅道本身的项目管理，那时候禅道的开发团队只有笔者光杆司令一人，后来和朋友们聊起，戏称一个人的项目管理。
下面让我们来展示下如何使用禅道来进行个人的事务管理。
3.2.1.1.创建待办
- 新增待办的时候，可以设定起止时间。也可以选择暂时不设定。
- 如果是私人事务，可以勾选上。
3.2.1.2.浏览待办
禅道提供了各种标签来检索待办信息。
其实个人使用禅道，还可以借鉴项目管理的概念，把自己要处理的事情放在项目里面进行跟踪管理，也是非常方便的。比如买房，考研，复习考试等等。
3.2.2. 关注需要自己处理的任务、需求、bug
禅道在我的地盘中提供了指派给自己的需求，任务，bug等快捷操作。凡是指派给自己的这些事项，都是需要及时处理的。因此对于每一位使用禅道的朋友来讲，每天的工作其实也很简单，就是将我的地盘中指派给自己的任务、需求或者bug及时处理掉就可以了。
3.2.2.1.我的任务
3.2.2.2.我的bug
3.2.2.3.我的需求
3.2.2.4.我的测试
3.2.3. 通过我的档案查看或修改个人信息
在我的地盘中还有我的档案一个页面，在这个页面可以查看或者修改自己的个人信息，包括修改密码功能。
3.2.3.1.查看个人信息
备注：
源代码提交帐号是该用户在subversion系统中的提交帐号，主要用来做对照使用。如果没有使用subversion集成功能，将这个字段保留为空即可。
3.2.3.2.修改密码
3.3.产品经理篇
3.3.1. 维护产品
产品管理对于公司来讲，至关重要。只有做出好的产品或者服务出来，才能赢得市场，谋求发展和生存。所以产品经理的这个位子对于公司来讲，是非常关键的，相当于公司的大脑，在决定着公司前进的方向。在禅道里面，产品和项目这两个概念被明确的区分开来。产品是需求方，决定做什么。项目是执行方，解决的是如何做的问题。而测试则是保障方，解决的是正确的做事情的问题。所以在禅道中，所有的一切都是围绕产品展开的。产品是整个项目管理活动的核心。
3.3.1.1.创建产品
- 用产品经理的角色登录禅道。
- 进入产品视图，然后点击页面右侧的“添加产品”链接，即可出现新增产品的页面。
- 如果系统中还没有添加产品，系统也会自动跳转到产品的添加页面。
添加产品时需要注意的地方：
- 产品代号相当于大家对这个产品的一个隐喻，比如禅道项目管理软件的代码是zentao。
- 产品负责人负责整理和解释整个产品的需求，制定相应的发布计划。
- 测试负责人，可以指定默认的测试负责人。这样可以适用于公司人比较多，提交bug不知道该给谁的情况。
- 发布负责人主要的职责是创建发布。
- 访问控制，则可以控制访问该产品的人员列表。比如可以将某一个产品设为私有，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才可以访问。
3.3.1.2.产品多分支和多平台功能
禅道7.4.beta版本开始，产品新增多分支和多平台功能。多分支和多平台功能使得产品的管理开发更加的清晰明了，非常适合一个产品拥有多个平台和多个分支的管理，这样需求明确的划分到某个平台和分支上，项目关联开发是就一目了然。多分支可以用于某个产品有定制开发的需求，比如某个产品针对不同的行业或者不同的客户有做二次开发，可以用产品的多分支来做区别管理。
下面给大家具体介绍产品多平台功能。多分支的操作与多平台是一样的，可以直接参考。
新增产品时，可以在产品类型里选择多分支和多平台。
产品创建成功后，产品页面下会显示多平台以及维护平台的菜单。
点击 平台 菜单，即可维护平台，右侧可以做添加平台。
平台添加成功后，在提需求页面，所属产品后可以选择所属平台。
需求创建成功后，在产品→需求页面，需求名称前就会显示所属平台的名称。
如果需求属于所有平台，那么需求名称前默认不显示所属平台名称。
在项目→产品关联产品页面时，同时可以选择关联的产品以及所属平台。
选择了所属平台后，项目→需求关联需求时，可以关联该产品下所有平台和项目关联的产品平台下的需求。
3.3.2. 创建和评审需求
我们产品经理可能都习惯了写需求设计文档，或者规格说明书，通过一个非常完整的word文档将某一个产品的需求都定义出来。但在禅道里面，我们提倡 按照功能点的方式来写需求。简单来讲，就是将原来需求设计文档中的每一个功能点摘出来，录在禅道里面，作为一个个独立的功能点。如果按照scrum标准走 的话，我们可以称之为用户故事(user story)。所谓用户故事，就是来描述一件事情，作为什么用户，希望如何，这样做的目的或者价值何在，这样有用户角色，有行为，也有目的和价值所在，非常方便与团队成员进行沟通。
3.3.2.1.创建需求
- 使用产品经理角色登录系统。
- 进入产品视图。
- 在页面右侧，有“提需求”菜单，点击菜单，出现新增需求的页面。
- 需求的标题是必填项。
- 所属计划和模块，可以暂时保留为空。
- 需求审核那块，我们选上不需要审核，这样新创建的需求状态就是激活的。只有激活状态的需求才能关联到项目中，进行开发。
- 需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。
- 可以设置关键词，这样可以比较方便的通过关键词进行检索。
3.3.2.2.评审需求
在创建需求的时候，有一个“不需要评审”的复选框，如果选中该复选框的话，需求的创建是激活中的。但大部分情况下面，需求还是需要评审的。即使产品完全有一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增需求的评审流程如下：
下面我们来看下具体的需求评审页面：
- 评审结果可以选择确认通过、有待明确、拒绝等操作。如果选择“确认通过”，则需求的状态改为“激活中”，然后就可以关联到项目中进行开发了。
- 如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，有其继续进行完善。
- 如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：
- 由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。
3.3.3. 变更和评审需求
变更是需求管理必不可少的流程，禅道项目管理软件对需求的变更提供了全面的支持。其实需求的变更并不可怕，但不清楚影响范围的变更是很可怕的。在传统项目管理中，由于没有有力工具的支撑，产品经理在变更需求的时候，无法知晓该需求的影响范围，会有很大的随意性。禅道项目管理软件将需求、任务、bug和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给产品经理更好的指导。
禅道里面需求变更的基本流程如下：
下面我们来看下具体的操作：
3.3.3.1.变更需求
禅道专门提供了需求的变更流程。凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。变更之后的需求状态为变更中。
- 编辑操作是无法修改需求的标题、描述、验收标准和附件的。
- 在变更需求的时候，如果选择了“不需要评审”，则需求状态自动变成激活，不需要再走评审流程。
- 在变更需求的时候，会列出该需求的影响范围：
3.3.3.2.评审需求
1. 通过需求的详情页面查看变更前后的变化
2. 评审需求，给出评审结果
- 评审结果可以选择确认通过，撤销变更，有待明确或者拒绝。如果选择确认通过，则需求的状态从“已变更”变为“激活中”。
- 如果选择撤销变更，则取消当前的变更，并回退到之前的版本。
- 如果选择有待明确，需求被打回到需求的变更者，继续进行完善。
- 如果选择拒绝，则需要给出相应的拒绝原因。
- 同样在评审需求的时候，也会列出相应的影响范围，评审者可以参考。
3.3.3.3.确认需求变更
当需求变更被确认之后，研发团队和测试人员需要确认需求的变更。
1. 任务确认需求变动
2. Bug确认需求变动
3. 用例确认需求变动
3.3.4. 需求的状态和研发阶段
禅道软件设计的需求有两个字段来跟踪它的变化，一个是需求的状态字段，一个是需求的研发阶段字段，下面来看下这两个字段。
3.3.4.1.需求的状态
需求状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活，其状态流转图如下：
3.3.4.2.需求的研发阶段
需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。
那么需求的研发阶段是如何变化的呢？一种方案是通过编辑操作，来修改研发阶段。但我们更提倡另外一种方案，就是在创建任务的时候，仔细设置任务的类型，比如开发，测试。禅道的程序会自动根据不同类型任务的变化来自动计算需求的研发阶段，其规则如下：
- 如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是"未开始"。
- 如果需求关联到了计划，还没有关联到项目中，则需求的研发阶段是"已计划"。
- 如果需求关联到了项目中，但还没有分解任务，则需求的研发阶段是"已立项"。
- 如果需求关联到了项目中，且进行了任务分解:
如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段为“研发中”。
如果所有的开发任务已经完成，并且所有的测试任务还没有开始，则为“研发完毕”。
如果有一个测试任务进行中，则视为“测试中”。
如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为"测试中"。
如果所有的测试任务已经结束，并且所有的开发任务已经结束，则视为"测试完毕"。 - "验收"阶段是需要产品经理手工来进行确认的。
- 产品→发布中关联的需求后，需求的研发阶段是“已发布”。
需求所属产品为多分支或多平台类型的所处阶段说明：
以多平台为例，该产品有安卓、ios两个平台。
（1）如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是“未开始”。
（2）如果需求属于所有平台，关联的计划也属于所有平台，则需求的阶段为“所有平台：已计划”。如果计划属于ios平台，则需求的阶段为“ios：已计划”。如果需求属于某个特定平台，阶段计算方式等同原来的普通产品的情况。
（3）如果项目关联的是产品的某个平台，假如关联了ios平台，同时关联了产品所有平台下和ios平台下的需求，没有分解任务。则ios平台下的需求此时阶段都是“已立项”，所有平台的需求则是“ios：已立项”。假如该需求所有平台还是“已计划”，则显示“所有平台：已计划”“ios：已立项”。
如果一个需求同时被两个项目关联，而两个项目，一个关联了产品的ios平台，一个关联了所有平台。同时都没有分解任务，那么这个需求的阶段就是“所有平台：已立项”“ios：已立项”。
注：禅道7.2.stable版本开始，可以编辑需求手动更改需求的所处阶段。
点击需求标题，进入需求详情页面，点击编辑需求，在页面的右侧显示需求的基本信息，需求所处阶段一栏点击下拉选中你要修改的需求所处阶段，保存即可。
再回到产品---需求列表页面，就可以看到需求的所处阶段已经由已立项变为测试中了。
3.3.5. 需求的注意事项
3.3.5.1.禅道中需求的写法
在禅道中，我们默认给大家提供了一个需求的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。这个模板是借鉴自scrum开发里面的用户故事(user story)的写法。只不过我们使用了相对比较中性的概念。
在这个模板中，总共有三个元素：角色，要做的事情，价值或者原因。我们平时在写需求的时候，往往会忽略角色和价值原因这两个元素，只关注了要做的事情。其实这有很多的问题。不进行用户角色的划分，会影响对产品功能的设计和定位，从而导致产品往往是给一个用户角色开发的，就是产品经理自己。:)而忽略开发的原因或者价值，会让开发人员感到困惑。他们可能并不理解你这样做的原因或者目的，不理解的需求实现起来自然会有问题。
3.3.5.2.需求的INVEST原则
除了上面基本的模板之外，在撰写用户故事的时候，可以参考INVEST原则：(摘自http://duweizhong.blogbus.com/logs/112151436.html)
- I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。
- N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。
- V aluable(有价值的):每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
- S mall(短小):一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。
- T estable(可测试的) :一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。
3.3.5.3.禅道里面的需求和原型图、需求设计文档的区别
传统管理模式中，很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后，交给设计人员进行页面设计，然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢？
- 和user story相比，原型图或者需求设计文档是一个整体，可以给人宏观的把握。这是原型图的优点。比较直观。
- 它是一个整体，所以就没有办法进行分解。你不可能分解成，做页面导航条，做页面的中间部分等。
- 没有分解，所以原型图也就没有办法进行优先级的排序。比如页面部分，有的很重要，有的不重要。但在原型图里面是体现不出来优先级的。
- 没有分解，自然也就无法进行跟踪。你没有办法得知原型图完成了多少。
- 过于死板，给设计人员和开发人员留下的发挥的空间太少，后演变成被动执行。
- 需求设计文档规定的比较细致，会让产品经理陷入太多的细节，对整体的把握会减弱。
虽然相比较于用户故事而言，传统的原型图或者需求设计文档有一些不足，但在实际的开发过程中，二者可以相辅相成。禅道从1.2版本中，已经增加了文档库管理。可以将原型图作为设计文档，上传到某一个产品相关的文档库中，和用户故事相互配合，是一个好的方案了。
3.3.6. 维护产品模块
添加完产品之后，就需要来设置产品的模块。模块相当于对产品需求的一个分类，通过组织模块，可以让大家对产品有一个宏观的把握和认识，也方便对需求进行分类和整理。
设置模块的步骤：
- 使用产品经理角色进入产品视图。
- 选择要维护的产品。
- 点击菜单中的“模块”。
- 维护模块的时候是一级级进行维护的。比如可以选择"我的地盘"，然后维护它的子模块。
- 右侧的数字是用来排序的，可以将通过调整模块的排序字段来调整它在模块树里面的位置。
- 可以选择某一个模块编辑，编辑的时候可以修改它所属的上级模块。
产品模块同步显示的问题：
禅道从5.2.1版本开始，产品的模块可以同步到项目任务、测试Bug和用例里。
项目任务、测试Bug和用例也可以单独维护自己的模块。需要注意的是产品模块同步到项目任务里是有条件的。
项目→任务里显示模块的规则：
1、项目中关联的需求在产品中的模块。比如产品模块A下面有4个需求，项目都没有关联，那么在项目中是不会显示模块A的，只要关联了4个需求中的任何一个及以上，项目模块就可以显示模块A。
2、创建任务的时候可以选择产品的某个模块（即使没有关联该模块下面的需求创建任务的时候也可以关联），创建任务后也会显示出该模块。
3、项目也可以维护自己的模块：项目→任务页面 左侧点击维护模块，可以添加维护项目自己的模块。
最新版本禅道，新增了列表页显示模块名的功能。（如果添加模块时有填写模块简称，那么就显示模块名简称。）
产品需求列表页面左侧的模块显示栏下有“列表页是否显示模块名”的编辑按钮。
禅道里默认列表页不显示模块名，点击进入选择框，选择只显示一级模块。
保存成功后，需求的列表页的显示如下。
需求名称前显示有该需求所属模块的名称。如果该需求不属于任何模块，就不显示模块名。
还可以选择 只显示最后一级模块，点击保存。
设置成功后，在需求列表页面需求的名称前即只显示最后一级模块的名称。
3.3.7. 建立发布计划
古人云，凡事预则立，不预则废。产品需要做规划，才能有轻重缓急，才能正确的做事。因此对于产品经理而言，计划是必需的。
- 对于产品经理自己而言，发布计划可以帮助他规划产品，制定发布的节奏，调整需求的优先级。
- 对于公司其他部门的同事以及外部的客户而言，发布计划可以让他们知晓产品的进展情况，以便做好相应的安排。
- 同时在项目关联需求的时候，计划可以帮助需求的关联。
3.3.7.1.创建计划
- 进入产品视图，选择某一个产品。
- 点击“计划列表”
- 出现计划列表页面，点击页面右侧的“创建计划”，即可出现计划增加页面。
3.3.7.2.关联需求
创建完计划之后，可以为计划关联需求
也可以在添加需求的时候指定计划(已经过期的计划不会列出)
3.3.7.3.计划和项目之间的关系
禅道软件中计划和项目并没有非常强的对应关系。如果某一个开发团队的计划和执行都非常好，那么一个计划可以对应一个项目。但这是非常理想的状态。一般情况下面是这样，在项目关联需求的时候，大部分的需求都关联自一个计划，但同时也关联了其他计划的部分需求。
3.3.8. 建立发布
项目结束后产品人员的一个工作就是创建发布，通过创建发布，可以告诉公司其他相关的部门，他们可以在新版本产品的基础上开展工作。同时也是鼓舞团队士气非常好的一个手段。
3.3.8.1.创建发布的前提
创建发布有两个前提：
- 该产品有关联过项目。
- 该项目有创建过版本。可以参考http://www.zentao.net/help-read-79213.html
3.3.8.2.如何创建发布
- 进入产品视图，选择发布列表。
- 然后点击“创建发布”，即可出现创建发布的页面。
- 如果产品是有多分支/多平台的，可以选择在哪个分支/平台下创建发布。
如果是没有使用多分支/多平台的，可以忽略上面的操作，直接点击右上角的“创建发布”操作。
创建成功后，即可关联需求和Bug。
- 选择了版本之后，系统会自动计算这个版本所对应的项目中完成的需求和解决的bug，可以进行关联选择。
- 如果系统自动计算的需求和bug不完整，可以在描述字段里面补充。
禅道7.4.beta版本开始，新增了发布的停止维护功能。
在产品--发布列表页面，右侧的操作按钮有停止维护按钮，点击操作即可。
停止维护的发布版本，在禅道系统里是默认不显示了的。
3.3.9. 路线图
禅道软件中，计划和发布组成了产品的路线图，通过路线图可以非常直观的了解产品过去发布过的版本和将来的计划。如下图，绿色的部分代表了发布过的版本，黄绿色的部分代表了将来的计划。点击某一个发布或者计划，可以查看其具体的需求信息。
3.3.10. 文档管理
禅道软件内置了基本的文档管理功能，这样禅道没有覆盖到的流程就可以通过文档管理功能来补充。禅道文档库共分为三种类型：产品文档库、项目文档库和自定义文档库。其中产品文档库用来存储产品层面产生的文档，项目文档库用来存储项目过程中产生的文档。自定义文档库则可以用来存储知识库、公司管理规范等文档。下面让我们来看下具体的操作。
3.3.10.1.维护分类
- 进入文档视图。
- 选择产品文档库。
- 然后选择页面下方的“维护分类”链接，即可出现维护分类的的页面。
3.3.10.2.添加文档
在产品视图，点击页面右侧的“创建文档”，即可进入文档的创建页面。
- 文档共有文件、链接和网页三种类型。
- 文件类型的文档可以上传一个附件。
- 链接类型的文档可以是一个网页链接。
- 网页型的文档可以直接使用富文本编辑器撰写。
3.3.10.3.浏览文档
文档添加之后，可以在文档库里面查看相应的文档列表。
也可以在产品视图的文档库里面查看这个产品下面的所有文档。
3.3.11. 主持产品会议
按照scrum的管理流程，开发团队需要定期召开迭代计划会议。计划会议一般控制在一天之内结束，共分为两个部分。其中第一个部分主要由产品经理负责讲解需求，确定需求的优先级，决定本期项目要完成的需求列表。然后下午由研发团队对需求进行任务分解。
产品计划会议的流程如下：
- 由项目经理提前准备，告诉大家会议的具体的时间和地点。
- 产品经理可以事先对需求做一个划分，将本期项目计划要实现的需求事先关联到项目中。(如果需求太多，来不及一一讲解)
- 然后由产品经理给大家做需求的讲解，与会的成员应当认真听讲，并提出自己的意见.
- 每一个需求讲解完毕之后，大家对需求的工作量进行估计，并根据需求的工作量确定每一个需求的优先级。
- 然后按照需求优先级的高低以及工作量的大小，对关联到项目中的需求做调整：将不需要实现的移除，关联新的需求。
计划会议的产出：这个计划会议我们需要拿到的结果就是项目视图的需求列表。
计划会议对应到禅道软件就是项目的关联需求操作：
3.3.12. 参与项目管理、演示和总结
很多公司的产品经理容易犯的一个错误就是项目开始之后，找不到产品经理了。就拿笔者之前所在的公司来讲，产品经理只是在计划会议上面给我们讲解下需求，然后项目开始之后，就消失了。其实这样很不好，会造成很多的问题：
- 首先，单纯的靠文字描述和计划会议，不可能保证100%的人员100%的理解正确，很有可能会有理解偏差的情况。所以产品人员应该随时了解项目进展情况，随时发现问题，随时解决问题。
- 其次，产品经理不参与项目过程，很容易造成产品经理和开发团队的对立，不利于团队的发展。而且很容易扯皮，大家互相推诿责任。
因此，产品经理在项目开始之后，应当随时了解项目的进展情况：参与团队的例会，在禅道里面通过项目视图了解任务进展，通过bug查看缺陷情况，需求完成之后及时检查确认等等。
在项目开发完成之后，产品人员应当对本期所作的需求进行确认，以保证是自己想要的东西。同时应当积极参加团队召开的演示会议，听取大家的意见和反馈，并整理成相应的需求，录入到禅道中。
产品经理还应当积极参加项目的总结会议，吸取经验教训，调整下一步的工作。
3.3.13. 需求的基本统计报表
针对一些公司需要对产品需求进行统计的情况，禅道项目管理软件从2.0版本开始，提供了需求的基本统计报表功能。在产品视图下的需求子栏目，点击“统计报表”链接，即可根据需要进行需求的统计，包括：
1. 产品需求数量。
2. 模块需求数量。
3. 按照计划进行统计。
4. 按照状态进行统计。
5. 按照所处阶段进行统计。
6. 按照优先级进行统计。
7. 按照预计工时进行统计。
8. 按照由谁创建来进行统计。
9. 按照当前指派来进行统计。
10. 按照关闭原因来进行统计。
11. 按照变更次数来进行统计。(根据版本号来进行计算，版本号 - 1为变更次数)
3.4.项目经理篇
3.4.1. 建立项目
很多朋友使用禅道之后经常问的一个问题就是产品和项目的关系。就像前面的《禅道和scrum的对应关系》这篇文章所描述的那样，禅道里面的项目其实对应的是敏捷开发里面的迭代的概念。只不过我们为了大家更容易理解和接受，还是沿用了传统的项目的概念。
创建项目
1. 进入项目视图，点击右侧的”添加项目“链接。
2. 出现项目添加的页面
在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标和项目描述等字段。其中关联产品是可以为空的。
注意事项：
- 项目代号是一种隐喻，也就是团队内部可以互相了解和知晓，比如禅道项目曾经使用过“opensesame"来作为项目的代号。
- 团队名称，可以自己定义，比如叫做“禅道开发团队”等等。
- 在添加项目的时候，可以选择关联与之相关的产品，以便后续进行需求的关联。
- 项目可以控制它的访问权限，分为默认、私有和自定义白名单三种。
3.4.2. 组建项目团队
项目组建之后要做的事情就是设置团队。很多朋友经常问，为什么我在创建任务的时候，只能指派给自己呢？其实原因很简单，是因为没有设置团队。
当项目创建成功之后，可以根据提示设置团队。
或者从项目视图中的团队菜单，也可以进行项目的团队管理。
在维护项目团队的时候，需要选择都是哪些用户可以参与到这个项目中，同时需要设置这个用户在本项目中的角色（角色可以随便设置，比如风清扬，冬瓜一号等）。可用工作日和可用工时每天需要仔细设置。通常来讲，一个人不可能每天8小时投入，也不可能一星期七天连续投入。
设置完毕之后，系统会自动计算这个项目总得可用工时。
当团队设置完毕之后，整个项目的可用资源就已经确定了：起止时间确定了，参与的人员也确定了。下面就是来确定项目中要做的事情了。
3.4.3. 确定项目要完成的需求列表
项目团队组建完毕之后，接下来要做的一个工作就是确定这期项目要做的需求。这项任务其实是整个团队，包括产品在内，共同完成的。确定的过程应该是线下的产品计划会议，请参考：http://www.zentao.net/book/zentaopmshelp/140.html
3.4.3.1.关联产品
如果在创建项目的时候，已经关联过产品，可以忽略这个步骤。
- 以项目经理身份登录。
- 进入项目视图。
- 点击“关联产品”按钮。然后点选该项目相关的产品即可。
3.4.3.2.关联需求
- 在关联需求的时候，可以按照优先级进行排序。
- 关联的需求状态必须是激活的（评审通过，不能是草稿）
3.4.4. 组织进行任务分解
需求确定之后，项目中几个关键的因素都有了：周期确定、资源确定、需求确定。下面我们要做的事情就是为每一个需求做wbs任务分解，生成完成这个需求的所有的任务。note:是完成需求的所有任务，这里面包括但不限于设计，开发，测试等。
3.4.4.1.访问项目的需求列表页面：
- 在项目的需求列表页面，可以很方便地对某一个需求进行任务分解。
- 同时还可以查看这个需求已经分解的任务数。
3.4.4.2.分解任务
- 这时候创建任务的时候，就可以选择需求了。
- 我们同时提供了需求查看的链接。
- 如果需求和任务的标题是一样的，可以通过”同需求“按钮快捷的复制需求的标题。
3.4.4.3.任务分解的几个注意事项
- 需要将所有的任务都分解出来。这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等。
- 任务分解的粒度越小越好，比如几个小时就可以完成。
- 如果一个任务需要多个人负责，继续考虑将其拆分。
- 事务型的事务可以批量指派，比如需要让团队里面的每一个人都写个项目总结，可以选择类型是事务，然后批量指派给团队里面的所有人员。
- 任务的类型请仔细设置，这个会涉及到需求研发阶段的自动计算。后面我们会有讲解。
- 任务的分配好是自由领取，这样可以大程度上调动大家的积极性。
- 任务的分解好是由团队共同完成，不要由项目经理一人包办。
3.4.5. 召开每天的站立会议
项目任务分解完毕之后，整个项目要完成的任务也都已经确定，每个人负责的任务也确定。这时候就进入到每天的迭代过程。项目经理的一个职责就是每天负责召开站立会议。
具体的形式如下：
- 每天固定时间召开。
- 项目团队成员站立在一起开会。
- 每个人讲述三件事情：昨天做了什么，今天计划做什么。有没有什么问题。
- 会议控制在15分钟之内结束。
注意事项：
- 不要坐着开会。
- 站立会议不要试着解决问题，大家更多的是沟通互相的进度，而不是解决具体的问题。具体的问题，会后讨论。
- 控制会议时间，不要超过15分钟。
- 站立会议不是汇报会议，而是大家的沟通。及时发现问题。
- 非项目团队成员可以参加，但不能发言。
3.4.6. 通过燃尽图了解项目的进展
项目团队成员除了每天的编码工作、参加站立会议之外，还有一个工作就是在禅道里面更新自己所负责任务的状态以及它的预计剩余时间。然后禅道系统会根据项目中所有任务预计剩余的时间累加起来，绘制成燃尽图。燃尽图的英文名字叫做 burn down chart，先来看一个例子：
- 此图横轴为日期，纵轴为工时数。
- 工时数乃项目中所有任务剩余工时的总和，每天计算一下，形成坐标，然后把线连接起来，形成此燃尽图。
- 新版本的禅道，燃尽图可以设置是否显示周末，还可以修改项目首天工时。修改首天工时，需要到组织--权限里分配。
- 燃尽图的更新，需要配置定时任务，具体请参考http://www.zentao.net/help-read-79063.html
燃尽图和甘特图的区别：
禅道核心的管理理念是基于scrum的。所以它的主要工具是燃尽图，而不是甘特图。这也恰恰反映了两种截然不同的管理思路。甘特图需要严格的设置过 任务的起止时间和前置关系，是一种控制式的管理。而燃尽图则更关注于做完整体的项目还剩下多少时间。所以在我们开源版本里面我们更提倡大家用好燃尽图。
3.4.7. 通过各种列表的各种功能了解项目进展
其实做好项目管理也很简单，做到信息公开、透明，很多事情自然而然就会变得简单。除了每天召开站立会议，更新燃尽图之外，项目经理还可以通过项目的各种列表功能来掌握项目的进展情况：
3.4.7.1.首页的项目进展列表
禅道软件在首页提供了进行中的项目的概况列表。通过这个列表，可以很方便的知道目前整个公司正在进行的项目的进展情况。这个图里面的进度是按照总消耗/(总消耗 + 总剩余)计算出来的一个工时的进度。
3.4.7.2.项目视图的所有项目列表
首页的项目列表只是正在进行中的项目，我们在项目视图中，还提供了所有项目进展情况的列表。
3.4.7.3.通过任务列表查看具体的任务的进展情况
1. 可以通过各种检索标签来
2. 可以通过分组查看，来按照不同的字段进行分组
3.4.7.4.通过项目任务树状图，了解项目需求和任务的开发情况。
禅道开源版8.2beta版本新增了任务的树状图功能。可以清晰的显示项目所关联的需求，需求和任务的关联关系以及任务的开发情况。
鼠标放在任务标题上，会显示任务的状态，工时信息，以及操作按钮。
3.4.8. 召开演示会议和总结会议
3.4.8.1.演示会议
在项目结束之后，项目经理应该召开相关人员（团队，以及其他相关的部门，领导，或者合作伙伴等等）召开演示会议。演示会议的目的旨在向大家展示本期项目团队所取得的成果，这是一个提高团队士气、增加成就感的非常好的方式，也是听取反馈，调整下一步计划的方式。
演示会议不用特别正式，它不是汇报会议。不用准备精美的ppt，只需要有一个大屏幕，然后团队的成员分头介绍自己所负责的东西。在演示过程中，会有人提出很多的问题或者建议，产品经理应当将其记录下来，转换为后面的需求。
3.4.8.2.总结会议
演示会议完之后，团队内部应该召开总结会议。这个会议的参与人员主要是团队成员了。该会议的注意议题是总结这次项目我们做的好的地方，做的不好的地方。要将其记录下来，存到文档管理中，比如叫做第几期项目总结。然后确定下一期项目要解决的问题，可以重点解决一个，比如开发环境的问题。
3.4.9. 项目任务基本的报表统计
禅道项目管理软件提供了基本的项目统计功能，项目经理可以通过这个功能来掌握一些宏观的信息：
- 按照所属项目进行统计。
- 按照指派给进行统计。
- 按照任务类型进行统计。
- 按照优先级进行统计。
- 按照截止日期进行统计。
- 按照初预计进行统计。
- 按照预计剩余进行统计。
- 按照已经消耗进行统计。
- 按照由谁完成进行统计。
- 按照关闭原因进行统计。
- 按照每天完成任务数进行统计。
需要注意的是：禅道的统计报表是根据你当前的列表范围进行统计的。比如你现在查看的是进行中的任务，那么统计就是在所有进行中的任务列表中进行的。换言之，你可以通过切换不同的检索条件来获得你想要的统计报表。
3.5.开发团队篇
3.5.1. 参加项目计划会议，分解任务
按照scrum的流程，项目团队成员要参加产品的计划会议和项目的任务分解。
在参加产品计划会议的时候，应当充分理解需求，并发表自己的意见，以确保自己对每一个需求理解都是正确的。
项目计划会议的主要任务是对需求进行任务分解，团队成员应全力参与。分解任务之后，自愿领取自己喜欢的任务。
注意：这个地方的团队成员，不仅仅是开发人员，也包括测试人员，dba，即所有的项目团队中的成员。
3.5.2. 领取任务并每天更新任务
当项目的任务分解完毕之后，项目团队成员需要领取自己喜欢做的任务，开始每天的开发。除了日常的编码工作之外，还应当每天花点时间在禅道里面更新下任务的状态以及消耗情况。
3.5.2.1.领取任务
按照scrum的原则，好是大家领取自己喜欢做的任务，这样才能更好的调动团队的积极性。有的朋友会问，如果没有人领取怎么办？大家都挑简单的怎么办？一个新手挑选了一个关键任务怎么办？每个人的任务量不太均衡怎么办？其实这些问题都不是问题。因为信息是公开透明的，一个个体不可能每一期都只挑简单的任务，做简单的事情。当然了，项目经理宏观层面的把握也必不可少，尤其是一些关键任务，需要平衡下。
领取任务可以通过两种方式，一种是通过“指派”操作，一种是通过“编辑”操作。
3.5.2.2.更新任务状态
项目开始之后，每个人每天应当及时更新自己所负责的任务的状态。禅道提供了几个快捷的操作按钮：开始、完成、关闭、取消和激活。
开始、完成和取消没有什么歧义。解释下关闭和激活。
禅道有一个可选流程，就是当任务完成之后，会自动指派回任务的创建者头上，这时候任务的创建者可以验证任务是否完成。如果完成，则将任务关闭。如果任务没有完成，则激活任务。这个流程是可选的，不是必须的流程。适用于传统的命令-控制式的管理。如果对于敏捷开发团队来讲，忽略这个流程即可。
3.5.2.3.更新任务的消耗
除了更新自己负责任务的状态之外，还应该及时更新任务的工时消耗情况：
- 初预计，即创建任务的时候的初预计。该字段在任务开始之后，不应该再进行修改。这个字段当任务结束之后，可以和已经消耗字段进行对比，以纠正自己的估计。
- 已经消耗，则是你在这个任务上所有花费的工时数。
- 预计剩余，则是你预计这个任务完成大约还需要多少时间。如果预计剩余为0，则表示任务完成。
这里面需要特别强调的是，初预计 ≠ 已经消耗 + 预计剩余。
一定要每天更新自己所负责的任务，因为燃尽图的绘制，就是通过预计剩余这个字段来计算的。
3.5.3. 创建版本
当完成若干功能之后，就可以创建版本了。版本的概念在英文里面是build，可以对应到软件配置管理的范畴。这是一个可选流程，但还是建议团队能够实施版本管理。这个版本主要的作用在于明确测试的范畴，方便测试人员和开发人员的互动，以及解决不同版本的发布和bug修复等问题。
有的同学会问，既然是版本管理，那么禅道能不能管理源代码？禅道当然是无法管理源代码了，呵呵，这是非常专业的一个事情，已经有非常好的开源软件来解决这个问题。比如subversion和git。大家可以根据自己实际的需要部署安装。禅道里面的版本是做了一个记录。
流程如下：
- 首先是团队经过开发，完成了若干需求，或者解决了一些bug。
- 这时候某一位发布负责人在subversion或者git中创建了一个tag(标签)，比如禅道的tag目录如下：
- 创建了tag之后，这位发布负责人就可以在禅道里面创建一个版本了。
注：新版本的禅道，先创建版本，保存成功后，在版本的详情页面再关联需求和Bug。
如果在版本详情页面没有看到关联按钮，那么联系管理员到组织→权限里分配相关权限。
说明：
- 名称编号，团队应该有自己的配置管理规范。比如可以是产品名_版本号_状态(stble, beta之类)_日期
- 不同开发语言其版本的存在形式也不同，有的需要编译，有的只需要源代码。请根据公司的实际情况来填写源代码地址，或者是存储地址。
- 新版本的禅道，先创建版本，然后再关联需求和bug。关联需求和bug后提交给测试人员进行测试的时候，就可以明确这次测试的范畴，测试可以更加有针对性。
- 描述字段可以填写一些测试的注意事项、重点内容等。
3.5.4. 申请测试
当版本创建完毕之后，就可以提交给测试人员进行测试了，提交测试会生成一个测试任务。在这儿需要和大家解释下这个测试任务的概念。其实英文里面里面比较合适的单位是testrun，但翻译到中文里面没有太贴切的词语，我们暂时用了测试任务的概念。但这个测试任务和项目里面创建的类型为“测试”的任务没有直接关联。请大家在使用的时候，注意这个细节。
一般来讲，我们在分解任务的时候，可以创建若干测试类型的任务，比如测试某某，测试某某，大概估计下测试需要的时间。然后具体的测试工作通过测试视图的测试任务来跟踪。
申请测试的步骤：
- 进入项目视图，点击“测试”。
- 然后选择“提交测试”，即可出现提交测试的页面。
说明：
- 负责人为本次测试的负责人。
- 可以指定这次测试预计起止的时间。
- 任务描述里面，可以注明此次测试需要注意的地方。
- 还需要说明的一点是，目前测试任务还没有指派的功能，所以需要大家线下通知测试团队的负责人，由他来负责组织相应人员来进行测试。或者是在项目--任务里创建测试类型的任务，指派给相应的测试人员。
3.5.5. 解决bug
提交测试之后，测试人员展开测试，便会有bug产生。这时候研发团队的一个重要职责便是解决bug。禅道里面bug的处理流程比较简单：
测试人员提交bug => 开发人员解决bug => 测试人员验证关闭，这是比较正常的流程。还有一个流程是激活流程：
测试人员提交bug => 开发人员解决bug => 测试人员验证未通过 => 激活bug => 重新解决 =>验证关闭。
开发人员所需要做的事情便是处理自己负责bug，并在禅道中登记解决方案：
1. 项目视图中的bug列表
2. bug的详情页面也可以找到“解决”操作的按钮。
3. 解决bug的时候，需要填写bug的解决方案。
附：bug的解决方案
禅道软件总共提供了其中解决方案：
- bydesign => 设计如此，无需改动。
- duplicate => 重复Bug，以前已经有同样的bug。
- external => 外部原因，非本系统原因。
- fixed => 已解决。
- notrepro => 无法重现，无法重现bug。
- postponed => 延期处理，确实是bug，但现在暂时不解决，放在以后处理。
- willnotfix => 不予解决。
这其中“已解决”和“延期处理”的bug视为有效bug。
3.5.6. 文档管理
见7.3.10文档管理
3.5.7. 确认bug
当测试人员提交了bug之后，如果开发人员来不及解决这个bug，这时候可选的一个操作是确认这个bug，给测试人员一个反馈。
1． bug列表页面会显示是否已经确认过。
2． bug详情页面有确认操作按钮。
3． bug列表右侧也有确认操作按钮。
需要说明的是，如果一个bug被解决之后，也会自动变成已确认。
3.6.测试团队篇
3.6.1. 维护bug视图模块
在禅道软件中，bug也同样需要维护模块，以便更好的组织管理bug。
禅道5.2.1版本开始，产品的模块直接同步到bug、用例下，有条件的同步到项目中。同时，bug模块、用例模块和项目模块也可以单独维护。
具体步骤：
- 进入测试视图，然后选择Bug。
- 在页面的左侧，会出现该产品的Bug模块列表。
- 模块列表的下部，有模块维护的连接，点击此链接，即可维护模块，详情的维护界面，
- 维护模块的时候是一级级进行维护的。比如可以选择“我的地盘”，然后维护它的子模块。
- 左侧的数字是用来排序的，可以将通过调整模块的排序字段来调整它在模块树里面的位置。
- 可以选择某一个模块编辑，编辑的时候可以修改它所属的上级模块，以及这个模块的默认负责人(当创建bug的时候，会自动将这个用户作为默认的负责人)
3.6.2. 提交bug
直接来看步骤：
- 进入测试视图的“Bug”
- 点击页面右侧的"提Bug"，即可进入Bug创建页面。
说明：
- 项目和任务，以及相关需求，应该认真填写，这样可以将Bug和项目，任务，需求关联起来，以便以后的统计分析。
- 影响版本是必填的。而这里面的列表来源，则是项目中的版本。如果这个地方没有版本可选的话，则需要到与该产品关联的项目--版本中创建版本。
- 重现步骤应该翔实准确，确保开发人员可以重现和解决Bug。
3.6.3. 验证bug，关闭
当开发人员解决bug之后，就需要来验证bug，如果没有问题，则将其关闭。已关闭的bug，默认是不再显示在bug列表的。
3.6.4. 激活bug
如果开发人员解决bug之后，验证无法通过，则可以将bug重新激活，交由后的解决者去重新解决。还有一种情况就是bug关闭之后，过了一段时间，bug又重现了，也需要重新激活。
激活bug的时候，指派给会自动设置成为后的解决者头上。
3.6.5. 找到自己需要的bug
测试人员一个非常重要的工作就是筛选bug，禅道对此提供了各种方便的功能来进行筛选。
3.6.5.1.我的地盘中的bug列表。
我的地盘中的bug列表，是所有当前指派给你进行处理的bug。如果该列表为空，那么恭喜你，没有你需要处理的bug。
3.6.5.2.项目视图中的bug列表
项目视图中的bug列表，是所有在这期项目中产生的bug，所以项目团队可以很方便的在这个页面查看到相应的bug。
3.6.5.3.分类浏览
在测试视图的”Bug列表“页面，可以按照各种条件，非常方便的进行浏览。
3.6.5.4.搜索功能
禅道提供了强大的搜索功能，可以组合出非常复杂的条件。
3.6.6. 维护测试用例视图
同7.6.1维护bug视图，测试用例视图也是需要单独维护的，方法与之相同，不再赘述。
3.6.7. 创建测试用例
禅道中的测试用例，彻底的将测试用例步骤分开，每一个测试用例都有若干个步骤组成，每一个步骤都可以设置自己的预期值。这样可以非常方便进行测试结果的管理和bug的创建。
直接来看创建用例的页面：
说明：
- 用例的适用阶段，指在哪些个测试阶段，可以用上这个用例。可以进行多选。
- 用例步骤可以非常方便在之后插入，之前插入，或者删除当前的步骤。
- 不要把若干个测试用例作为步骤写到一个测试用例里面，因为这样不利于测试的管理和统计。
3.6.8. 管理测试任务
当开发人员申请测试之后，会生成相应的测试任务给测试人员。这时候测试人员要做的就是为这个测试任务关联相应的测试用例。如果这个测试任务需要多人来配合完成，则需要将相应的用例指派给相应的人员来进行完成，或者自己领取相应的测试用例。
3.6.8.1.关联测试用例
- 进入测试视图，
- 选择“版本”，然后进入版本列表。
- 选择某一个待测版本（即原来的测试任务），点击“关联”菜单，即可出现关联测试用例的页面。
几点说明：
- 测试用例可以通过上面的搜索表单进行搜索。
- 用例默认是关联新的版本，也可以点击下载框，选择之前的版本
- 可以按照需求或者bug来进行检索。
3.6.8.2.指派或领取用例
在版本（测试任务）的用例列表页面，可以点选用例，将其指派给某一个人来执行。
3.6.9. 执行用例并提交bug
在测试--版本的用例列表页面，用户可以按照模块来进行点选，或者选择所有指派给自己的用例，来查到需要自己执行的用例列表。
在用例列表页面，选择某一个用例，然后选择右侧的“执行”菜单，即可执行该用例。
测试人员在测试时，我们推荐在测试--版本页面，版本所关联的用例列表里执行用例，完成测试。
1. 用例列表页面，点击执行
2. 执行用例
3. 创建bug
如果一个用例执行失败，那么可以直接由这个测试用例创建一个bug，而且其重现步骤会自动拼装。
3.6.10. 查看报表统计
测试管理的还有一个重要工作就是统计报表，直接来看步骤：
在bug列表页面，点击页面上部的统计报表，即可出现统计报表页面。
说明：bug的统计报表是和当前的列表集合相关的。因此，你可以通过不同的搜索条件来查找自己要进行统计的bug列表，然后再按照不同的统计项进行统计。