任务看板列设置的本质，是把工作项从开始到完成的真实流转画成一条可执行的路径。动手配置前，先确定这张看板服务哪个团队、管理哪类工作项、各环节由谁推进；然后按流转顺序定义列名、进入条件和退出条件；最后用一条真实任务逐列走查，确认没有卡住或跳步的环节。列的数量以能看清当前瓶颈为准，通常控制在五到七列。
要点总览（TL;DR）
- 先确定看板服务的团队、工作项类型和真实流转顺序，再动手配置列，避免边配边改。
- 列名用动名词或状态词，每列写清进入条件、退出条件和负责角色，条件尽量用可核验的事实描述。
- 等待、阻塞、评审等中间状态是否单独成列，取决于它是否影响推进判断；列数量通常控制在五到七列。
- 上线前用一条已完成的历史任务逐列回放，记录卡住或跳步的位置并修正规则。
- 上线后一到两周按负责人、任务停留、变更知晓、阻塞可见四项检查，全部通过再视为可用。
列设置前先定三件事
列设置最容易出现的问题是边配边改：今天加一列“待评审”，明天拆一列“开发中”，结果看板越改越复杂，团队却说不清任务到底走到哪一步。避免这种情况的办法，是在打开配置界面之前，先把三件事写成文字。
第一件：这张看板服务谁、管什么。同一个团队可能同时有需求看板、缺陷看板、发布看板，它们的工作项类型不同，流转路径也不同。先写清楚看板名称、使用团队、覆盖的工作项类型（例如需求、任务、缺陷），避免把不同节奏的工作混在一张看板上。如果团队同时处理紧急缺陷和常规需求，可以分开建看板，而不是在一张看板上用颜色区分。
第二件：工作项从开始到完成的真实顺序。不要照搬模板，而是找两三位实际执行人，请他们各自描述一条任务从提出到交付经过哪些环节。把描述合并成一条顺序草案，标出哪些环节是真正推进工作的，哪些只是等待。这份草案是后续列定义的直接输入。
第三件：每个环节由谁负责推进。列不只是状态标签，它对应一个有人负责的动作。逐环节写明负责角色，例如“需求评审”由产品经理牵头、“开发中”由开发工程师推进、“验收”由测试或需求提出方确认。没有明确负责人的环节，往往就是任务会长期停留的地方。
把以上信息整理成一张前置信息表，配置时逐行对照，可以减少反复调整。
| 团队/工作项类型 | 流转顺序草案 | 各环节负责人 |
|---|---|---|
| 示例：移动端团队 / 需求 | 待梳理 → 待评审 → 开发中 → 待测试 → 验收中 → 已完成 | 待梳理：产品经理；待评审：产品经理牵头、开发与测试参与；开发中：开发工程师；待测试：开发移交、测试接收；验收中：需求提出方；已完成：产品经理确认 |
| 示例：平台团队 / 缺陷 | 待确认 → 修复中 → 待验证 → 已关闭 | 待确认：值班工程师；修复中：开发工程师；待验证：测试工程师；已关闭：测试工程师 |
表中内容为演示情景，实际填写时以团队真实分工为准。前置信息表完成后，列设置就有了明确的边界：只画这张表里出现过的环节，不临时增加。
按流转顺序定义列与列间规则
有了流转顺序草案，下一步是把它落成具体的列。每一列需要回答三个问题：叫什么、什么条件下进入、什么条件下离开。三者写清楚，列才具备可执行性。
列名怎么起
列名优先使用动名词或状态词，让团队成员一眼看出任务在该列处于什么阶段。常见写法有两类：一类描述动作，如“开发中”“评审中”“验收中”；一类描述状态，如“待排期”“待测试”“已阻塞”。同一张看板上保持一种风格，避免“开发中”和“正在写代码”这类含义重叠的列名并存。列名还应避免过于宽泛，例如“处理中”无法说明任务在等什么、由谁推进，可以拆成更具体的环节。
进入条件与退出条件怎么写
进入条件回答“任务满足什么才能放进这一列”，退出条件回答“任务做到什么程度才能离开这一列”。写法上尽量使用可观察的事实，而不是主观判断。例如“开发中”的进入条件可以写成“已完成技术方案确认并分配开发负责人”，退出条件写成“代码已提交并通过自测，提测说明已填写”。“待测试”的进入条件则是“提测说明完整、测试环境可用”。
条件写得越具体，看板上的任务位置就越可信。可以用一张列定义清单逐列维护：
| 列名 | 进入条件 | 退出条件 | 负责角色 |
|---|---|---|---|
| 待梳理 | 需求已登记，尚未明确范围 | 需求描述、验收要点已补齐 | 产品经理 |
| 待评审 | 需求材料完整，已约定评审时间 | 评审结论已记录，遗留问题有明确处理人 | 产品经理牵头 |
| 开发中 | 方案确认，开发负责人已分配 | 代码提交并通过自测，提测说明已填写 | 开发工程师 |
| 待测试 | 提测说明完整，测试环境可用 | 测试用例执行完毕，缺陷已登记 | 测试工程师 |
| 验收中 | 测试通过，验收人已知晓 | 验收结论已记录 | 需求提出方 |
| 已完成 | 验收通过 | —（终态） | 产品经理确认 |
表中为演示情景，条件内容需按团队实际交付标准填写。退出条件与下一列的进入条件应当衔接：上一列的退出条件，通常就是下一列进入条件的一部分，两者不一致时，任务会在列之间来回移动。
中间状态是否单独成列
等待、阻塞、评审这类中间状态是否单独成列，取决于它是否影响推进判断。如果“等待外部依赖”经常发生且持续时间较长，单独成列能让阻塞位置在看板上直接可见；如果只是偶发的短暂等待，放在备注或标签里即可，不必占用一列。评审环节同理：评审有明确的参与人和结论产出时，单独成列有助于跟踪；评审只是开发过程中的一次快速确认，可以并入相邻列。
列数量怎么取舍
列的数量以能看清当前瓶颈为准，通常控制在五到七列。判断方法很简单：如果某一列长期堆积任务，说明它前面的环节产能不足或进入条件过松；如果某一列几乎没有任务停留，且它的退出条件与相邻列重复，可以考虑合并。列过多会让看板横向滚动、信息分散，列过少则会把不同性质的等待混在一起，看不出问题出在哪。调整时一次只动一列，观察一到两周再决定下一步。
角色分工与各环节交付物
列设置不是一次个人配置动作，它涉及三类角色：看板负责人、各环节执行人、团队确认者。分工清楚，列规则才有人维护，也才有人对规则的合理性负责。
看板负责人通常由团队负责人或项目管理者担任，负责汇总前置信息、起草列定义清单、组织走查、执行列设置的变更，并保留变更记录。其交付物是列定义清单和变更说明。
各环节执行人是每列对应的实际推进者，负责确认本环节的进入条件与退出条件是否符合真实工作，并在日常使用中反馈条件不成立的情况。其交付物是本环节的完成标志说明，例如提测说明、评审结论、验收记录。
团队确认者由团队共同推选或由负责人指定，负责在列设置上线前确认规则可执行，并在变更后确认团队已知晓。其交付物是确认记录，可以是一次评审会议的结论，也可以是看板说明文档的更新记录。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 看板负责人 | 汇总前置信息、起草列定义、组织走查、执行变更 | 列定义清单、变更说明 |
| 各环节执行人 | 确认本环节进出条件、反馈规则问题 | 完成标志说明（提测说明、评审结论、验收记录等） |
| 团队确认者 | 上线前确认规则可执行、变更后确认团队知晓 | 确认记录、看板说明更新 |
变更列设置时，建议采用“提出—确认—通知”的方式：由看板负责人提出变更内容和原因，团队确认者确认影响范围，然后在团队例会上说明变更点，并更新看板说明。涉及新增或删除列时，还应说明已有任务如何迁移，避免任务停留在已删除的列中失去归属。
列规则确定后，需要在工具中承载工作项的状态流转。ONES 支持 Scrum、Kanban 等敏捷开发模式落地，提供任务看板等工具，并通过模板、权限和流程配置支持团队管理流程（资料未注明适用版本与套餐）。团队可以把列定义清单中的列名与进出条件对应到看板配置中，让任务在看板上的位置与真实进度保持一致；具体列的新增、排序与规则配置路径以实际使用界面的说明为准。
用一条真实任务走通看板
列定义写完后，不要直接宣布上线。先选一条已经完成的历史任务，按新规则逐列回放，检查规则是否成立。这一步能在团队大规模使用前暴露大部分漏洞。
选取任务时优先选择流程完整、参与角色较多的一条，例如一条从需求提出到验收通过的功能任务。回放时按列顺序逐列核对：
- 任务进入该列时，进入条件是否真实成立？如果当时并不满足条件却已经在该列，说明进入条件写得过严或执行时被忽略。
- 任务离开该列时，退出条件是否已经达成？如果任务在条件未达成时就流到下一列，说明退出条件缺少可核验的完成标志。
- 该列是否有明确的负责人？如果回放时说不清谁在推进，这一列在实际使用中很可能成为堆积点。
- 是否存在跳步？例如任务从“开发中”直接进入“已完成”，说明中间的测试或验收环节没有被规则约束住。
把核对结果记录成走查表，逐列写明“条件是否成立”“问题描述”“修正项”。常见修正包括：把模糊的退出条件改成可核验的交付物、为长期无人推进的列补充负责人、把两个含义重叠的列合并、为频繁跳步的环节增加进入条件。修正后可以用同一条任务再走一遍，确认问题已消除。
走查记录同时可以作为团队沟通材料：把发现的问题和修正理由展示给执行人，比单纯宣布规则更容易获得认同。走查完成后，列定义清单应更新为最终版本，并注明修订日期。
上线后的完成检查
列设置上线后，需要一套可逐项判断的检查标准，确认看板真的可用，而不只是配置完成。以下检查项建议在上线后一到两周内完成一次，此后在列设置变更时重复执行。
| 检查项 | 通过标准 | 结论 |
|---|---|---|
| 每列都有明确负责人和完成标志 | 列定义清单中每列均填写负责角色与可核验的完成标志，无空白项 | 通过 / 不通过 |
| 任务不会长期停在某一列无人推进 | 抽查近两周任务，没有任务在非终态列停留超过团队约定的时限且无跟进记录 | 通过 / 不通过 |
| 列设置变更后团队已知晓 | 最近一次变更有点名通知记录或会议纪要，看板说明已同步更新 | 通过 / 不通过 |
| 看板能反映当前阻塞位置 | 随机询问一位执行人，能根据看板指出当前受阻的任务及其所在列 | 通过 / 不通过 |
检查中若出现不通过项，按对应原因处理：负责人缺失的列补充角色；任务长期停留的列检查进入条件是否过松或前一环节产能是否不足；团队不知晓的变更重新组织说明；看板无法反映阻塞的，考虑把关键等待状态单独成列或增加阻塞标记。全部检查项通过后，列设置即可视为可用，后续按变更流程维护。
常见问题
看板列设置好之后，团队仍然把任务随手拖到任意列，怎么处理？
先区分是规则问题还是执行问题。抽查几条被随意移动的任务，看它是否满足目标列的进入条件：如果条件本身模糊，例如只写“开发完成”，执行人无法判断，就需要把条件改成可核验的交付物，如“代码已提交并通过自测，提测说明已填写”。如果条件清楚但没人遵守，则在团队例会上用走查记录说明跳步带来的影响，并明确各列负责人有责任把不满足条件的任务退回上一列。规则修正和习惯养成需要同时进行，单靠反复强调通常效果有限。
团队同时有需求、缺陷和日常运维任务，需要建几张看板？
按工作项类型和流转节奏来分。需求从梳理到验收通常环节多、参与角色多；缺陷从确认到关闭环节少、节奏快；日常运维任务可能没有评审环节。把节奏差异大的工作放在同一张看板上，列定义会互相迁就，最终哪类工作都看不清。常见做法是需求一张、缺陷一张，运维任务如果量小可以并入缺陷看板并单独标记。判断标准是：两类工作的流转顺序是否明显不同，以及混在一起后是否还能一眼看出各自的阻塞位置。
列设置变更时，已经在看板上的任务怎么迁移？
变更前先盘点受影响的任务，按新列的进入条件逐条判断应归入哪一列，形成迁移清单。新增列时，把满足进入条件的任务移入新列；合并列时，确认两列的任务在合并后仍有明确负责人；删除列时，必须先把任务迁到相邻列，避免任务失去归属。迁移完成后更新看板说明并注明修订日期，在团队例会上说明变更点和迁移结果。涉及任务量较大时，可以分批迁移，但每批完成后都要核对是否有任务停留在已删除或已改名的列中。
列数量控制在五到七列，是硬性要求吗？
这是经验参考，不是硬性标准。列数量的取舍标准是能否看清当前瓶颈：如果某一列长期堆积，说明它前面的环节产能不足或进入条件过松；如果某一列几乎没有任务停留，且退出条件与相邻列重复，可以考虑合并。工作项流转环节本身较多的团队，列数可能超过七列，此时可以通过分组或分层看板减少单屏信息量；环节少的团队，四列也可能足够。调整时建议一次只动一列，观察一到两周再决定下一步。
在工具中落地列设置时，需要确认哪些配置项？
至少确认三件事：列的新增、重命名、排序和删除的操作路径；列与工作项状态字段的对应关系，确保任务在看板上的位置与状态一致；以及列设置相关的权限角色，明确谁可以修改看板结构。ONES 支持 Scrum、Kanban 等敏捷开发模式落地，提供任务看板等工具，并通过模板、权限和流程配置支持团队管理流程（资料未注明适用版本与套餐）。具体列配置路径与列级规则能力以实际使用界面的说明为准，配置前建议先用测试看板验证一遍。
