📊 项目进度追踪与SDLC管理 — Project SDLC Tracker

版本：v1.0 | 角色：轩辕 CTO | 核心理念：承诺驱动开发

---

一、任务拆解协议

1.1 Epic → Story → Task 层级

┌────────────────────────────────────────────────────────┐
│  Epic (2-4周)                                           │
│  用户系统                                                  │
├────────────────────────────────────────────────────────┤
│  ├── Story-1 (3-5天)                                    │
│  │   注册登录模块                                          │
│  │    ├── Task-1.1 (4h) 前端注册表单                      │
│  │    ├── Task-1.2 (3h) 后端Auth API                     │
│  │    └── Task-1.3 (2h) 数据库用户表 + 迁移              │
│  │                                                      │
│  ├── Story-2 (3-5天)                                    │
│  │   权限管理模块                                          │
│  │    ├── Task-2.1 (3h) RBAC模型设计                     │
│  │    ├── Task-2.2 (4h) 权限中间件                       │
│  │    └── Task-2.3 (2h) 管理界面                         │
│  │                                                      │
│  └── Story-3 (2-3天)                                    │
│      用户资料模块                                          │
│        ├── Task-3.1 (2h) 资料编辑页面                     │
│        └── Task-3.2 (3h) 头像上传API                     │
└────────────────────────────────────────────────────────┘

1.2 拆解规则

每个层级的时间约束：
  Epic:   2-4周    ← 超4周必须拆分更多Story
  Story:  3-5天    ← 超5天必须拆更多Task
  Task:   2-4小时  ← 超4小时的Task必须进一步拆解

Rule of Thumb:
  "如果某个Task你无法在4小时内完成
   → 说明你还没真正理解它 → 继续分解"

---

二、ETA估算模型

2.1 三值估算

对每个Task，用三个估算值：

O = Optimistic（乐观值）: 一切顺利所需时间
M = Most Likely（最可能值）: 正常情况
P = Pessimistic（悲观值）: 考虑各种延误

ETA = (O + 4M + P) / 6  （PERT加权平均）

示例：
  Task: 前端登录表单
  O=1h, M=3h, P=8h
  ETA = (1 + 4*3 + 8) / 6 = 21/6 = 3.5h

2.2 复杂度快速评估

复杂度级别	O	M	P	ETA	典型任务
L0 (微小)	0.5h	1h	2h	1.1h	修改字段、修复小Bug
L1 (简单)	1h	3h	6h	3.2h	CRUD API、简单页面
L2 (中等)	3h	8h	16h	8.5h	认证系统、复杂表单
L3 (困难)	8h	24h	48h	25.3h	支付集成、性能优化
L4 (挑战)	24h	72h	160h	77.3h	系统重构、微服务拆分

2.3 历史数据校准

def calibrated_eta(task):
    # 从历史数据中获取校准系数
    history = get_history_for_similar_tasks(task)
    if not history:
        # 没有历史数据，用PERT标准值
        return pert_eta(task)
    
    # 计算历史平均偏差
    actual_vs_estimate = history["actual"] / history["estimated"]
    mean_ratio = actual_vs_estimate.mean()
    
    # 校准（如果历史显示通常超时20%，就调整ETA）
    return pert_eta(task) * mean_ratio

---

三、进度追踪机制

3.1 实时看板

# 📋 项目看板 — [项目名]

## 🟢 To Do
| 优先级 | Task ID | 描述 | ETA | 负责人 |
|--------|---------|------|-----|--------|
| P1 | T-004 | 忘记密码功能 | 4h | @工蜂-A |

## 🟡 In Progress
| Task ID | 描述 | 开始时间 | 预期完成 | 完成% | 负责人 |
|---------|------|---------|---------|-------|--------|
| T-001 | 登录表单 | 08:00 | 11:30 | 70% | @工蜂-A |
| T-002 | Auth API | 08:00 | 11:00 | 90% | @工蜂-B |

## 🔵 Review
| Task ID | 描述 | 提交时间 | Reviewer | 状态 |
|---------|------|---------|----------|------|
| T-003 | 用户表迁移 | 10:00 | @仲裁蜂 | ⏳等待 |

## ✅ Done
| Task ID | 描述 | 完成时间 | 实际耗时 | vs ETA |
|---------|------|---------|---------|--------|
| — | — | — | — | — |

3.2 燃尽图自动化

每日更新燃尽图：

Day   剩余工作量(h)  计划线  实际线
──────────────────────────────────
D-1   42             42      42
D-2   38             37      36    ◀ 超前1h
D-3   33             32      29    ◀ 超前3h
D-4   28             27      22    ◀ 超前5h
D-5   22             22      15    ◀ 远超计划
...

状态: ✅ 超前计划（进度良好）
风险: 无
备注: 蜂群并行效果显著，ETA有望提前

3.3 阻塞项自动标记

阻塞自动检测规则：
1. Task状态为"进行中"但超过24小时无更新 → 自动标记🔴
2. Task上游依赖已完成但本Task未开始 → 自动标记🔴
3. 同一Agent被分配超过5个Task → 自动标记🟡（负载过高）
4. Story完成率低于40%但已过50%时间 → 自动标记🟡

---

四、状态汇报模板

4.1 日报模板（对齐AGENTS.md格式）

🔧 轩辕日报 · 2026-05-04

✅ 已完成：
  · [用户系统] 登录表单 — T-001 ✅ (4h完成，v ETA-3.5h +0.5h)
  · [用户系统] Auth API — T-002 ✅ (3h完成，v ETA-3h 准时)
  · [用户系统] 用户表迁移 — T-003 ✅ (1.5h完成，v ETA-2h -0.5h)

🔄 进行中：
  · [权限系统] RBAC模型 — T-004 🟡 50% (ETA: 今天16:00)
  · [权限系统] 权限中间件 — T-005 🟡 30% (ETA: 明天10:00)

⚠️ 阻塞(需天枢/创始人介入)：
  · [用户系统] T-006 微信登录集成 — 等待微信APPID审批
  · 已通知天枢：预计审批周期3-5个工作日
  · 建议：先做其他功能，微信登录降级为最后优先级

📊 进度概览：
  总Task: 8 | ✅完成: 3 | 🟡进行中: 3 | ⏳待分配: 2 | 🔴阻塞: 1
  完成率: 37.5% | 进度 vs 计划: ✅超前5%
  ETA总体: 比原计划提前约1天

4.2 周报模板

🔧 轩辕周报 · 2026-05-04 ~ 2026-05-08

## 本周完成
| 项目 | 已完成功能 | 代码量 | 测试覆盖 | 状态 |
|------|-----------|--------|---------|------|
| 用户系统 | 注册/登录/资料编辑 | 2,800行 | 94% | ✅ |
| 权限系统 | RBAC模型+中间件 | 1,500行 | 88% | ✅ |
| 部署流水线 | CI/CD + 容器化 | — | — | ✅ |

## 下周规划
| 项目 | 计划 | ETA | 依赖 |
|------|------|-----|------|
| 支付系统 | 微信/支付宝集成 | 5天 | 微信审核 |
| 通知系统 | 邮件+站内信 | 3天 | — |

## 技术债务
| 债务项 | 级别 | 引入时间 | 计划修复 |
|--------|------|---------|---------|
| 用户模块测试覆盖不足 | P2 | 本周 | 下周一 |
| Auth缓存策略缺失 | P2 | 本周 | 下周三 |

## 风险评估
- 微信支付审核进度 → 可能影响上线时间
- 建议：先完成通知系统，并行等待审核

4.3 紧急汇报模板

🚨 紧急状态报告 · [时间]

## 问题
[一句话描述]

## 影响范围
- 影响的Story/Task: [列表]
- 影响的上线时间: [新的预计时间]

## 根因
[诊断结果]

## 解决方案
- 短期: [立即止血措施]
- 长期: [根本解决方案]

## 需要什么
- [来自天枢的决策]
- [来自创始人的资源]

---

五、风险预警系统

5.1 风险分级

级别	定义	响应	升级路径
P0 🔴 灾难	系统不可用/上线严重延迟	立即通知+立即解决	直接升级到创始人
P1 🟠 严重	核心功能受阻/延迟+1天	4小时内通知+当天解决	升级到天枢
P2 🟡 中等	非核心功能受阻/延迟+4h	日报中提及+2天内解决	记录+下次迭代
P3 🟢 轻微	轻微延迟/不影响上线	内部记录+优化	纳入技术债务

5.2 自动风险检测

每执行一次状态更新，自动检测：

[1] 交付时间检测
    if 剩余工作量 > 剩余时间 * 标准产能:
        trigger = 🟡 "进度滞后风险"
        if 滞后 > 30%:
            trigger = 🟠 "严重滞后风险"
            notify = 天枢

[2] 阻塞链检测
    if Task-A是关键路径 + Task-A阻塞:
        for each downstream of Task-A:
            mark = 🟡 "连锁阻塞风险"
            estimated_delay = Task-A.remaining_time + downstream.total_work

[3] 质量退化检测
    if 最近3个Task的Review通过率 < 80%:
        trigger = 🟡 "质量风险"
        action = "仲裁蜂介入加强Review"

[4] 资源枯竭检测
    if 可用Agent数 < 待分配Task数 * 0.5:
        trigger = 🟠 "资源不足"
        action = "向昆仑请求更多Agent配额"

---

六、多项目并行管理

6.1 资源冲突检测

# 多项目资源调度

## 当前活跃项目
| 项目 | 优先级 | Agent使用 | ETA |
|------|--------|----------|-----|
| 用户系统 | P0 | 3个Agent | 5天 |
| 支付集成 | P1 | 2个Agent | 5天 |
| 通知系统 | P2 | 1个Agent | 3天 |

## Agent负载
@工蜂-A: [用户系统]40% + [通知系统]30% + [支付]30% = 🔴 100%过载
@工蜂-B: [用户系统]30% + [支付]60% = 🟡 90%高负载

## 调度建议
1. @工蜂-B专注[支付]先完成（P1优先）
2. [通知系统]延迟2天开始，等待@工蜂-A释放
3. 或：向昆仑申请额外1个Agent资源

6.2 优先级协商协议

当多个项目争抢同一资源时：

1. 按项目优先级分配（P0 > P1 > P2）
2. 同级别按"阻塞上游最多"优先
3. 如果两个P0冲突 → 升级到天枢决策
4. 记录决策到MEMORY.md以供后续参考

---

七、与天枢/创始人的协作协议

7.1 承诺-执行-汇报闭环

┌───────────────────────────────────────────┐
│           承诺驱动开发闭环                   │
├───────────────────────────────────────────┤
│  ① 承诺 (Commit)                           │
│  「用户系统5天完成，预计5月9日上线」         │
│  → 天枢确认                                │
│  → 写入MEMORY.md                           │
├───────────────────────────────────────────┤
│  ② 执行 (Execute)                          │
│  → 每天更新看板                            │
│  → 阻塞自动通知                            │
│  → 进度实时跟踪                            │
├───────────────────────────────────────────┤
│  ③ 汇报 (Report)                           │
│  → 每日日报（标准模板）                     │
│  → 风险提前预警（不等到最后一天才说）        │
│  → 延迟提前48小时告知                      │
├───────────────────────────────────────────┤
│  ④ 复盘 (Retro)                            │
│  → 上线后复盘ETA偏差原因                    │
│  → 更新历史数据以校准未来ETA                │
│  → 记录到MEMORY.md                         │
└───────────────────────────────────────────┘

7.2 汇报频率与渠道

场景	频率	渠道	格式
日常进度	每天X次	天枢	日报模板
里程碑	每完成1个Story	天枢+创始人	简短状态更新
P0风险	立即	创始人+天枢	紧急汇报模板
P1风险	4小时内	天枢	风险说明
周复盘	每周一	天枢+创始人	周报模板

---

八、配套模板文件

tracker-template.md

# 📊 [项目名称] 进度追踪

**状态**: 🟢 正常 / 🟡 注意 / 🔴 阻塞
**总ETA**: [日期]
**负责人**: 轩辕

## 里程碑
| 里程碑 | 计划 | 实际 | 状态 |
|--------|------|------|------|
| M1: 需求评审 | [Date] | [Date] | ✅ |
| M2: 架构设计 | [Date] | [Date] | ✅ |
| M3: 开发完成 | [Date] | [Date] | 🟡 |
| M4: 测试通过 | [Date] | — | ⏳ |
| M5: 上线 | [Date] | — | ⏳ |

## 当前看板
[看板内容]

## 风险列表
| 风险 | 级别 | 状态 | 缓解方案 |
|------|------|------|---------|
| [描述] | P0/P1/P2 | 🔴/🟡/🟢 | [方案] |

## 关键指标
- Story完成率: X%
- Task完成率: X%
- 代码覆盖率: X%
- Review通过率: X%
- Bug率: X/kloc

---

九、实战示例

场景：用户系统上线追踪

# 用户系统 · 全流程进度管理

## Day 1 (5/1)
✅ 完成需求解构，生成8个Task
✅ 承诺：5/9上线
📊 进度: 0/8 (0%) — 正好

## Day 2 (5/2)
等待微信APPID审批(T-006阻塞)
重新调度：T-006降级，T-007/T-008提前
📊 进度: 3/8 (37.5%) — ✅超前5%
🟡 风险: 微信审批周期不确定

## Day 3 (5/3)
微信审批通过（比预期快）
T-006开始执行
📊 进度: 5/8 (62.5%) — ✅超前10%

## Day 4 (5/4)
T-006完成，开始集成测试
发现1个Bug（已自动修复）
📊 进度: 7/8 (87.5%) — ✅超前15%

## Day 5 (5/5)
全部完成，部署上线
📊 实际: 5天 vs 承诺: 5天 ✅准时
📦 复盘: 蜂群+前期阻塞调度策略成功
📝 更新历史校准数据: 目标-实际偏差 = 0%

---

十、常见陷阱

陷阱	表现	解决方案
ETA过于乐观	总是超时	使用三值估算 + 历史校准
报喜不报忧	直到最后才发现延期	阻塞自动标记+预警规则
任务粒度太粗	一个Task做3天	强制粒度<4小时
忽略依赖	下游一直等待	画依赖图后再分配
不归档历史	每次都重新估算	每次复盘更新历史数据库

---

轩辕在此。 🔧 项目SDLC追踪 v1.0 | 承诺驱动 | 风险预警 | 透明进度