2 todo planner

② 近期任务规划 (TODO Planner)

任务目标

帮助用户制定项目的近期任务计划（通常为周或双周/Sprint），产出标准化的 TODO.md 文件。该文件应清晰呈现：

• 当前周期重点: 本 Sprint/周的核心目标
• 任务列表: 按优先级排序的具体待办事项
• 责任与时间: 负责人、截止日期、预估工时
• 依赖与阻塞: 任务间的关系和风险点

触发条件

当用户说以下任一话术时激活：

• "帮我写 todo" / "制定待办清单"
• "规划本周/本月任务"
• "任务分解" / "拆解任务"
• "优先级排序" / "哪些先做"
• "Sprint 规划" / "迭代计划"

前置条件

⚠️ 推荐（非强制）: 先完成 ① 远期规划，确保近期任务对齐远期目标。

如果已有 ROADMAP.md，TODO 应该是其近期的具体化拆解。

核心方法论选择

方法论对比表

方法	适用场景	核心逻辑	输出格式	复杂度
P0-P3 分级	通用任务管理	影响力×紧急度	4级标签	⭐ 简单
MoSCoW	需求/功能排序	Must/Should/Could/Won't	4类标签	⭐⭐ 中等
Eisenhower 矩阵	个人效率	重要×紧急	4象限	⭐⭐ 中等
时间盒 (Time-boxing)	敏捷Sprint	固定时间窗口	时间约束	⭐⭐ 中等
RICE 评分	产品功能优先级	R×I×C/E	数值分值	⭐⭐⭐ 复杂
WSJF	敏捷开发	加权最短作业优先	故事点权重	⭐⭐⭐ 复杂

推荐选择决策树

项目类型？
    │
    ├── 个人项目 → P0-P3 + Eisenhower ✅（简单高效）
    │
    ├── 小团队 (2-5人) → MoSCoW + 时间盒 ✅（平衡）
    │   └── 如是敏捷开发 → Scrum Sprint Planning 模板
    │
    └── 中大型团队 → MoSCoW + RICE + 看板跟踪 🔄（完整）

> 📖 详细指南: [todo-methods.md](../references/todo-methods.md)

操作步骤

Step 1: 收集任务输入

任务来源清单

## 任务收集 Checklist

### 从上游文档导入
- [ ] ROADMAP.md 的本季度 KR 拆解
- [ ] 上个周期的遗留/未完成任务
- [ ] Issue Tracker (GitHub Issues/Jira) 的 Open Issues
- [ ] 用户反馈/Bug 报告
- [ ] 团队会议记录的 Action Items

### 新增需求识别
- [ ] 产品经理的新需求
- [ ] 技术债务偿还（代码重构/升级依赖）
- [ ] 学习和探索性任务（调研新技术等）
- [ ] 运营和支持类工作（文档/培训/客服）

快速收集命令:

# 从 GitHub Issues 收集
gh issue list --state open --limit 20 --json title,labels,assignee 2>/dev/null

# 从 Jira 收集（如有）
jira jql "project = XXX AND status in ('To Do', 'In Progress')" 2>/dev/null

# 统计现有 TODO
if [ -f TODO.md ]; then
  echo "现有未完成任务:"
  grep '^- \[ \]' TODO.md | wc -l
fi

---

Step 2: 应用优先级方法论

方法 A: P0-P3 分级法（推荐默认）

定义:

优先级	名称	含义	响应时间	占比建议
P0	🔴 必须做 (Must)	阻塞性问题或核心功能	立即	10-20%
P1	🟡 应该做 (Should)	重要但不紧急	本周期	30-40%
P2	🟢 可以做 (Could)	有价值但可推迟	有空再做	30-40%
P3 ⚪	⚪ 未来考虑 (Won't)	低优先级或暂不做	下个周期	0-10%

判定标准:

任务是否满足以下任一条件？
    │
    ├── 阻塞其他任务？ → P0
    ├── 影响用户体验（线上Bug）？ → P0
    ├── 是本周期承诺的核心功能？ → P0/P1
    ├── 是 ROADMAP 的里程碑交付物？ → P1
    ├── 有明确的外部截止日期？ → P1
    ├── 提升效率/质量但非紧急？ → P2
    ├── 锦上添花的功能？ → P2/P3
    └── 不确定是否需要？ → P3 或删除

方法 B: MoSCoW 法则（需求/功能排序）

定义:

类别	全称	含义	承诺度
Must	必须有	不做就无法发布	100% 承诺
Should	应该有	高价值但非关键	尽量做，允许延期
Could	可以有	有了更好，没有也行	有时间就做
Won't	不会有	明确不做（本轮）	不承诺

使用场景:

• 产品发布规划
• MVP 功能范围确定
• 客户需求谈判

判定问题:

1. 如果不包含这个功能，产品还能用吗？→ No → Must
2. 用户会因为这个功能不满吗？→ Yes → Should
3. 这个功能能让产品更出色吗？→ Yes → Could
4. 这个功能现在完全不需要？→ Yes → Won't

方法 C: Eisenhower 矩阵（个人效率）

                    │
        紧急       │     不紧急
        ────────   │   ──────────
                    │
重要 ↑   │  🔴 第I象限   │  🟢 第II象限
        │  (立即做)      │  (计划做)
        │  P0 任务       │  P1/P2 任务
        │                │  学习/规划/锻炼
        ├────────────────┼────────────────→
不重要 ↓│  🟠 第III象限  │  ⚪ 第IV象限
        │  (委托/简化)   │  (删除/忽略)
        │  干扰/部分会议  │  无意义的事
        │  P3 或外包     │  直接砍掉

应用技巧:

• 第 I 象限: ≤ 20% 时间（救火模式不可持续）
• 第 II 象限: ≥ 50% 时间（重点投资区）
• 第 III 象限: ≤ 25% 时间（学会说"不"）
• 第 IV 象限: 0% 时间（果断删除）

📖 详细应用指南: todo-methods.md

---

Step 3: 编写 TODO.md

标准模板（推荐）

# {项目名} 待办事项 ({周期})

> 周期: {start_date} ~ {end_date} | 负责人: {owner}
> 对齐目标: [ROADMAP.md O{N}-KR{M}](./ROADMAP.md#{anchor})

---

## 📍 本周期重点

**核心目标**: {一句话说明本周/本Sprint最重要的1-2件事}

**成功标准** ({Done的定义}):
- [ ] {criteria_1}
- [ ] {criteria_2}
- [ ] {criteria_3}

---

## 🚀 P0 - 必须完成 (Must Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 1: 动宾结构的简短标题}

- **负责人**: @{who}
- **类型**: 🔧Feature / 🐛BugFix / 📝Docs / 🔬Research / 🎨Design
- **优先级原因**: {为什么是P0?（阻塞/核心/承诺）}
- **预估工时**: {X}h (或 {X} story points)
- **截止日期**: {when} (或 Sprint Day {N})
- **依赖**: 无 / 依赖于 #{issue} / 被 #{issue} 依赖
- **验收标准 (DoD)**:
  - [ ] {done_criteria_1}
  - [ ] {done_criteria_2}
- **备注**: {额外信息/链接/上下文}

### [ ] {Task 2: ...}
...（同上格式）

---

## ⭐ P1 - 应该完成 (Should Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 3: ...}
...（同上格式，优先级改为 P1）

---

## 💡 P2 - 可以做 (Could Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 4: ...}
...

---

## ❄ P3 - 未来考虑 (Won't / Backlog)

> 这些任务本轮不做，放入 Backlog 或下个周期考虑

- [ ] {Task 5: ...} （原因: {为什么推迟}）
- [ ] {Task 6: ...} （原因: {why}）

---

## 🚧 阻塞项 & 依赖关系

### 当前阻塞
| 被阻塞的任务 | 阻塞来源 | 预计解除时间 | 应对措施 |
|-------------|---------|------------|---------|
| #{task} | {what blocks it} | {when} | {workaround} |

### 关键依赖
| 任务 | 依赖项 | 类型 | 状态 |
|------|--------|------|------|
| {task} | {dependency} | 🔗内部/🔗外部/🔗上游 | ✅就绪/⏳等待中 |

---

## 📈 进度概览

| 维度 | 数据 |
|------|------|
| **总任务数** | {N} |
| **已完成** | {X} ({%}) |
| **进行中** | {Y} ({%}) |
| **未开始** | {Z} ({%}) |
| **预估总工时** | {X}h |
| **已消耗工时** | {Y}h |
| **剩余工时** | {Z}h |

### 燃尽趋势（可选）

理想线 ────╮ ╭╯ 实际线 ╭───╯ ╰── (手绘或ASCII) Day1 Day3 Day5 Today

---

## 📝 备注 & 变更记录

### 本周期调整
| 日期 | 变更内容 | 原因 |
|------|---------|------|
| {date} | {change} | {reason} |

### 待确认事项
- [ ] {pending_item_1} (需要谁确认)
- [ ] {pending_item_2}

---

*最后更新: {date} | 下次站会: {standup_time}*

---

Step 4: 工作量估算（可选但推荐）

估算方法

方法	适用场景	单位	准确度
时间估算	个人任务	小时(h)	中（受经验影响）
Story Points	敏捷团队	点数(1/2/3/5/8...)	相对准确
T-shirt Sizing	快速粗估	XS/S/M/L/XL	粗略但快

T-shirt Sizing 参考标准:

Size	含义	典型工时（参考）
XS	极小（< 2h）	< 2 小时
S	小（半天）	2-6 小时
M	中等（1-2天）	6-16 小时
L	大（3-5天）	16-40 小时
XL	特大（> 1周）	> 40 小时

估算原则:

1. 独立估算: 不要受其他任务影响
2. 包含缓冲: 增加 20-50% 的不确定时间
3. 区分理想时间 vs 实际时间: 理想时间 × 1.5 ≈ 实际时间
4. 定期校准: 记录实际耗时，修正未来估算

---

Step 5: 质量验证

TODO 质量检查清单

# 基础统计
echo "=== TODO 质量检查 ==="
echo "文件行数: $(wc -l < TODO.md)"
echo "总任务数: $(grep -c '^- \[' TODO.md)"
echo ""

# 优先级分布
echo "=== 优先级分布 ==="
grep -cE '\[P0\]|🔴.*必须' TODO.md || echo "P0: 0"
grep -cE '\[P1\]|🟡.*应该' TODO.md || echo "P1: 0"
grep -cE '\[P2\]|🟢.*可以' TODO.md || echo "P2: 0"

# 关键字段完整性
echo ""
echo "=== 字段完整性 ==="
tasks_with_owner=$(grep -c '@[a-zA-Z]' TODO.md)
tasks_with_deadline=$(grep -cE '(截止|deadline|Sprint Day)' TODO.md)
tasks_with_estimate=$(grep -cE '(工时|story point|h$|SP)' TODO.md)
total_tasks=$(grep -c '^- \[' TODO.md)

echo "有责任人: $tasks_with_owner/$total_tasks ($(($tasks_with_owner*100/$total_tasks))%)"
echo "有截止日期: $tasks_with_deadline/$total_tasks ($(($tasks_with_deadline*100/$total_tasks))%)"
echo "有工时估算: $tasks_with_estimate/$total_tasks ($(($tasks_with_estimate*100/$total_tasks))%)"

通过标准:

• 总任务数在合理范围（个人 5-15 个/周，团队 8-20 个/Sprint）
• P0 任务占比 10-20%（过多则焦点分散）
• ≥ 80% 任务有责任人
• ≥ 80% 任务有截止日期
• ≥ 60% 任务有工时估算
• 依赖关系已标注

---

快速路径（极简模式）

如果只需要一个简单的 TODO 清单（如个人每日待办），使用极简模板：

# TODO - {date}

## 🎯 今日重点
{最重要的1-2件事}

## ✅ 任务列表

- [ ] 🔴 {紧急重要任务} (@me, 截止: 今天)
- [ ] 🟡 {重要不紧急任务} (@me, 截止: 本周)
- [ ] 🟢 {一般任务} (@me, 有空再做)

## 📌 备注
{任何需要记住的事情}

---
*上次更新: {time}*

适用场景:

• 个人日常待办
• 会议 Action Items
• 临时性的任务备忘

与 ROADMAP 的对齐

如何从 ROADMAP 拆解到 TODO？

ROADMAP (远期)                      TODO (近期)
─────────────                     ─────────────
O1: 打造卓越的用户体验              │
  KR1: NPS 从 30 → 60             │
    Q2-KR: NPS 提升 15 点          │
      M2: 反馈系统上线 (5/1)      │ → P0: 完成反馈系统前端开发
                                  │ → P0: 部署到测试环境
                                  │ → P1: 编写用户引导文案
                                  │ → P2: 设计感谢页面UI

对齐原则:

1. 每个 P0 任务应该能追溯到某个 KR 或里程碑
2. P1/P2 任务可以是探索性或优化类的（不一定直接对应 KR）
3. 如果发现 TODO 和 ROADMAP 完全脱节 → 需要重新审视

常见问题

Q: P0 太多怎么办？

A: P0 应该控制在 总数的 10-20%（通常 1-3 个）。如果 P0 过多：

• 重新评估：真的都是"必须"吗？
• 向上升级：是否需要调整 ROADMAP 的期望？
• 拆分周期：将部分 P0 移到下一个周期

Q: 任务粒度多大合适？

A: 推荐：

• 个人: 半天~2天能完成的任务
• 敏捷团队: 1个 Sprint（2周）内能完成的 Story
• 原则: 如果一个任务 > 3天，考虑拆分为子任务

Q: 估算不准怎么办？

A: 这是正常的！改进方法：

1. 记录实际耗时：每次完成后记录真实用时
2. 定期校准：每月回顾一次估算偏差
3. 使用相对估算：Story Points 比绝对时间更稳定
4. 增加缓冲：预留 20-50% 的应急时间

Q: TODO 需要每天更新吗？

A: 取决于场景：

• 个人: 每日晨间更新（5分钟）
• 小团队: 每日站会同步（15分钟）
• 大团队: 通过看板工具实时更新（Jira/Trello/Notion）

注意事项

⚠️ 规划 ≠ 执行: TODO 是"做什么"，不是"怎么做"。后者需要在执行过程中细化。

⚠️ 保持动态: TODO 应该每周或每 Sprint 更新，不是写完就不变的。

⚠️ 避免过度填充: 宁可少放任务（留缓冲），也不要填满导致无法完成（挫败感）。

⚠️ 学会说不: 不是所有任务都必须进入 TODO。P3/Won't 要敢于拒绝或延期。

⚠️ 对齐远期: 定期检查 TODO 是否还在支撑 ROADMAP 的方向，避免战术上的勤奋掩盖战略上的懒惰。