研发任务管理规范

任务拆分、估算、进度跟踪、WIP 限制

任务拆分原则

规则：研发任务必须拆分到”可独立交付、可独立验证”的粒度，单个任务工期不超过 3 个工作日。

[Requirement] 每个任务必须有唯一的 ID（如 TASK-001）、明确的负责人、可验证的完成标准。

[Requirement] 单个任务的预计工期不得超过 3 个工作日（24 人时）；超过则必须继续拆分。

[Standard] 任务完成标准须关联到验收标准（AC），一个任务可对应 1-N 条 AC，但一条 AC 不可拆到多个任务。

[Standard] 任务须标注类型：feature / bugfix / refactor / chore / test。

[Default] 任务粒度默认控制在 0.5-2 人日，过大或过小都不合理。

拆分粒度对照表：

任务规模	工期	是否合理	说明
极小	< 0.5 人日	偏低	合并到相关任务，避免看板碎片化
合理	0.5-2 人日	推荐	可独立交付与验证
偏大	2-3 人日	可接受	须确保完成标准明确
过大	> 3 人日	禁止	必须继续拆分

拆分示例（支付页改版需求）：

REQ: 支付页改版
├── TASK-001: 搭建支付页路由与页面骨架            [0.5 人日]
├── TASK-002: 实现商品信息展示与金额计算          [1 人日]
├── TASK-003: 接入微信支付下单接口                [1.5 人日]
├── TASK-004: 接入支付宝下单接口                  [1.5 人日]
├── TASK-005: 支付结果轮询与状态展示              [1 人日]
├── TASK-006: 异常支付重试与兜底                  [1 人日]
└── TASK-007: 支付页自动化测试                    [1 人日]

反模式：

❌ 一个任务”实现支付模块”，预估 10 人日——无法跟踪进度。
❌ 任务拆成”写第一行代码""写第二行代码”——粒度过细，管理成本高于收益。
❌ 任务没有完成标准，靠”做完了”口头确认。

估算方法

规则：任务估算是承诺不是许愿，必须由执行人参与估算，采用三点估算法降低偏差。

[Requirement] 任务估算必须由实际执行人参与，禁止由管理者单方面拍脑袋指定工期。

[Standard] 采用三点估算法：E = (O + 4M + P) ÷ 6，其中 O=乐观，M=最可能，P=悲观。

[Standard] 估算单位统一为”人日”（1 人日 = 8 人时），不使用”天""周”等模糊单位。

[Caution] 估算值须包含开发、自测、代码评审的时间，不只是纯编码时间。

[Suggestion] 对陌生领域的任务，悲观值 P 取乐观值 O 的 3-4 倍；对熟悉领域，P 取 O 的 1.5-2 倍。

三点估算示例：

任务	乐观 O	最可能 M	悲观 P	估算 E = (O+4M+P)/6
接入微信支付	1	1.5	3	(1+6+3)/6 = 1.67 ≈ 1.5 人日
支付结果轮询	0.5	1	2	(0.5+4+2)/6 = 1.08 ≈ 1 人日

估算偏差跟踪：

每次任务完成后记录实际工时与估算工时，计算偏差率：

偏差率 = (实际工时 - 估算工时) ÷ 估算工时 × 100%

[Suggestion] 团队偏差率长期超过 ±30% 时，应回顾估算方法并调整。

反模式：

❌ “这个应该很快，半天搞定吧”——没有依据的估算。
❌ 估算只算编码时间，忽略联调、自测、评审，导致实际工期翻倍。
❌ 管理者把估算值直接当成 deadline，不留缓冲。

进度跟踪

规则：任务进度必须可视化、可追溯，每日更新状态，禁止”黑盒开发”。

[Requirement] 每个任务在看板上必须有明确状态：待办 / 进行中 / 待评审 / 已完成。

[Requirement] 任务进入”进行中”后，每日站会须同步进度与阻塞项。

[Standard] 任务超过估算工期 80% 仍未进入”待评审”状态，须主动预警并说明原因。

[Standard] 阻塞超过 1 个工作日的任务，须升级至负责人协调，不得自行搁置。

[Default] 每日站会时长不超过 15 分钟，每人 1-2 分钟同步：昨天做了什么、今天做什么、有什么阻塞。

任务状态流转：

待办 ──→ 进行中 ──→ 待评审 ──→ 已完成
           │           │
           └── 阻塞    └── 打回修改 ──→ 进行中

状态定义：

状态	定义	进入条件
待办	已排期，未开始	排期确认后
进行中	正在开发	负责人领取任务
阻塞	因外部原因无法推进	等待他人/依赖/审批
待评审	开发完成，等待 Code Review	自测通过、PR 提交
已完成	评审通过、合并到主干	PR 合并

进度预警规则：

触发条件	动作
进度达 80% 未提 PR	站会上说明原因，评估是否需拆分或求助
进度达 100% 仍未提 PR	升级至团队负责人，评估是否延期
阻塞超过 1 天	升级至负责人协调解除阻塞
连续 2 天无进度更新	视为失管，负责人介入

反模式：

❌ 任务状态永远停在”进行中”，直到上线才更新。
❌ 站会变成汇报会，每人讲 10 分钟，占用大量时间。
❌ 阻塞了不说，等到 deadline 前一天才暴露。

WIP 限制

规则：限制在制品（Work In Progress）数量，强制聚焦，降低上下文切换成本。

[Requirement] 单个研发人员同时进行中的任务不得超过 2 个。

[Requirement] 团队”进行中”任务总数不得超过团队人数 × 2。

[Standard] 看板”进行中”列设置 WIP 上限，达到上限时不允许新增任务进入，必须先完成已有任务。

[Standard] 紧急插入任务时，必须从”进行中”移出一个任务回”待办”，保持 WIP 不超限。

[Caution] WIP 限制不是”不能多任务”，而是避免同时推进多个未完成任务导致交付延迟。

WIP 限制计算示例：

团队人数	个人 WIP 上限	团队 WIP 上限
3 人	2	6
5 人	2	10
8 人	2	16

看板列 WIP 设置：

列	WIP 上限	说明
待办	不限	需求池可多
进行中	团队人数 × 2	强制限制
待评审	团队人数	评审积压需消化
已完成	不限	已交付

反模式：

❌ 一个人同时开 5 个任务，每个都做了一半，没有一个能交付。
❌ “进行中”列有 20 个任务，看板失去管理意义。
❌ 紧急任务直接插入，不调整 WIP，导致原有任务全部延期。

看板规则

规则：看板是任务管理的唯一事实来源，所有任务必须在看板上体现，禁止看板外”隐形任务”。

[Requirement] 所有研发工作必须创建任务卡片，包括临时需求、bug 修复、技术债务，禁止”顺手做一下”不入看板。

[Requirement] 任务卡片必须包含：标题、负责人、估算工期、验收标准链接。

[Standard] 任务卡片颜色按类型区分：feature=蓝色、bugfix=红色、refactor=黄色、chore=灰色。

[Standard] 任务卡片须标注所属需求 ID（如 REQ-2024Q4-001），便于追溯。

[Default] 看板列顺序固定为：待办 → 进行中 → 待评审 → 已完成，不随意增减列。

任务卡片模板：

┌─────────────────────────────────────┐
│ TASK-003 [feature] REQ-2024Q4-001  │
├─────────────────────────────────────┤
│ 接入微信支付下单接口                 │
├─────────────────────────────────────┤
│ 负责人: 张三   估算: 1.5 人日       │
│ 关联 AC: AC-3, AC-4                 │
├─────────────────────────────────────┤
│ 完成标准:                           │
│ - 调用微信统一下单 API 成功         │
│ - 返回 prepay_id 并生成支付参数     │
│ - 异常时返回明确错误码             │
└─────────────────────────────────────┘

看板维护规则：

每日站会前，所有人更新自己任务的状态。
任务从”待办”移入”进行中”时，负责人须确认已明确完成标准。
任务进入”待评审”前，须完成自测并提交 PR。
任务”已完成”后，须在卡片上记录实际工时，用于估算校准。
每周五清理”已完成”列超过 2 周的卡片，归档至需求文档。

反模式：

❌ 修了一个线上 bug 没建任务，绩效统计时无法追溯。
❌ 任务卡片只有标题，没有负责人和验收标准。
❌ 看板半年没更新，状态与实际严重脱节。