project-sdlc-tracker

📊 Project Progress Tracking and SDLC Management — Project SDLC Tracker

Version：v1.0 | Role: Xuanyuan CTO | Core Philosophy: Commitment-Driven Development

I. Task Breakdown Protocol

1.1 Epic → Story → Task Hierarchy

┌────────────────────────────────────────────────────────┐
│  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 Breakdown Rules

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

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

II. ETA Estimation Model

2.1 Three-Point Estimation

对每个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 Rapid Complexity Assessment

Complexity Level	O	M	P	ETA	Typical Tasks
L0 (Trivial)	0.5h	1h	2h	1.1h	Modify fields, fix small bugs
L1 (Simple)	1h	3h	6h	3.2h	CRUD API, simple page
L2 (Medium)	3h	8h	16h	8.5h	Authentication system, complex forms
L3 (Difficult)	8h	24h	48h	25.3h	Payment integration, performance optimization
L4 (Challenging)	24h	72h	160h	77.3h	System refactoring, microservice splitting

2.3 Historical Data Calibration

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

III. Progress Tracking Mechanism

3.1 Real-Time Dashboard

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

## 🟢 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 Burndown Chart Automation

每日更新燃尽图：

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 Automatic Blocking Item Marking

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

IV. Status Reporting Templates

4.1 Daily Report Template (aligned with AGENTS.md format)

🔧 轩辕日报 · 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 Weekly Report Template

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

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

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

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

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

4.3 Urgent Report Template

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

## 问题
[一句话描述]

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

## 根因
[诊断结果]

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

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

V. Risk Warning System

5.1 Risk Classification

Level	Definition	Response	Escalation Path
P0 🔴 Disaster	System unavailable/severe launch delay	Notify immediately + resolve immediately	Escalate directly to the founder
P1 🟠 Severe	Core functionality blocked/delayed +1 day	Notify within 4 hours + resolve the same day	Escalate to Tianshu
P2 🟡 Medium	Non-core functionality blocked/delayed +4h	Mention in daily report + resolve within 2 days	Log + next iteration
P3 🟢 Minor	Slight delay/no impact on launch	Internal log + optimization	Include in technical debt

5.2 Automatic Risk Detection

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

[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配额"

VI. Multi-Project Parallel Management

6.1 Resource Conflict Detection

# 多项目资源调度

## 当前活跃项目
| 项目 | 优先级 | 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 Priority Negotiation Protocol

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

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

VII. Collaboration Protocol with Tianshu/Founder

7.1 Commitment-Execution-Reporting Closed Loop

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

7.2 Reporting Frequency and Channels

Scenario	Frequency	Channel	Format
Daily progress	X times per day	Tianshu	Daily report template
Milestone	Each time 1 Story is completed	Tianshu + Founder	Brief status update
P0 risk	Immediate	Founder+Tianshu	Emergency report template
P1 risk	Within 4 hours	Tianshu	Risk description
Weekly review	Every Monday	Tianshu+Founder	Weekly report template

VIII. Supporting template files

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

IX. Practical examples

Scenario: User system launch tracking

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

## 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%

X. Common pitfalls

Pitfall	Manifestation	Solution
ETA too optimistic	Always overtime	Use three-point estimation + historical calibration
Only reporting good news, not bad	Delay is only discovered at the end	Automatic blocking marking + warning rules
Task granularity too coarse	One Task takes 3 days	Enforce granularity < 4 hours
Ignoring dependencies	Downstream keeps waiting	Draw the dependency graph before assigning
Not archiving history	Re-estimating every time	Update the historical database in each review

Xuanyuan is here. 🔧 Project SDLC Tracking v1.0 | Commitment-driven | Risk warning | Transparent progress

About this skill

I. Task Breakdown Protocol

1.1 Epic → Story → Task Hierarchy

1.2 Breakdown Rules

II. ETA Estimation Model

2.1 Three-Point Estimation

2.2 Rapid Complexity Assessment

2.3 Historical Data Calibration

III. Progress Tracking Mechanism

3.1 Real-Time Dashboard

3.2 Burndown Chart Automation

3.3 Automatic Blocking Item Marking

IV. Status Reporting Templates

4.1 Daily Report Template (aligned with AGENTS.md format)

4.2 Weekly Report Template

4.3 Urgent Report Template

V. Risk Warning System

5.1 Risk Classification

5.2 Automatic Risk Detection

VI. Multi-Project Parallel Management

6.1 Resource Conflict Detection

6.2 Priority Negotiation Protocol

VII. Collaboration Protocol with Tianshu/Founder

7.1 Commitment-Execution-Reporting Closed Loop

7.2 Reporting Frequency and Channels

VIII. Supporting template files

tracker-template.md

IX. Practical examples

Scenario: User system launch tracking

X. Common pitfalls