| name | project-sdlc-tracker |
| description | 项目进度追踪与SDLC全周期管理——ETA承诺、实时看板、风险预警、多项目并行调度。覆盖：任务拆解协议、ETA估算模型、进度追踪机制、日报/周报模板、风险预警系统、承诺驱动开发。触发词：项目进度、SDLC、ETA、甘特图、看板、燃尽图、里程碑、进度追踪、project management、进度汇报、阻塞告警 |
📊 项目进度追踪与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:
return pert_eta(task)
actual_vs_estimate = history["actual"] / history["estimated"]
mean_ratio = actual_vs_estimate.mean()
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 | 承诺驱动 | 风险预警 | 透明进度
