简介这份《禅道使用手册完整版》面向项目经理、产品经理、开发与测试人员以及初次接触禅道、需要系统掌握项目管理工具操作流程的团队帮助解决项目进度跟踪、任务分配、需求与缺陷协同管理中的实际问题。资源包共1个docx文档约4.02MB内容按角色组织涵盖基本介绍、个人管理、产品经理使用、项目经理使用等章节从软件介绍、用户角色、登录与最简流程到待办创建与浏览、我的任务与我的BUG、需求创建评审与变更、产品模块维护、发布计划与燃尽图等均有展开目录层级清晰便于按模块查阅。已有5218人学习下载适合作为团队内部培训或日常查阅的参考手册读者可据此快速熟悉禅道各角色的操作路径与协作方式减少上手成本。1. 拿到一份禅道手册先别急着从头读很多团队装完禅道第一件事是拉个会把手册从头到尾过一遍。结果两小时过去大家记住了“禅道是一款基于 Scrum 的项目管理软件”回到工位还是不知道明天该点哪里。这份《禅道使用手册完整版》的价值不在“读完”而在“按角色查”——它把产品经理、项目经理、开发、测试四条线的操作路径拆得很细从建产品、提需求、建项目、分解任务到提交 bug、验证关闭每一步都对应到具体菜单和字段。你不需要通读你需要的是知道自己这个角色在禅道里每天该动哪几个页面以及哪些字段填错了后面会连环翻车。这篇笔记就是按这个思路把手册里的操作路径重新排了一遍补上手册没写透的参数含义和踩坑点适合正在落地禅道、或者装了但用不起来的小团队照着复现。2. 角色与流程对齐先搞清楚谁在哪个页面干活禅道最容易让人放弃的地方不是功能少而是角色和页面的对应关系没建立起来。手册第 1.2 节列了五类角色系统管理员、产品人员、项目经理、开发人员、测试人员。但光知道角色名没用得知道每个角色每天打开禅道第一眼该看哪里。这一章先把流程骨架立住后面几章再逐个角色拆操作。2.1 五类角色的权限边界与日常入口手册里对权限的描述比较简略只说了系统管理员负责添加用户、分配权限。实际落地时权限分配是第一个容易埋雷的地方。禅道的权限模型是“角色 分组”新建用户时要选所属分组分组决定了能看到哪些菜单。常见做法是系统管理员单独一个账号不参与日常业务产品经理给产品视图的全部权限项目经理给项目视图加部分产品视图只读开发和测试给“我的地盘”加对应视图的读写权限。这里有个反直觉的点开发和测试不需要给“产品视图”的完整权限。手册 5.1 到 5.7 节里开发要做的领取任务、创建版本、解决 bug、确认 bug全部可以在“我的地盘”和项目视图里完成。给多了权限反而容易出现开发直接去改需求描述的翻车情况——需求描述是产品经理的领地开发改了测试按旧描述写用例后面就是一笔糊涂账。日常入口可以按这个对应关系记角色每天第一眼看的页面核心动作产品经理产品视图 → 需求 / 计划提需求、评审、建计划、建发布项目经理项目视图 → 任务 / 燃尽图建项目、组团队、分解任务开发我的地盘 → 我的任务领取任务、更新工时、建版本、解 bug测试我的地盘 → 我的 BUG / 我的测试提 bug、验证、关 bug、执行用例系统管理员后台 → 用户 / 权限加人、分组、改密码这张表不是手册原文是我按手册各章节的操作路径反推出来的。手册是按功能模块组织的实际用起来是按角色组织的这个转换不做团队就会在菜单里迷路。2.2 从需求到发布的完整链路怎么串手册 1.4 节给了基本流程产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做的需求 → 分解任务指派到人 → 测试提交 bug。这六步是主干但中间有几个衔接点手册没强调恰恰是链路断掉的高发区。第一个衔接点是“需求必须激活才能关联到项目”。手册 3.2 节写得很清楚创建需求时如果勾了“不需要评审”需求状态直接是激活如果走了评审评审结果选“确认通过”才变激活。只有激活状态的需求才能关联到项目里开发。很多团队卡在这里项目经理建完项目发现需求列表是空的以为是权限问题其实是需求还躺在草稿状态。第二个衔接点是“项目关联需求”这个动作。手册 4.3 节叫“确定项目要完成的需求列表”操作入口在项目视图里。这里要注意关联需求时是从产品维度选的一个项目可以关联多个产品的需求但大部分小团队一个项目对应一个产品选的时候别漏。第三个衔接点是“版本”和“发布”的先后。手册 3.7 节明确写了创建发布的两个前提产品有关联过项目且该项目创建过版本。版本是开发在 5.3 节创建的发布是产品经理在 3.7 节创建的。顺序反了发布页面会提示前提不满足。这个依赖关系建议直接写进团队的新人须知里。2.3 最简使用的四种裁剪方式手册 1.3 节提了四种最简使用只做产品管理、只做项目任务管理、只做 bug 管理、个人事务跟踪。这个设计很务实因为不是每个团队一上来就能跑全流程。我的建议是按团队成熟度选裁剪方式刚起步的两三人小队直接用“只做 bug 管理”最省事。测试在 6.2 节提交 bug开发在 5.5 节解决 bug测试在 6.3 节验证关闭这条闭环最短一周就能跑顺。等 bug 流程稳定了再往上加项目任务管理让开发在 5.2 节领取任务、每天更新。产品管理那条线需求、计划、发布放到最后加因为它对产品经理的投入要求最高需求写不细整条线就是空转。个人事务跟踪2.1 节的待办适合作为过渡期的补充让每个人先养成“打开禅道看今天要干什么”的习惯比一上来就推全流程阻力小得多。3. 产品经理线需求、计划、发布三件套怎么落地产品经理是禅道里操作最重、也最容易把数据搞乱的角色。手册第三章从 3.1 到 3.10 节覆盖了维护产品、创建评审需求、变更评审需求、需求状态阶段、维护模块、建立计划、建立发布、路线图、文档管理、统计报表。这一章挑出其中真正影响后续流程的环节把字段含义和操作顺序讲透。3.1 建产品时那几个字段填错会连锁反应手册 3.1 节列了添加产品时需要注意的字段产品代号、产品负责人、测试负责人、发布负责人、访问控制。这几个字段不是随便填的每一个都在后续流程里被引用。产品代号相当于产品的英文标识手册举例说禅道自己的代号是 zentao。这个字段一旦定了后面改起来麻烦建议用简短的英文或拼音别用中文。产品负责人是需求的最终解释人评审需求时默认指派给他。测试负责人决定了提交 bug 时的默认指派人——手册原话是“可以适用于公司人比较多提交 bug 不知道该给谁的情况”。发布负责人负责创建发布3.7 节的发布操作默认由他执行。访问控制这个字段值得单独说。手册提到可以把产品设为私有只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才能访问。小团队一般设成公开但如果涉及外部客户或者跨部门协作私有产品能避免无关人员看到需求细节。这里有个坑设成私有后新加入项目团队的成员如果没被单独加进访问列表会看不到产品下的需求表现是“项目里关联不了需求”排查时先看访问控制别急着查权限分组。3.2 需求按功能点拆评审流程别省手册 3.2 节的核心观点是“按照功能点的方式来写需求”把需求设计文档里的每个功能点摘出来作为独立需求录入。这个粒度建议严格执行因为禅道的任务分解、用例管理、bug 关联都是挂在需求上的需求粒度太粗后面任务拆不动用例也写不细。创建需求时有两个字段要留意。一个是“所属计划和模块”手册说可以暂时保留为空但我的经验是模块尽量填哪怕先建个粗分类。模块在 3.5 节有专门维护流程它是需求的分类维度3.10 节的统计报表里“模块需求数量”就是按这个维度出的。另一个是“不需要评审”复选框勾了需求直接激活不勾就走评审流程。评审流程手册 3.2 节给了三种结果确认通过、有待明确、拒绝。确认通过变激活有待明确保持草稿并指派回创建者拒绝要填原因。这里的关键是“有待明确”这个状态的设计意图——它允许不成熟的想法先存着不阻塞其他需求的推进。很多团队评审时非黑即白要么通过要么拒绝其实“有待明确”才是使用频率最高的选项。需求状态和阶段是两个字段手册 3.4 节专门讲了。状态有草稿、激活、已变更、已关闭四种阶段有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布九种。阶段是自动流转的规则手册写得很细没关联计划和项目是未开始关联计划没关联项目是已计划关联项目没分解任务是已立项有开发任务进行中是研发中开发任务全完成测试没开始是研发完毕有测试任务进行中是测试中测试全结束开发没结束还是测试中都结束是测试完毕。验收阶段要产品经理手工确认。这套自动流转逻辑不用背但要知道它存在因为看板上的阶段不对时八成是任务或测试的状态没更新。3.3 需求变更走专用流程别用编辑绕过去手册 3.3 节有一句话很关键“编辑操作是无法修改需求的标题、描述、验收标准和附件的。”也就是说这四个字段要改必须走变更流程。变更后需求状态变“变更中”然后走评审评审结果有确认通过、撤销变更、有待明确、拒绝四种。确认通过变回激活撤销变更回退到之前版本。这个设计的意义在于留痕。直接编辑改掉历史版本就没了测试按旧描述写的用例对不上开发按旧描述写的代码也不知道差在哪。变更流程会列出影响范围手册提到变更时会展示该需求关联的任务、bug、用例评审者可以参考。变更确认后研发和测试还要分别确认需求变动手册 3.3 节第 3 点列了任务确认、Bug 确认、用例确认三个动作。实操建议变更评审尽量和线下评审会绑定会上定完会后在禅道里记录参与人和结果。手册也说了“一般来讲需求评审可以是一个线下的评审会议在禅道里面记录下参与需求评审的人员即可”。别指望禅道替代沟通它只是把结论固化下来。3.4 计划、发布、路线图的依赖关系手册 3.6 节讲计划3.7 节讲发布3.8 节讲路线图。三者的关系是计划和发布组成路线图绿色是已发布版本黄绿色是将来计划。计划的作用是规划发布节奏、调整需求优先级同时帮助项目关联需求。发布的前提是产品关联过项目且项目创建过版本。计划关联需求有两个入口建完计划后在计划里关联或者提需求时直接指定计划已过期的计划不会列出。手册特别说明计划和项目没有强对应关系一个计划可以对应一个项目但多数情况是项目关联的需求大部分来自一个计划同时夹杂其他计划的部分需求。这个灵活性是好事但也意味着计划不能当项目用别指望用计划来跟踪执行进度执行进度看项目视图的燃尽图4.5 节。发布创建后路线图自动更新。3.10 节的需求统计报表有三个维度产品需求数量、模块需求数量、按计划统计。这三个报表够用了不用额外折腾。4. 项目经理与开发线任务分解、燃尽图、版本与 bug 闭环这一章把项目经理和开发的操作用一条线串起来因为这两者的动作是咬合的项目经理分解任务开发领取任务、更新、建版本、申请测试、解 bug。手册第四章和第五章的内容合并看才能看清任务从创建到关闭的完整生命周期。4.1 建项目、组团队、定需求列表的顺序手册 4.1 到 4.3 节给了三步建立项目、组建团队、确定需求列表。顺序不能乱因为组建团队时要选人确定需求列表时要关联产品需求这两步都依赖项目已经建好。建项目时手册没展开的字段是项目名称和代号建议和产品代号保持一致的命名习惯方便检索。组建团队在 4.2 节把产品经理、开发、测试都加进去注意这里加的是团队成员不是权限分组两回事。确定需求列表在 4.3 节从产品维度选已激活的需求关联进来。这里有个高频问题项目建好了需求列表里选不到想要的需求。排查顺序是先看需求状态是不是激活草稿和变更中都关联不了再看产品访问控制有没有把当前用户排除最后看需求是不是已经关联到别的项目了——一个需求可以关联多个项目但如果团队约定一个需求只进一个项目就要注意别重复关联。4.2 任务分解的粒度与指派规则手册 4.4 节叫“组织进行任务分解”这是项目经理最核心的动作。任务挂在需求下面一个需求可以拆多个任务每个任务指派到人、估工时。粒度建议控制在半天到两天太粗了燃尽图看不出进展太细了管理成本高。任务分解时容易忽略的是任务类型。禅道的任务有设计、开发、测试、研究等类型类型影响后续的统计。开发任务和测试任务要分开建因为需求阶段的自动流转3.4 节依赖任务类型来判断“研发中”还是“测试中”。如果测试任务建成了开发类型需求阶段会一直卡在研发中看板上就对不上了。指派规则上手册 5.2 节说开发“领取任务并每天更新任务”。实际操作中项目经理分解时直接指派比让开发自己领更可控尤其是任务有明确依赖关系时。开发每天更新的是已消耗工时和剩余工时这两个数字是燃尽图的数据源。4.3 燃尽图读不懂先查这三个数据源手册 4.5 节说“通过燃尽图了解项目的进展”4.6 节说“通过各种列表了解项目进展”。燃尽图是项目经理最常看的图但它不准的时候也最让人抓狂。燃尽图的数据来自任务的剩余工时所以图不对先查三个地方第一任务有没有每天更新剩余工时。开发不更新剩余工时不变燃尽图就是一条平线。第二任务分解时估的工时是否合理。总工时估少了燃尽图一开始就在低位看不出趋势。第三有没有任务被关闭但没填实际工时。关闭任务时实际工时为 0剩余工时会突然掉一大截图会出现断崖。手册 4.7 节的项目任务基本报表统计可以作为燃尽图的补充按人、按任务类型出工时分布排查是谁的工时没填比盯着燃尽图猜快得多。4.4 开发建版本、申请测试、解 bug 的动作链手册第五章从 5.1 到 5.7 节开发的动作链是参加计划会议分解任务 → 领取任务每天更新 → 创建版本 → 申请测试 → 解决 bug → 文档管理 → 确认 bug。这条链里创建版本5.3 节和申请测试5.4 节是衔接开发和测试的关键。创建版本时版本号建议和代码仓库的 tag 对齐比如 v1.2.0。版本关联的是项目不是产品发布时才关联到产品3.7 节。申请测试是把版本提交给测试测试收到后开始执行用例、提 bug。解决 bug 在 5.5 节解决时选解决方案已解决、重复、设计如此、无法重现等填解决版本。这里有个坑解决版本填错测试验证时对不上代码分支会反复打回。建议解决版本和创建版本用同一套版本号。5.7 节的确认 bug 是开发对测试关闭的 bug 做最后确认防止测试误关。4.5 测试侧bug 视图、用例、测试任务的配合手册第六章是测试的主场。6.1 节维护 bug 视图模块6.2 节提交 bug6.3 节验证关闭6.4 节激活 bug6.5 节找自己需要的 bug6.6 到 6.9 节是用例和测试任务6.10 节看报表。提交 bug 时bug 视图模块6.1 节决定了 bug 归到哪个分类这个分类和产品模块3.5 节是两套体系别混。bug 的严重程度和优先级是两个字段严重程度是技术影响优先级是业务紧急度测试填严重程度产品经理或项目经理定优先级分工要明确。用例管理6.7 节创建用例、6.9 节执行用例提交 bug和测试任务6.8 节管理测试任务是配套的。测试任务挂在版本上执行用例时如果失败直接转成 bugbug 自动关联用例和需求。这条链路跑顺了需求、用例、bug 三者是可追溯的3.3 节需求变更时的影响范围才能列全。5. 避坑与排查五个真实会卡住流程的问题手册是操作说明不会告诉你哪里会翻车。这一章列五个我在落地时反复遇到的问题按“现象 → 原因 → 解决”写都是能直接对照排查的。5.1 需求关联不到项目现象项目经理在项目里关联需求列表是空的或者缺了某几条。原因需求状态不是激活草稿、变更中、已关闭都关联不了或者产品访问控制把当前用户排除了或者需求已经关联到别的项目且团队约定不重复关联。解决先在产品视图确认需求状态再看产品访问控制列表最后查需求详情页的关联项目记录。5.2 燃尽图一条平线现象项目跑了一周燃尽图几乎没下降。原因开发没有每天更新任务的剩余工时或者任务分解时没估工时。解决让开发在“我的任务”里每天更新已消耗和剩余工时项目经理在 4.7 节的报表里按人查工时填报情况谁没填一目了然。5.3 发布创建不了现象产品经理点创建发布提示前提不满足。原因产品没有关联过项目或者关联的项目没有创建过版本。解决按 3.7 节的两个前提倒查先确认项目存在且关联了需求再确认开发在 5.3 节创建过版本。顺序不能反。5.4 需求阶段卡在“研发中”不动现象开发任务都完成了需求阶段还是研发中没变成研发完毕。原因测试任务建成了开发类型或者测试任务还没建。解决检查任务类型测试任务必须是测试类型如果测试任务还没分解补建测试任务阶段会自动流转。5.5 测试验证 bug 后开发又打回现象测试关闭 bug开发确认时打回来回拉扯。原因解决版本填错测试验证的不是开发修复的那个版本或者 bug 描述不清开发理解偏了。解决统一版本号命名规范解决版本和创建版本对齐提交 bug 时附上复现步骤和环境信息6.2 节的描述字段别偷懒。6. 把手册用成检查清单我的日常核对习惯手册读一遍就够但用起来得有个核对机制。我现在的习惯是把手册里的关键节点抽成一张检查清单每个迭代开始和结束时各过一遍比临时翻文档快。迭代开始时核对四项产品经理的需求是否都是激活状态且关联了计划项目经理的项目是否关联了需求并完成了任务分解任务类型是否开发测试分开团队成员是否都在项目团队里。迭代结束时核对三项开发是否创建了版本并申请测试测试的 bug 是否都验证关闭或激活产品经理是否基于版本创建了发布。这套清单不是手册原文是从 3.4 节的需求阶段流转规则反推的——阶段自动流转的前提是每个环节的数据都填了缺一环阶段就卡住。比如“已立项”要求需求关联项目且分解了任务那迭代开始时就该确认这两件事都做了而不是等阶段不对了再回头查。还有一个习惯是每周看一次 3.10 节的需求统计报表和 4.7 节的项目任务报表。需求报表看模块分布哪个模块需求扎堆说明那块是重点或者需求拆得不够细任务报表看工时分布谁的任务工时异常高可能是估算不准或者任务粒度太粗。这两个报表不用天天看每周一次足够发现趋势。最后说个验证方法新团队落地禅道第一周只跑 bug 闭环6.2 提交、5.5 解决、6.3 验证关闭第二周加任务领取和更新5.2 节第三周加需求评审3.2 节第四周加计划和发布3.6、3.7 节。每周结束对照手册对应章节检查数据完整性哪一步的数据填不齐就停在那一步补别急着往下推。禅道的流程是环环相扣的前一环的数据是后一环的输入跳步的代价是后面所有报表都不准。从那以后我每次给新团队配禅道都强制先跑两周纯 bug 闭环再往上加流程急不得。希望这份按角色重排的操作路径能帮你少走几趟菜单迷宫。本文还有配套的精品资源点击获取