📊 项目进度追踪与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 复杂度快速评估

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 风险分级

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 汇报频率与渠道

八、配套模板文件

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%

十、常见陷阱

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