before

一般的，产品的从需求开始到上线，要经历很多个步骤：

在产品的整个开发测试周期内，都需要进行相应的开发流程、测试流程、缺陷管理、配置管理等等。

那最开始，我们使用word文档来管理缺陷，后来慢慢的发展到管理整个项目，这个时候，用word就不方便了，所以，人们开发出了项目管理工具：

• Quality Control（QC）：是Mercury Interactive 公司（软件版权属于惠普公司）推出的一个基于 Web（伪） 且支持测试管理的所有必要方面的应用程序。该软件提供统一、可重复的流程，用于收集需求、计划和安排测试、分析结果并管理缺陷和问题。组织可使用该软件在较大的应用程序生命周期中实现特定质量流程和过程的数字化。该软件还支持在 IT 团队间进行高水平沟通和协调。功能真的很强大（收费版），但是要花钱........

• Bugzilla：Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期，功能较少，专门用来管理缺陷。

• Bugfree：除了管理缺陷，也可以管理用例，但不能管理需求.......

• Mantis：缺陷管理平台Mantis，也做MantisBT，全称Mantis Bug Tracker。Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。

• JIRA：JIRA是集项目计划、任务分配、需求管理、缺陷跟踪于一体的软件。它基于Java架构的管理系统，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

  JIRA创建的问题类型包括New Feature（新功能）、Bug（缺陷）、Task（任务）和Improvement（改进）四种，还可以自定义，所以它也是一个过程管理系统。同时融合了项目管理、任务管理和缺陷管理。JIRA功能强大，可配合着一些组件及工具一起使用，如： Confluence 用于 wiki 管理需求，JIRA管理任务、进度和 Bug 。

  JIRA设计以项目为主线，产品、测试结合管理，通过issues控制管理。因此它的核心诉求还是围绕issue展开的，以issue驱动管理、分工、以及团队协作，进而实现项目的规划、建设，终完成产品开发。

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

  禅道的主要管理思想基于国际流行的敏捷项目管理方式—Scrum。Scrum是一种注重实效的敏捷项目管理方式，它规定了核心的管理框架 ，但具体的细节还需要团队自行扩充。禅道在遵循其管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。

  禅道最大的特色是创造性的将产品、项目、测试这三者的概念明确分开，互相配合，又互相制约。通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品。

目前，禅道和JIRA用的人较多。我们这里以禅道为例。

禅道项目管理软件是做什么的？

禅道由青岛易软天创网络科技有限公司开发，国产开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。禅道管理思想注重实效，功能完备丰富，操作简洁高效，界面美观大方，搜索功能强大，统计报表丰富多样，软件架构合理，扩展灵活，有完善的API可以调用。禅道，专注研发项目管理！

为什么用禅道这个名字？

禅和道这两个字含义极其丰富，有宗教方面的含义，也有文化层面的含义。禅道项目管理软件取其文化含义，期望通过这两个字来传达我们对管理的理解和思考。这个名字是受《编程之道》和《编程之禅》这两本书的启发。英文里面的禅为Zen，道为Tao，所以我们软件的英文名字为zentao。

禅道的安装

docker部署禅道

1. 新建一个容器卷挂载目录

[root@C /]# mkdir -p /docker_data/zento_data

2. 拉取镜像

[root@C ~]# docker pull idoop/zentao:12.0.1

3. 启动禅道

docker run -d -p 6003:80 -p 3308:3306 --restart=always -e ADMINER_USER="root" -e ADMINER_PASSWD="password" -e BIND_ADDRESS="false" -v /docker_data/zentao_data:/opt/zbox/ --add-host smtp.exmail.qq.com:163.177.90.125 --name zentao-server idoop/zentao:latest

4. 现在就浏览器访问ip:6003端口即可，然后会让你修改密码，默认账号和密码：

账号：admin
密码：123456

for Windows

1. 执行安装，注意，无论哪个盘，都要安装在根目录下。

2. 安装完事了。在C:\xampp目录中双击start启动它。

3. (可能的提示)安装VC++运行环境。

如果VC++安装失败，参考：https://answers.microsoft.com/zh-hans/windows/forum/all/microsoft-visual-c-2015/0b2acae1-63fa-4e0b-b482-c9f8e138100e

3. 启动后，是这个页面，点击启动按钮即可。

4. 提示修改密码，你修改成较为简单的即可。

5. 按照提示浏览器访问给出连接，提示让你登录，这是因为在启动时没有取消勾选启用Apache用户访问验证选项，你可以取消勾选。

6. 当你取消勾选启用Apache用户访问验证选项后，浏览器访问就可以了，这里你可以选择开源版即可。

7. 选择开源版，用户名默认是admin，密码默认是123456。

8. 进入修改密码界面。

9. 问你是否进入新手教程，这里选择取消。

10. 完事就进入到了这样的一个页面。

11. 禅道的项目流程介绍。

我们通过这个流程图，使用禅道走一遍流程。

创建角色

我们知道当一个项目开始的时候，需要由产品经理创建产品和收集需求等操作，还需要其他的角色来完成不同的任务，所以，我们先来把各个角色创建完成。

为了不忘记密码，下面列出相关角色和密码，便于参考：

角色	密码	备注
admin	root!1234	管理员
chanpinjingli1	root!1234	产品经理1
xiangmujingli1	root!1234	项目经理1
yanfazhuguan1	root!1234	研发主管1
chanpinzhuguan1	root!1234	产品主管1
ceshizhuguan1	root!1234	测试主管1
gaocengguanli1	root!1234	高层管理1
kaifa1	root!1234	开发人员1
kaifa2	root!1234	开发人员2
ceshi1	root!1234	测试人员1
ceshi2	root!1234	测试人员2

为了方便，角色密码以都为root!1234。

现在，使用admin账号登录系统。

添加角色

选择组织下面的添加用户，参照下图设置个人信息。

然后按照这个套路你可以使用批量添加将其他的角色建立起来，错了也可以修改。

完事，大概角色就这些，后续用到再添加即可。

产品管理

创建产品

现在使用产品经理登录，并略过新手教程：

账号:chanpinjingli1
密码：root!1234

开始吧！

选择产品视图，选择添加产品按钮，填写相应信息即可。

完事了。

这里需要注意的是：

• 产品负责人，可以选择当前的产品人员，产品经理。
• 测试负责人，测试主管或者测试经理。
• 产品代号，内部的对于该产品的名称。
• 访问控制选项，有三种选择：
  • 默认选项，只有能看到产品视图的人，可以访问。
  • 私有的， 该产品项目下的人员才能看到。
  • 设置白名单，白名单中组中的用户可以访问。

此时，产品创建完毕，接下来应该干嘛？应该创建该产品的计划了。

创建产品计划

还是使用产品经理登录，并略过新手教程：

账号:chanpinjingli1
密码：root!1234

开始吧！

产品下面的计划选择创建计划。

填写相应的信息即可。

创建计划的好处有：

• 可以帮助产品人员控制产品的研发过程。
• 帮助相关人员了解产品进度，便于后续的工作安排。

有了相应的计划了，接下来就可以建立相应的需求，并且可以将需求分解为多个模块。

添加模块和创建需求

还是使用产品经理登录，并略过新手教程：

账号:chanpinjingli1
密码：root!1234

开始吧！

产品选项点击代码统计产品，然后点击模块按钮，就可以填写相应的模块信息。

当你点击保存后，会在左侧菜单栏显式刚刚创建的模块。

将产品需求分为各个模块，方便我们对产品有个宏观认识，掌握产品的构成，任务细化后也便于跟进进度和随时调整。

有了模块，就可以在该模块下提需求，然后对提的需求进行评审后，就可以进入实现开发阶段了。

来，创建需求吧！ 选择产品,然后在产品列表中选择相应的产品(我们这里就一个)，完事点击需求，再点击提需求。

编辑各个选项即可，这里需要注意的是，提的需求是需要评审的，所以需求评审选项你应该取消勾选，然后你要指定有谁评审，也就是这个需求保存后，需要你指定的人去评审这个需求；抄送选项则是说提的需求应该被谁看到，或者"告诉"谁，可以多选；至于优先级选项则是数字越小优先级越高；关键字,后续搜索用；你也可以为这个需求上传附件和附件的标题信息。

当你点击保存后，就会看到，该需求如下图所示的样子，这是因为该需求刚刚提出，但还没经过评审，所以是草稿状态，此时该需求还不能进入到研发阶段；当然，需求的评审应该是一个线下的过程，禅道这里只是记录一下评审过程。

那接下，就是需要对需求进行评审了吧！

需求评审

先来看需求的评审流程，如下图。

知道了需求评审的流程，并且当时这个需求指派给产品主管去评审，所以我们现在以产品主管的身份登录：

账号:chanpinzhuguan1
密码：root!1234

PS：由于需求的评审相关是多人参加，你应该注意每个截图中的登录者的身份。

在产品的需求选项，选择指派给我选项，会发现有一条来自产品经理创建的需求，需要评审，点击操作列的眼睛也就是评审按钮。

新的评审页面如下：

在这个页面中，需要注意的有个评审结果选项，有三个：

• 确认通过，需求没有问题，通过。
• 有待明确，这个需求有些问题，你可以在备注栏中填写需求的问题。
• 拒绝，这个需求有大问题，或者这需求不对，这个需求不用实现，所以该需求被拒绝。

我们这里选择有待明确，打回去这个需求。

可以看到历史记录中，发现产品主管已经评审完毕，并且把评审结果展示了，这个时候，应该由产品经理(提需求的人)去完善该需求：

此时产品经理登录禅道后，会发现自己提交的需求被打回来了，那么点击需求描述也能发现产品主管的评审结果，所以，此时，产品经理需要再次编辑完善该需求。

产品经理已经完善了该需求，并且重新保存，那么该需求将重新提交给产品主管，此时产品主管登录，就可以发现完善的内容。

那么，此时点击评审按钮再次评审，这里我们选择拒绝选项看看发生什么情况？新增了一个下拉框，让你选择拒绝原因。

我们随便选择一项，如设计如此，此时无论是产品经理还是产品主管登录，都会发现此时该需求处于已关闭状态。

那么，如果产品主管在评审时，选择了确认通过，那么此时的需求状态就是激活的，如下图，一个新的需求的评审结果。

注意，只有进入到激活状态的需求才能进行后续的开发。

需求评审是一个线下过程，有多人决定，评审完毕在禅道中记录即可。

需求变更

一般的，项目中的需求变更流程如下图所示：

除了需求的评审，还会经常遇到需求的变更，来看看禅道中的需求变更流程。

# 产品经理
账号:chanpinjingli1
密码:root!1234
# 产品主管
账号:chanpinzhuguan1
密码:root!1234

现在，让我们以以产品经理的身份登录，修改其中一个激活状态的需求，进行变更操作。

然后进行内容的变更。

变更完毕后，此时该需求的状态是已变更状态。

现在，以产品主管的身份对上述变更做变更评审。

需要我们重点关注的是评审结果：

• 确认通过：选择该项后， 该需求的变更完成，新的需求状态为激活状态。后续的开发任务按照该需求来。
• 撤销变更，选择该项后，该需求撤回到上一次的激活状态，并且记录一个变更的版本信息，后续开发任务按照原需求进行，相当于拍了个快照，恢复到之前的状态。
• 有待明确，选择该项后，可以将评审结果重新指派给产品经理，然后产品经理再次修改变更记录，再交给产品主管进行评审的这样一个流程。

上面三种状态都是基于产品经理在提需求变更时，选择需求评审的结果。如果选择不需要评审，那需求就直接变更完毕，状态也是激活状态。

再次强调，当需求内容(标题/描述/附件信息等)发生改变时，都要走变更流程。

项目管理

项目立项

现在，关于产品相关的需求已经评审结束，就可以进入到项目立项阶段，也就是即将进入到实际的编码阶段了。

项目立项一般都是开个立项会：

• 由产品人员把产品的需求与项目组成员沟通，必要时调整需求；
• 项目组成员估算完成需求的工作量；
• 对需求进行分解，任务分配；

完事之后，一般由项目经理在禅道中建立项目。

PS:项目组成员在线下已经分配好了，但还需要在项目创建后，手动的关联，所以，称这个过程为创建项目和创建团队。

那现在我们来看项目经理如何建立项目和需求分配，这里先看怎么建项目，由项目经理登录禅道：

账号: xiangmujingli1
密码: root!1234

选择项目下的添加项目,编辑相关选项。

当你点击保存后，会提示：

选择设置团队，进入如下界面：

当然， 你后续也可以手动的设置项目团队

选择团队管理，关联项目组成员，并未每个成员设置开发/测试时间。

完事之后，长这样：

以上就是创建项目和关联团队的操作。

注意，访问控制这里跟之前产品的访问控制一样：

• 默认的，只要有项目视图的就可以看到
• 私有的，项目团队成员可以看到
• 白名单，白名单中的成员可以看到

关联/分配需求

当项目创建后，也有了项目团队，接下来该做什么？是关联需求，只有关联了产品人员提出的需求，就可以继续后续的开发/测试工作了。

那如何关联需求呢？以及需求如何分配呢？用项目经理登录：

账号: xiangmujingli1
密码: root!1234

关联需求

项目视图下的需求选项，该选项展示已经关联的需求列表，我们暂时还没有关联需求，所以列表为空；这里点击关联需求。

勾选需要关联的需求，完事点击保存，注意，这里只能关联激活状态的需求，并且，由于在创建项目的时候，该项目关联的是代码统计产品，所以，此时关联的需求也是该产品下的激活状态的需求。

关联完毕后，是这样的：

那接下来，要干嘛？毫无疑问，关联完了需求后，那肯定是要找人撸袖子干了啊，所以，接下来要开始需求分配了。

分配需求

此时就到了具体让谁干的阶段了，比如让开发去码后台代码代码；让UI去切图；让测试去设计测试用例等等。

此时，还是项目经理登录状态。

在项目下的需求列表中，点击加好开始分配需求。

举一个为开发分配需求的例子，参照下图进行相关选项的编写。

在来为测试分配需求：

分配需求就是这么简单！但是有个问题，在上述操作过程中，都是将任务指派给一个角色，那如果遇到需要将需求分配个多个角色怎么办，比如各个角色在完成任务后需要编写总结和报告该怎么分配这个需求，来看看怎么搞。

这就用到了你可能没有注意到的任务类型选项中的事物选项，该选项就是干这个事儿的。

当选择事物后，我们就可以将该任务分配多个角色了，相关选项如下图所示。

现在，任务分配大致就这样做，我们可以在项目视图中的任务列表查看这些任务。

另外，在项目视图下的需求列表中，也能看到各需求的任务数。

当然，在实际的个工作中， 需求分配这些操作都是项目团队商量着来的，而禅道上只是一种表现形式。

那么，接下来，该干嘛了？开发人员领取任务，并且统计每天的工作量。

项目开发阶段

现在，到了开发领取任务，创建项目版本的阶段了。

由开发人员登录：

账号: kaifa1
密码: root!1234

需求开发

项目视图下的任务栏，选择指派给我的，然后在每一个任务的操作中，点击开始按钮，就可以了。

由于，在之前分配任务的时候，项目经理给开发人员就10个工时，此时，第一天干了8个小时，还剩下两个小时。

当你点击开始后，在任务列表中也能体现，如下图，该任务已经开始了，并且任务进度和耗时都有相应的变动。

此时你也可以点击工时按钮，进行后续工时的编写：

如上图，我们在剩下的的两个工时中，改了代码的bug，预计这需求完成了，工时剩余未0，当你点击保存时，会提示你，是否标记任务完成，此时根据当前的完成情况，这里点击确定；在所有的任务列表中，发现该需求的状态是以完成的。

现在，当开发人员完成需求后，就要把项目构建版本、打包传合并到主分支这些操作了。

构建版本

来看禅道中如何构建版本，此时，还是开发人员登录状态。

PS：在工作中，产品最起码有测试版本(beta)和生产(稳定)版本(stable)两个版本甚至有更多的版本。

项目视图中的版本列表栏，选择创建版本。

如下图的选项中：

• 产品的名称编号一般都是产品名称_版本号_teta/stable_日期。
• 描述选项，一遍填写该版本有哪些功能，解决哪些问题，测试中的注意事项等等。

版本构建完成后，是这样的：

此时的版本是一个空的版本，因为各项数据都是初始状态。

版本关联需求

上一步骤中，构建了版本，那该版本都完成了哪些需求呢？我们来为这个版本关联上需求。

用到的相关角色账号：

# admin
账号: admin
密码: root!1234

# 开发人员
账号: kaifa1
密码: root!1234

赋予(开发)角色自定义权限

默认的，开发人员在构建版本完毕后，并没有关联版本的操作按钮或者链接，因为默认没有该权限。所以，需要使用admin用户为开发人员赋予该权限。

使用admin账号登录。

组织视图下的版本选项，在研发列，点击权限维护按钮。

下拉选择版本选项，勾选关联需求选项，再下拉点击保存即可。 当然，你也可以勾选其他的功能。

此时，在以开发人员人员的角色登录禅道，在项目视图下的版本选项，就可以看到了关联需求的按钮了，点击它。

在需求列表中，勾选上相应的需求，就可以关联了。

完事之后，该版本的完成的需求列表也能查看到该需求了。

OK了。

现在，开发阶段算是完事了，该测试人员上场了！

测试阶段

开发完成了需求，就该进入提测阶段，然后测试就开始进行具体的测试环节了。

那么开发提测的过程在禅道上是如何操作的呢？一起来看看！

用到的相关角色账号：

# 测试人员
账号: ceshi1
密码: root!1234

# 开发人员
账号: kaifa1
密码: root!1234

# admin
账号: admin
密码: root!1234

# 测试主管
账号: ceshizhuguan1
密码: root!1234

开发提测

开发人员登录。

测试视图下的版本列表中，下图是提交测试后的样子。

点击提交测试，编写提测的相关说明。

需要注意的：

• 负责人，指的测试的负责人。
• 优先级，根据功能来选择。
• 描述，告诉测试需要注意的事项等其他事项。

接下来该干嘛了？测试？测试用例都没有！来写测试用例吧！

创建用例

测试人员登录。

测试视图下用例列表，点击＋建用例。

填写相关选项。

保存后，用例列表就有了这个用例。

版本关联用例

接下来，还需要将该用例关联到当前的版本中。

还是测试人员登录。

测试视图下的版本列表，点击关联用例按钮。

勾选用例后点击保存即可。

OK了。

此时，虽然用例写完了，但是严格意义上来说还需要对该用例进行评审。

当然， 默认的，禅道中，用例评审默认是关闭的，我们需要先打开该功能。

后台开启用例评审功能

admin账号登录，后台视图，自定义菜单栏**选择用例**中的评审流程，勾选开启即可，如下图所示。

用例评审

当管理员开启用例评审功能后，在创建用例时，就会发现，有了用例评审选项单选框。

如上图，该用例需要评审，那在用例列表中，就会发现该用例就是出于待评审阶段。

点进该用例的详情页，你会发现，你自己其实也可以评审，这块禅道对于权限的限制没有那么严格，但是一般的由测试主管等领导来评审你的用例。

下图的截图是以测试主管的身份登录，进行该用例的评审。

测试视图中的用例列表，可以看到待评审的那个用例。

点进详情页后，可以进行评审操作。

评审结果这里就两个选项：

• 确认通过，选择该项后，该用例处于正常状态，就是可以进行实际的测试操作了。
• 和继续完善，很明显打回去从新完善呗，流程参考需求评审的流程。

PS：你也可以为刚刚这个用例关联版本。

用例执行及提交bug

当用例评审过了之后，就可以执行了，执行用例会有两种结果，通过和失败，而对于通过和失败的处理方式，一般可以参考下图来处理：

我这里以测试主管的身份登录的， 你可以以测试人员登录的身份登录，相关流程都一样，无所谓的。

测试视图下的用例列表中，选择一个用例点击执行。

注意，这个用例的执行是你真实的在你的测试环境中跑一遍用例，而禅道这里只是记录一下执行过程。在上图的测试结果中，每一步都通过的话，就不用管，如果某一步失败了，就会在下面记录该失败步骤，并且可以进行提测，如下图：

如上图的第三步骤，出现问题的话，就会记录该bug，此时点击右下角的转bug，将bug提交给开发人员。

如下图的选项中：

• 截止日期这一栏，我们暂时不填，因为我们也不知道开发什么时候修复该bug。
• 当前指派，原则上应该由谁开发则指派给谁。
• 重现步骤，你应该按照提示进行详细描述bug产生的过程，便于开发复现bug。

在测试视图的Bug列表中可以发现刚才提交的bug。

上图中，可以看到该bug此时是处于未确认状态，即未经过开发确认的状态。

除了可以在用例执行过程中提bug，我们还可以单独点提bug安装来提bug。

很明显，有了bug，开发就要确确认及修改bug了。

开发修复bug

开发人员修复bug的流程一般是：

• 确认bug的存在
• 实际的解决bug
• 在禅道上修改bug的状态

来看禅道中的操作。

开发人员登录。

测试视图Bug选项中，指派给我的；这里有两个重要按钮：

• 确认，可以直接点击这个按钮进行确认该bug，你也可以点击到bug详情栏点击确认。
• 解决，确认后，你就可以去真正的解决该bug，完事再来修改该bug的状态。

确认bug

当你点击确认按钮后，可以选择bug类型，以及填写备注等操作，然后点击保存。

此时bug的状态就变成了已确认状态；如果此时测试人员登录，会发现此bug就是已确认状态，表示开发确认了bug。

当你解决完这个bug后，需要再次来禅道修改bug状态，点击解决按钮。

关于解决方案，有下面几种，意思就是字面意思，没啥好解释的：

• 设计如此
• 重复bug
• 外部原因
• 已解决
• 无法重现
• 延期处理
• 不予解决

由于该bug是测试主管提交的，所以我们将bug的修改结果在指派给测试主管。此时，该bug的状态是已解决。

再来个测试主管登录视图：

OK啦。

现在，开发说解决了这个bug，就真的解决了么？我们还需要对该bug确认测试，也就是回归测试。

回归测试

一旦开发人员将bug修复，然后测试人员就要重新进行回归测试。

此时，由于bug是测试主管发现并提交的，所以，还由测试主管登录。

测试视图下的Bug列表，你会发现该bug处于已解决的状态：

我们可以点bug详情来查看。

如上图，有重要的两个选项：

• 关闭，当开发修复bug后，测试人员需要再次对该bug进行回归测试，没有问题，点击关闭，这个bug的周期就完了。
• 激活，如果测试人员在回归测试时，发现bug仍然存在，就要激活该bug，让开发继续改，流程如下：
  • 由于该bug之前开发确认过，此时，开发直接再次修复该bug，然后在他的视图中将bug状态改为以解决。
  • 测试继续进行回归测试，通过则关闭bug；失败则继续激活，直到通过回归测试。

来演示 一下测试重新激活的流程：

在bug详情页面，测试人员点击激活按钮：

此时，无论谁登录查看，该bug的状态都是激活状态；然后开发登录禅道，发现，该bug被重新激活后，直接修复，然后在禅道上重新修改bug至已解决状态：

PS：上图为开发人员视图。

完事后，测试人员，也就是测试主管在进行回归测试，发现没有问题，在点击关闭即可。

然后，bug列表，你会发现，此时bug处于已关闭状态：

OK，回测测试过程演示完毕。

注意：如果一个bug反复的解决不掉，就不要在禅道上跟开发来回交互，而是直接跟开发线下沟通，注意和气生财呦！

总结

本篇主要围绕一般的产品流程来展开的，整个流程开始由：

• 产品经理：
  • 收集信息
  • 建立产品
  • 为产品建立产品计划，加强产品的控制，项目人员掌握产品进度，便于后续安排
  • 为了后续方便，在计划周期内，建立模块，并且将各个模块分解为一个个需求
  • 并且，对需求进行评审，这是一个线下会议
  • 评审中，可能会遇到需求变更，要走需求变更流程
• 项目经理：
  • 基于产品建立项目
  • 组建项目团队，开发/测试等团队
  • 确认项目中的需求，进行可能的需求修改
  • 对需求进行分解为一个个任务，任务类型需要注意的是事物，一次性将任务指派给多人。
• 开发：
  • 统计每天的工作量
  • 完成需求任务后：
    • 提交版本，版本命名参考产品名称_版本号_teta/stable_日期
    • 版本关联需求
  • 完事后，提测
• 测试：
  • 编写测试用例
  • 用例评审，该功能默认是关闭的，需要管理员开启
  • 执行用例：
    • 发现问题，转bug，将bug提交给开发人员
    • 开发人员首先要确认bug，然后改完bug后，修改在禅道修改bug状态
    • 测试回归测试：
      • 通过，关闭bug。
      • 失败，再次激活，跟开发再次交互.....，直到回归测试通过
    • 如果遇到bug反复解决不了的， 就不要在禅道上交互了， 直接线下友好沟通，没准还能交个女朋友！岂不美哉？

欢迎斧正，that's all