一、目的
1. 量化评估
· 对个人的评估
把工作拆分成一个一个的最细粒度任务，可以详细到小时的单位，并分配给开发人员。任务分配者（比如迭代负责人）注意每个任务难度、复杂度相近。管理者可以通过任务的完成数量，完成时间，对开发者有一个量化的工作量评估。
通过所完成任务的bug的率的统计，可以对开发人员的代码质量有一个大概的评估。
工作量和工作质量可以作为绩效评估的参考项之一。
· 对团队的评估
如果不能把握团队的工作量和完成情况，管理者往往只能靠感觉评估团队的需求处理能力。通过把所有的工作拆分成任务并在线上分配给开发人员，再结合一些统计报表，管理者对团队执行力可以有一个数据化的感知。方便管理者对外承诺，也可以作为团队是否需要扩张的参考依据。
2. 降低成本
· 流程化管理
· 快速追踪
线上项目管理，把“文档”，“产品”，“模块”，“需求”，“测试用例”，“bug”，“开发分支”进行关联。每一个环节都可以往前往后进行追踪。免去了测试人员不知道bug应该提给谁、开发人员找不到产品人员、不知道某开发分支关联了那些需求、需求变更历史无法追溯等一些问题。
· 内部协调
各责任人根据“需求列表”为主线进行沟通协调。产品做完UE后，拆解成具体的的需求列表。测试人员可以根据需求列表中的每一项需求编写测试用例并执行；迭代负责人可以通过需求列表进行任务的拆解和分配；后端可以根据需求列表拆分成具体的API；前端可以拆分页面上的功能点。
· 打开持续优化通道
有了标准流程，并且执行过程可视化，才能不断的优化流程或优化团队人员，最终达到提高整体团队效率的终极目的。
二、使用禅道达到上述目的
1. 思想
禅道的基本设计思想是，产品、开发、测试三权分立。产品人员负责创建产品、拆分需求、制定发布计划并发布产品；迭代负责人负责创建迭代、关联该迭代需要完成的需求、分解任务指派到人、制定发布版本，并提交测试； 开发人员执行任务并完成任务；测试人员编写测试用例，提交bug，追踪bug。
2. 核心概念
· 产品
产品：对外交付的完整产品，比如，xx内部管理系统;
模块：产品拆分成的功能模块，比如财务模块;
需求：模块继续拆分成具体的需求点。
计划：产品人员对外承诺的发布计划。发布计划关联一份需求清单，大多数情况下，迭代跟发布计划一一对应。
发布：项目结束后产品人员创建发布，目的是告知公司其他部门新版本的产品可以投入使用。
· 开发
任务：根据需求拆分的开发任务
迭代：同敏捷开发的迭代(Sprint)
版本：任务执行完成之后，提测之前创建发布版本。根据版本提交测试单给测试人员。版本测试完成之后由产品人员进行发布。
· 测试
用例：测试人员根据需求创建的测试用例
bug：测试用例转的bug，或测试过程中发现的bug
· 其他
文档库：保存相关的文档，UE、UI、架构设计、API设计等。文档可以是文件也可以是外部链接。
统计报表：燃尽图等
组织：组织结构，可以根据自己部门的情况自定义，比如前端、后端、测试等。
三、使用-主流程
1.产品人员
· 产品管理
创建产品：产品人员创建产品。产品包括：名称、代号、产品负责人、测试负责人、发布负责人等属性。
导入需求：产品人员把整个产品拆分成大的功能模块，然后将功能模块拆分成详细的需求列表。需求可以分层，建议不超过三层。
发布计划：产品人员创建发布计划，并关联本次计划需要完成的需求列表或计划修复的bug。
发布版本：开发人员完成某次迭代后，生成可测试版本。该版本经过测试后，由产品进行验收并提交发布。
· 需求管理
创建需求：需求包括需求来源、备注需求发起人、关联的产品、关联的模块、关联的计划、由谁评审等属性。
变更需求：需求变更的时候，系统会记录下变更的内容。
需求评审：指定评审人，由评审人员执行评审的操作。
2. 迭代负责人
创建迭代，并拆分成细粒度的任务列表，并分配任务给开发人员。
开发过程中，通过燃尽图等及时关注任务的执行情况。检查是否跟理想状态有所偏差，及时发现问题，并处理异常情况。
开发完成后，创建版本(或分支)，提交测试单给测试人员，测试人员会根据测试单进行测试。
3. 开发人员
开发人员需要参与需求评估和需求拆分的会议。需求被拆分成具体的任务后，由开发人员认领各自的任务，进行开发，并维护该任务的生命周期（开始、完成、挂起等）。
4. 测试人员
· 编写测试用例
在产品人员导入产品/需求之后，测试人员就可以开始在需求上编写针对于该需求的测试用例。
在开发人员提交测试单后，执行所有测试单中的测试用例。
· 提bug
提交bug给开发人员，根据需求所关联的开发人员，可以找到该bug指派的对象。bug创建后管理整个bug的生命周期。
四、使用-其他
1. 文档库的使用
产品产生过程中的阶段文档（UE、UI等）可以放到该产品的主库中。
迭代文档库中存放本次迭代产生的架构设计、数据库设计、API设计等
测试阶段产生的报告，比如测试总结报告等可以放到迭代的文档库中。
2. 统计报表的使用
· Bug分析
Bug数量统计、bug指派统计可以衡量团队或团队成员的代码质量。
· 任务统计
燃尽图、迭代任务数统计、任务指派统计、消耗时间统计、每天完成统计等图标可以把握当前迭代的完成情况。
· 产品需求统计
需求数量统计、需求来源统计、所处阶段统计、当前指派统计、变更次数统计等可以衡量产品复杂度、需求质量等。使产品需求和需求完成的过程更加透明。
五、其他问题
如何倒逼产品需求合理化？
需求变更次数的记录可以一定程度上反应该需求是否经过深思熟虑的需求。
如何导出日报、周报、月报？
配合第三方插件，自动生成日报、周报、月报。或对禅道二次开发，导出各种工作日志。工作日志更加客观，还省去了写报告的时间精力。
提高积极性
工作量和工作质量的统计作为绩效评估的参考，或作为末位淘汰的依据之一，可以一定程度上激发员工积极性。
六、总结：
首先要感谢禅道团队开发出这么优秀的系统并开源。禅道只是一个工具，真正理解了这个工具背后的管理逻辑才能更好的使用这个工具。把线下的开发管理工作搬到线上，使不可见变成可见，使工作可量化，必然会对提升团队效率有一定的帮助。我们的使用项目管理工具的终极目的也是提升整个团队的效率。一套管理机制的实施不可能让所有人都舒服，但管理者不能当老好人，应该代表公司中奋斗者的利益，努力让奋斗者获得应得的利益。最后一句话：对所有人的公平就是最大的不公平！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
