★ FEATURED ARTICLE 简介这份《禅道使用手册完整版》面向项目经理、产品经理、开发与测试人员以及初次接触禅道、需要系统掌握项目管理工具操作流程的团队帮助解决项目进度跟踪、任务分配、需求与缺陷协同管理中的实际问题。资源包共1个docx文件约4.02MB内容按角色组织涵盖基本介绍、个人管理、产品经理使用、项目经理使用等章节并延伸至需求状态与阶段、产品模块维护、发布计划与发布、燃尽图进展跟踪及需求统计报表等模块目录层级清晰便于按角色检索。已有5218人学习下载说明其在项目管理入门与团队落地场景中具有较高参考价值。读者可借助这份手册快速理解禅道的最简使用与基本流程掌握待办管理、我的任务与我的BUG关注、需求创建评审与变更、项目团队组建和任务分解等操作要点适合作为团队内部培训或日常查阅的配套文档。1. 拿到一份禅道手册先别急着从头翻很多团队装完禅道第一件事是拉个会把手册从头念一遍。念完散会第二天该乱还是乱需求挂在草稿里没人管任务分解到一半停了测试提的 bug 开发说没收到。问题不在工具在于没人把「角色—动作—状态流转」这条线串起来。这份《禅道使用手册完整版》的价值恰恰是把产品经理、项目经理、开发、测试四类角色在禅道里的动作拆成了可照做的步骤从建产品、提需求、立项分解任务到提 bug、验证关闭一条链走完。它适合正在落地项目管理流程的中小研发团队也适合刚接手禅道配置、需要快速摸清「谁在哪个页面干什么」的从业者。下面我按手册的骨架把能直接抄的部分和容易翻车的地方拆开讲。2. 角色与主流程先把四类人的动作对齐2.1 五个角色各自管什么手册把系统里的角色分成系统管理员、产品人员、项目经理、开发、测试五类这个划分不是摆设它直接决定了每个人登录后该看哪个视图。系统管理员管账号和权限产品人员管产品、需求、计划、发布项目经理管项目、团队、任务分解开发和测试围绕任务与 bug 转。实际落地时最常见的错配是让产品经理去建项目、让项目经理去提需求结果需求状态和项目阶段对不上燃尽图画出来是平的。我一般建议在开账号之前先画一张角色对照表把「谁负责创建、谁负责评审、谁负责执行」写死再往禅道里灌人。手册里 1.2 节列的角色职责可以直接拿来当这张表的底稿。2.2 六步主流程与状态联动手册 1.4 节给的基本流程是产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做的需求 → 分解任务指派到人 → 测试提交 bug。这六步看着简单真正的约束在状态上只有「激活」状态的需求才能关联到项目里开发草稿状态的需求在项目关联需求的下拉里根本不会出现。所以流程能不能跑通取决于需求评审那一步有没有做。下面这段是我常用的检查脚本思路用禅道开放 API 拉一遍需求状态分布确认没有大量需求卡在草稿# 拉取某产品下的需求列表按状态统计需替换 host、账号、产品ID curl -s -c /tmp/zt.cookie -d accountadminpassword你的密码 \ http://你的禅道地址/index.php?muserflogin /dev/null curl -s -b /tmp/zt.cookie \ http://你的禅道地址/index.php?mproductfbrowseproductID1branch0browseTypeallparam0orderByid_descrecTotal0recPerPage200pageID1 \ | grep -o status-[a-z]* | sort | uniq -c这段命令先登录拿 cookie再请求产品需求列表页最后用 grep 抓状态样式类名做计数。参数里productID换成你的产品 IDrecPerPage调大一点避免分页漏数。它不精确但能快速看出「草稿」占比是不是异常高——如果一半需求是草稿说明评审环节被跳过了后面项目关联需求时必然缺料。2.3 最简使用的四种裁剪手册 1.3 节提到四种最简用法只做产品管理、只做项目任务管理、只做 bug 管理、只做个人事务跟踪。这一点很实用很多团队一上来就全模块铺开结果没人维护数据烂掉。我的经验是先选一种跑两周比如先只把 bug 流程跑顺测试提 bug、开发解决、测试验证关闭三个动作闭环了再往上加需求和项目。手册里 6.2 到 6.4 节正好是这条最小闭环的操作说明拿来当第一阶段的落地范围刚好。3. 产品侧落地需求、模块、计划、发布怎么串3.1 建产品时那几个字段别乱填手册 3.1 节讲添加产品重点在几个字段的语义产品代号是团队对产品的隐喻产品负责人负责整理和解释需求、制定发布计划测试负责人用于人多时默认指派 bug发布负责人负责创建发布访问控制可以把产品设为私有。这里最容易踩的是「访问控制」——设成私有后只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品关联的项目团队能访问其他人打开就是空白。有团队建完产品发现开发看不到需求排查半天以为是权限 bug其实是私有产品没把开发加进项目团队。3.2 需求按功能点拆评审决定能不能进项目手册明确要求「按照功能点的方式来写需求」把需求文档里的每个功能点摘出来单独录入。创建需求时标题必填所属计划和模块可以先空着关键是「不需要评审」这个复选框勾上需求直接是激活状态不勾走评审流程评审通过才变激活。手册 3.2 节的评审结果有确认通过、有待明确、拒绝三种对应状态分别是激活、打回创建者继续完善、关闭并记录原因。变更需求走的是另一条路。手册 3.3 节强调标题、描述、验证标准、附件的修改都必须走变更流程普通「编辑」操作改不了这几项。变更后状态变「变更中」评审通过才回到激活。变更页面会列出影响范围评审者据此判断。这里有个细节值得记变更时如果勾了「不需要评审」状态直接回激活省一道流程但也就失去了变更留痕的评审记录团队规范严的话别开这个口子。3.3 需求状态与阶段是两个字段手册 3.4 节把这件事讲得比较透值得单独拎出来。状态字段只有四种草稿、激活、已变更、已关闭对应创建、变更、审核、关闭、激活几个操作。阶段字段描述激活需求在研发中的位置共九种未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。阶段的推进是自动的规则大致如下条件需求阶段未关联项目也未关联计划未开始关联计划但未关联项目已计划关联项目但未分解任务已立项有开发任务进行中、测试任务未开始研发中开发任务全完成、测试任务未开始研发完毕有测试任务进行中测试中开发与测试任务全部结束测试完毕产品经理手工确认已验收关闭原因为「已发布」已发布这张表是排查「需求阶段不动」的第一手依据。阶段卡在「已立项」不动八成是任务没分解卡在「研发完毕」不动去看测试任务有没有建。3.4 模块、计划、发布三件套模块是对需求的分类手册 3.5 节说维护模块要一级级来左侧数字是排序字段编辑时可以改上级模块。计划是产品经理规划发布节奏的工具创建计划后可以关联需求也可以在提需求时直接指定计划过期计划不会列出。发布有两个前提产品关联过项目、项目创建过版本缺一个都建不了发布。手册 3.6 节还点明计划和项目没有强对应关系一个计划可能对应一个项目也可能项目关联的需求来自多个计划——这点在跨版本迭代的团队里很常见别硬凑一对一。路线图由计划和发布组成绿色是已发布版本黄绿色是未来计划点进去能看具体需求。需求统计报表在产品视图的需求子栏目下支持按产品、按模块、按计划三种口径统计数量。这三样加起来基本能回答「这个版本要做什么、做到哪了、发了多少」三个问题。4. 项目与执行侧任务分解、燃尽图与 bug 闭环4.1 建项目、组团队、定需求列表项目经理的动作从建项目开始然后组建团队再确定项目要完成的需求列表。手册 4.3 节这一步的前提是需求已经激活否则关联不上。团队组建决定了谁能被指派任务、谁能看到私有产品所以顺序不能反先建项目、加团队再关联需求、分解任务。4.2 任务分解到人燃尽图才有意义手册 4.4 节的任务分解是整个流程里最容易被敷衍的一步。任务不分解需求阶段停在「已立项」燃尽图画出来是一条平线项目经理拿着图开会只能干瞪眼。分解的粒度我一般按「一个人两天内能完成」来切每个任务有预计工时、指派到人、有起止时间。手册 4.5 节用燃尽图看进展4.6 节用各种列表看进展4.7 节是项目任务的报表统计——这三样是项目经理的日常看板但前提都是任务数据是真实的。下面这段是批量检查「有需求但无任务」的排查思路用页面抓取做粗筛import re, requests s requests.Session() # 登录替换为你的地址与账号 s.post(http://你的禅道地址/index.php?muserflogin, data{account: admin, password: 你的密码}) # 拉项目需求列表 html s.get(http://你的禅道地址/index.php?mprojectfstoryprojectID1).text # 抓需求链接与任务数标记具体 class 以你版本页面为准 stories re.findall(rstoryID(\d)[^]*.*?/a, html, re.S) print(需求条数:, len(stories)) # 逐条打开详情检查任务页签是否为空 for sid in stories[:20]: detail s.get(fhttp://你的禅道地址/index.php?mstoryfviewstoryID{sid}).text if 暂无任务 in detail or no task in detail.lower(): print(无任务需求:, sid)逻辑是先登录维持会话再抓项目需求列表逐条打开详情页找「暂无任务」标记。projectID换成你的项目 IDstories[:20]是抽样上限避免请求过多。这段脚本依赖页面文案禅道版本不同文案可能变跑之前先手动打开一个需求详情确认关键字。它的用途不是替代人工而是在迭代中期快速定位「需求挂着但没人干活」的漏网之鱼。4.3 开发的动作领任务、建版本、申请测试、解 bug开发侧手册 5.1 到 5.7 节的动作链是参加计划会议分解任务 → 领取任务并每天更新 → 创建版本 → 申请测试 → 解决 bug → 文档管理 → 确认 bug。其中「每天更新任务」是燃尽图数据质量的命门任务剩余工时不变图就不动。创建版本是发布的前提之一申请测试是把版本交给测试的信号解决 bug 时填的解决方案会决定测试验证时的操作路径。4.4 测试的动作提 bug、验证、激活、管用例测试侧手册 6.1 到 6.10 节覆盖维护 bug 视图模块、提交 bug、验证关闭、激活 bug、查找 bug、维护用例视图、创建用例、管理测试任务、执行用例并提交 bug、查看报表。这里的关键闭环是提交 → 开发解决 → 验证通过关闭或验证不通过激活。激活 bug 时一定要写清楚复现步骤和实际结果否则开发二次解决还是猜。用例和 bug 的关联也别省执行用例失败直接转 bug回溯时能对上号。5. 避坑排查五个真实翻车点5.1 需求在项目里关联不到现象项目经理在项目里关联需求下拉列表是空的或者少了一大半。原因需求还是草稿状态没走评审或者需求关联的计划已过期。解决先在产品视图确认需求状态是「激活」再检查计划是否过期过期计划不会在提需求时列出但已关联的需求不受影响。5.2 开发看不到私有产品现象产品设了私有访问控制开发登录后产品列表空白。原因私有产品的可见范围是产品添加者、产品负责人、测试负责人、发布负责人加项目团队开发不在项目团队里就看不到。解决把开发加进对应项目团队或者评估后把产品访问控制改为公开。5.3 燃尽图一条平线现象项目跑了一周燃尽图几乎不动。原因任务没分解或者分解了但没人更新剩余工时。解决先补任务分解再在每日站会后要求每人更新任务剩余工时项目经理每周抽查一次任务更新率。5.4 改了需求描述却没留变更记录现象需求描述被直接改掉评审记录里找不到变更痕迹。原因用了普通「编辑」而不是「变更」流程编辑操作本来就改不了标题、描述、验证标准和附件。解决培训时明确这几项必须走变更变更时按需选择是否评审团队规范严的不要勾「不需要评审」。5.5 建不了发布现象点创建发布提示条件不满足。原因发布要求产品关联过项目、且该项目创建过版本两个前提缺一不可。解决先确认项目里已创建版本再回产品视图建发布如果项目还没建版本让开发走一遍创建版本流程。6. 把手册用成检查清单我的日常核对习惯手册读一遍容易用起来难。我的做法是把手册里的关键节点抽成一张每周核对清单而不是每次翻文档找章节。具体是四列角色、动作、对应手册章节、本周是否完成。产品经理那列盯「需求是否全部激活、计划是否关联需求」项目经理那列盯「任务分解率、燃尽图是否更新」开发那列盯「任务剩余工时是否每日更新、版本是否创建」测试那列盯「bug 是否在 48 小时内验证」。核对时我会用前面那两段脚本做粗筛再人工看几个样本。脚本只负责把异常条目捞出来判断还得靠人。比如「无任务需求」捞出来十条可能八条是刚提的还没到分解环节只有两条是真漏了这个区分脚本做不了。还有一个习惯是版本升级或换环境后先跑一遍最小闭环建一个测试产品、提一条需求、建一个项目、关联需求、分解一个任务、提一个 bug、解决、验证关闭。整条链走通再让团队进来用。这套动作对应手册 1.4 节的主流程十分钟能跑完但能提前暴露权限、状态、字段配置的问题比等团队用出问题再排查省事得多。从那以后我每次接手一个新禅道环境都强制先走一遍这条最小闭环再开账号翻车的次数明显少了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
