图片不好粘贴，原文件请到资源中下载
http://download.csdn.net/detail/maotongbin/9866042
第1章 说明
版本控制整个思想基于禅道管理的思想。针对产贸送的实际情况进行适当调整。部分流程与禅道的正常流程相悖，请特别注意。
整个规范分为两部分：1.新需求研发流程 2.Bug维护流程 按照实际工作中的流程顺序及角色划分来进行陈述。
2.1 流程图
2.2 创建需求
角色：咨询/产品经理
1. 使用产品经理角色登录系统。
2. 进入产品视图。
3. 在页面右侧，有“提需求”菜单，点击菜单，出现新增需求的页面。
l 需求的标题是必填项。
l 所属计划和模块，可以暂时保留为空。
l 需求审核那块，我们选上不需要审核，这样新创建的需求状态就是激活的。只有激活状态的需求才能关联到项目中，进行研发。
l 需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。
l 可以设置关键词，这样可以比较方便的通过关键词进行检索。
2.3 评审需求
角色：咨询/产品经理、技术部长、组长、研发、测试、其他管理人员
在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建是激活中的。但大部分情况下面，需求还是需要评审的。即使产品完全有一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增需求的评审流程如下：
下面我们来看下具体的需求评审页面：
l 评审结果可以选择确认通过、有待明确、拒绝等操作。如果选择“确认通过”，则需求的状态改为“激活中”，然后就可以关联到项目中进行研发了。
l 如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，有其继续进行完善。
l 如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：
l 由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。
2.4 变更和评审需求
角色：咨询/产品经理、技术部长、组长、研发、测试、其他管理人员
变更是需求管理必不可少的流程，禅道项目管理软件对需求的变更提供了全面的支持。其实需求的变更并不可怕，但不清楚影响范围的变更是很可怕的。在传统项目管理中，由于没有有力工具的支撑，产品经理在变更需求的时候，无法知晓该需求的影响范围，会有很大的随意性。禅道项目管理软件将需求、任务、Bug和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给产品经理更好的指导。
禅道里面需求变更的基本流程如下：
下面我们来看下具体的操作：
2.4.1 变更需求
禅道专门提供了需求的变更流程。凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。变更之后的需求状态为变更中。
l 编辑操作是无法修改需求的标题、描述、验收标准和附件的。
l 在变更需求的时候，如果选择了“不需要评审”，则需求状态自动变成激活，不需要再走评审流程。
l 在变更需求的时候，会列出该需求的影响范围：
2.4.2 评审需求
2.4.2.1 通过需求的详情页面查看变更前后的变化
2.4.2.2 评审需求，给出评审结果
l 评审结果可以选择确认通过，撤销变更，有待明确或者拒绝。如果选择确认通过，则需求的状态从“已变更”变为“激活中”。
l 如果选择撤销变更，则取消当前的变更，并回退到之前的版本。
l 如果选择有待明确，需求被打回到需求的变更者，继续进行完善。
l 如果选择拒绝，则需要给出相应的拒绝原因。
l 同样在评审需求的时候，也会列出相应的影响范围，评审者可以参考。
2.4.3 确认需求变更
当需求变更被确认之后，研发团队和测试人员需要确认需求的变更。
2.4.3.1 任务确认需求变动
2.4.3.2 Bug确认需求变动
2.4.3.3 用例确认需求变动
2.5 组织进行任务分解
角色：技术部长/组长
确定了当前项目要完成的需求之后，下一步的操作就是为每一个需求做任务分解。需求确定之后，项目中几个关键的因素都有了：周期确定、资源确定、需求确定。下面我们要做的事情就是为每一个需求做wbs任务分解，生成完成这个需求的所有的任务。note:是完成需求的所有任务，这里面包括但不限于设计，研发，测试等。
2.5.1 访问项目的需求列表页面：
l 在项目的需求列表页面，可以很方便地对某一个需求进行任务分解。
l 同时还可以查看这个需求已经分解的任务数。
2.5.2 分解任务
l 这时候创建任务的时候，就可以选择需求了。
l 我们同时提供了需求查看的链接。
l 如果需求和任务的标题是一样的，可以通过”同需求“按钮快捷的复制需求的标题。
2.5.3 任务分解的几个注意事项
1. 需要将所有的任务都分解出来。这里面包括设计，研发，测试，美工，甚至包括购买机器，部署测试环境等等。
2. 任务分解的粒度越小越好，比如几个小时就可以完成。
3. 如果一个任务需要多个人负责，继续考虑将其拆分。
4. 事务型的事务可以批量指派，比如需要让团队里面的每一个人都写个项目总结，可以选择类型是事务，然后批量指派给团队里面的所有人员。
5. 任务的类型请仔细设置，这个会涉及到需求研发阶段的自动计算。后面我们会有讲解。
6. 任务的分配好是自由领取，这样可以大程度上调动大家的积极性。
7. 任务的分解好是由团队共同完成，不要由技术部长一人包办。
2.6 领取任务，并每天更新任务
角色：研发人员
项目开始之后，研发人员只需要每天花点时间在禅道里面更新下任务状态以及其消耗和剩余时间。当项目的任务分解完毕之后，项目团队成员需要领取自己喜欢做的任务，开始每天的研发。除了日常的编码工作之外，还应当每天花点时间在禅道里面更新下任务的状态以及消耗情况。
2.6.1 领取任务
按照scrum的原则，好是大家领取自己喜欢做的任务，这样才能更好的调动团队的积极性。有的朋友会问，如果没有人领取怎么办？大家都挑简单的怎么办？一个新手挑选了一个关键任务怎么办？每个人的任务量不太均衡怎么办？其实这些问题都不是问题。因为信息是公开透明的，一个个体不可能每一期都只挑简单的任务，做简单的事情。当然了，技术部长宏观层面的把握也必不可少，尤其是一些关键任务，需要平衡下。
领取任务可以通过两种方式，一种是通过“指派”操作，一种是通过“编辑”操作。
2.6.2 更新任务状态
项目开始之后，每个人每天应当及时更新自己所负责的任务的状态。禅道提供了几个快捷的操作按钮：开始、完成、关闭、取消和激活。
开始、完成和取消没有什么歧义。解释下关闭和激活。
禅道有一个可选流程，就是当任务完成之后，会自动指派回任务的创建者头上，这时候任务的创建者可以验证任务是否完成。如果完成，则将任务关闭。如果任务没有完成，则激活任务。这个流程是可选的，不是必须的流程。适用于传统的命令-控制式的管理。
2.6.3 更新任务的消耗
除了更新自己负责任务的状态之外，还应该及时更新任务的工时消耗情况：
初预计，即创建任务的时候的初预计。该字段在任务开始之后，不应该再进行修改。这个字段当任务结束之后，可以和已经消耗字段进行对比，以纠正自己的估计。
已经消耗，则是你在这个任务上所有花费的工时数。
预计剩余，则是你预计这个任务完成大约还需要多少时间。如果预计剩余为0，则表示任务完成。
这里面需要特别强调的是，初预计 ≠ 已经消耗 + 预计剩余。
一定要每天更新自己所负责的任务，因为燃尽图的绘制，就是通过预计剩余这个字段来计算的。
2.6.4 完成任务
任务完成以后，点击【解决】来完成任务。此处需要特别注意。在“指派给”中，任务默认会指派给建立任务的人。这里我们需要手动把“指派给”修改成自己的组长。
2.7 建立发布
角色：技术部长/组长
项目结束后的一个工作就是创建发布，通过创建发布，可以告诉公司其他相关的部门，他们可以在新版本产品的基础上开展工作。同时也是鼓舞团队士气非常好的一个手段。
在建立发布前组长必须要对研发人员的代码进行审核。
2.7.1 如何创建发布
1. 进入产品视图，选择发布列表。
2. 然后点击“创建发布”，即可出现创建发布的页面。
3. 如果产品是有多分支/多平台的，可以选择在哪个分支/平台下创建发布。
如果是没有使用多分支/多平台的，可以忽略上面的操作，直接点击右上角的 创建发布 操作。
创建成功后，即可关联需求和Bug。
l 选择了版本之后，系统会自动计算这个版本所对应的项目中完成的需求和解决的Bug，可以进行关联选择。
l 如果系统自动计算的需求和Bug不完整，可以在描述字段里面补充。
2.7.2 通知测试
组长在创建了发布以后需要完成两个任务：
1. 在研发人员完成研发后会将任务指派给组长。建立发布后组长需要将此次发布的任务在禅道中指派给测试人员。并在备注中填写对应的发布版本。
2. 通知测试人员根据发布，对版本进行测试。
2.8 任务验证，关闭
角色：测试人员
2.8.1 任务验证
测试人员可以根据研发组提供的发布版本查看此处发版关联的任务和Bug。
当研发人员完成需求研发后，就需要来验证Bug，如果没有问题，则将其关闭。如果Bug仍然存在，则将其激活。已关闭的Bug，默认是不再显示在Bug列表的。
2.8.2 通知咨询
测试人员完成测试后将发布版本号告知咨询人员。咨询人员进行业务验证。
2.9 验证任务，关闭
角色：咨询人员
咨询人员在收到测试人员反馈后，可以根据版本信息。查看此处发版管理的需求和Bug
咨询人员对业务验证无误后。更新需求状态，关闭需求。并反馈给技术部长，此处版本验证无误。
2.10 上线发版
角色：运维人员
技术部长在得到反馈后，通知运维人员。协调研发组长对版本进行发布。
运维组对版本进行发布。并关闭发布任务。【停止维护】
同时DBA对数据库进行维护。
3.1 流程图
3.2 提交Bug
角色：测试人员
统一规范，所有Bug必须由测试人员提出。其他人员发现Bug联系相关测试人员。提交Bug，并进行跟踪。
1. 进入测试视图的“Bug”
2. 点击页面右侧的"提Bug"，即可进入Bug创建页面。
Bug提交不再是直接提交给研发组。而是先“指派给”咨询人员。咨询人员确认这个Bug是否合理，是否是业务设计如此。并且咨询人员需要对产品负责。咨询人员有必要知道当前的系统存在哪些问题。而且Bug的紧急程度，优先级咨询人员最优发言权。
说明：
1. 项目和任务，以及相关需求，应该认真填写，这样可以将Bug和项目，任务，需求关联起来，以便以后的统计分析。
2. 影响版本是必填的。而这里面的列表来源，则是项目中的版本。如果这个地方没有版本可选的话，则需要到与该产品关联的项目--版本中创建版本。
3. 重现步骤应该翔实准确，确保研发人员可以重现和解决Bug。
3.3 确认Bug
角色：咨询人员
以前测试人员直接将Bug提交给研发。现在改为先将Bug提交给咨询人员。咨询人员确认这个Bug是否合理，是否是业务设计如此。并且咨询人员需要对产品负责。咨询人员有必要知道当前的系统存在哪些问题。而且Bug的紧急程度，优先级咨询人员最优发言权。
1. 确认Bug；
2. 评估优先级和紧急程度；
3. 将Bug指派给研发组长。
3.4 分配Bug
角色：技术部长/组长
此部分参考新需求研发流程
3.5 修复Bug
角色：研发人员
此部分参考新需求研发流程
3.6 代码复核
角色：技术部长/组长
此部分参考新需求研发流程
3.7 验证bug，关闭
角色：测试人员
当开发人员解决bug之后，就需要来验证bug，如果没有问题，则将其关闭。
已关闭的bug，默认是不再显示在bug列表的。
3.8 激活bug
如果开发人员解决bug之后，验证无法通过，则可以将bug重新激活，交由后的解决者去重新解决。还有一种情况就是bug关闭之后，过了一段时间，bug又重现了，也需要重新激活。
激活bug的时候，指派给会自动设置成为后的解决者头上。
3.9 业务复核
角色：咨询人员
此部分参考新需求研发流程
3.10 版本发布
角色：运维人员
此部分参考新需求研发流程
第4章 参考文档
此文档是基于禅道的管理思想完成的。在禅道管理的基础上进行适当调整。制定适合产贸送自己的工作流程。感兴趣或者想要深入了解的同事可以到禅道官方查看说明文档。再此对禅道表示感谢！
http://www.zentao.net/book/zentaopmshelp/165.html
163
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
