禅道使用教程

第一次打开禅道后台，禅道我盯着那个“产品-项目-测试”的使用三层结构看了十分钟。当时团队只有五个人，教程用禅道纯粹是禅道因为老板听说“别人都在用”。结果第一个月，使用我们把所有需求都塞进“产品”里，教程任务全堆在“项目”下，禅道测试单和bug混在一起。使用直到某天研发翻着列表骂了一句：“这跟Excel有什么区别？教程”我才意识到，工具没错，禅道是使用我们没搞懂它怎么串起来。

禅道的教程核心逻辑其实就一句话：需求从产品来，任务在项目做，禅道bug归测试管。使用 这三者不是教程并列关系，是流水线。产品经理在“产品”模块提需求，评审通过后，研发负责人在“项目”里把需求拆成任务，指派给具体的人。任务完成后，测试在“测试”模块建版本、提bug，bug修完再关联回任务。整条链路走通一次，你就明白为什么它比表格强——每个动作都有上下文，点开一个bug能看到它属于哪个需求、哪个任务、谁改的代码。

建产品，别急着建项目

很多人上来就建项目，结果需求没地方挂。正确顺序是：先建“产品”，比如“电商App”。产品里再建“模块”，像“购物车”“订单”“支付”。模块不用太细，能区分功能区域就行。我见过一个团队把模块拆到按钮级别，最后没人愿意选，全填“其他”。

建完产品，去“产品-需求”里提第一条需求。标题写清楚“用户能通过微信登录”，别写“登录优化”这种模糊话。优先级、预计工时这些字段，一开始可以空着，但“评审”必须走。禅道的评审不是形式，是让研发和测试提前看到需求，避免做完才发现理解错了。我们团队现在规定：需求没评审，研发不许领任务。

项目里拆任务，颗粒度要狠

需求评审通过后，切到“项目”模块。新建项目时，关联刚才的产品。然后进“项目-任务”，点“分解需求”。禅道会自动把需求列出来，你勾选后拆成任务。这里有个坑：任务别写“完成登录功能”，要写“写微信登录接口”“调通回调地址”“前端加登录按钮”。每个任务控制在4-8小时，最多不超过两天。颗粒度粗了，进度条永远卡在50%。

指派任务时，禅道会发邮件和通知。但别依赖这个，我们团队每天站会时，研发负责人会对着禅道的“任务看板”过一遍：谁的任务快到期了，谁卡住了。看板拖拽比列表直观，尤其是任务多的时候。

测试和bug，别混着来

研发提测后，测试人员在“测试”模块建“版本”，关联对应的需求和任务。然后提bug时，必须选“受影响版本”和“关联需求”。这样研发修bug时，能直接看到这个bug是哪个需求引入的。我们有个惨痛教训：早期bug不关联需求，结果修完一个，另一个又冒出来，因为根本不知道改的是哪块逻辑。

bug状态流转要严格：激活→已解决→已关闭。测试验证通过才能关闭，别让研发自己关。我们规定：研发点“已解决”时必须写解决方案，比如“改了缓存逻辑”。测试如果发现没修好，直接点“激活”，备注写清楚复现步骤。来回几次，研发就学会一次改到位了。

那些没人告诉你的细节

禅道的“文档”模块可以当团队wiki用，但别把需求文档全塞进去。我们只放接口文档和部署手册，需求本身就在“需求描述”里写清楚。另外，“组织”里的“用户”要定期清理，离职的人不删，任务指派列表里全是灰色头像，看着烦。

报表功能我用得少，但“项目-进度”里的“燃尽图”值得看。如果曲线一直平着，说明任务没拆细或者没人更新状态。我们团队现在要求：每天下班前，每个人必须更新自己任务的状态和剩余工时。不更新？第二天站会站着说。

最后说个真事：上个月新来的后端问我，为什么禅道里任务完成了还要点“完成”按钮，直接改状态不行吗？我让他试了一次，结果燃尽图没变化，因为系统只认“完成”动作触发的工时归零。他愣了两秒说：“这设计真轴。”对，禅道就是轴，但轴得让你没法偷懒。