References:Linear Cycles、Basecamp Shape Up
Use Cases
- Replacing traditional Sprints
- Fast-paced delivery of AI workflows
- Projects with fixed time and variable scope
- Avoiding estimation hell
- Needing a continuous delivery cadence
Core Idea
传统 Sprint：
估算时间 → 排满 → 时间不够延期或砍质量
Cycle model: Fixed time box (Appetite) → when time is up, deliver the most valuable part at that moment Scope is adjustable, time is not extended
Advantages of AI workflows: Execution speed is fast, the bottleneck is waiting Cycle cadence is better suited for short cycles and high-frequency delivery
## Cycle 类型（AI 工作流适配）
```text
Micro Cycle：30~60 分钟
- 一个功能点从设计到测试
- 适合 S/M 级任务
- 单工作流或 2 个工作流串行
Standard Cycle：2~4 小时
- 一个完整模块
- 适合 M/L 级任务
- 多工作流协作
Extended Cycle：1 天（实际执行 6~8 小时 + 等待）
- 跨多模块的大功能
- 适合 L 级任务
- 全流程参与
Multi-Day Cycle：2~5 天
- 大型项目阶段
- 适合 XL 级任务
- 包含多个 Extended Cycle
Cycle Rules
1. 开始前明确目标和验收标准
- 不是"做某些功能"
- 而是"达到某个可验证的状态"
2. Cycle 内不接受新需求
- 变更进入下一个 Cycle
- 紧急 bug 例外（占用 cooldown）
3. 时间到了但没完成
- 砍范围交付最有价值的部分
- 不延期
- 剩余范围进入下个 Cycle
4. Cycle 结束后必有 cooldown
- 不能背靠背开始新 Cycle
- cooldown 用于消化遗留问题
Cooldown
每个 Standard Cycle 后：15~30 分钟
每个 Extended Cycle 后：1~2 小时
每个 Multi-Day Cycle 后：半天到一天
Cooldown 用途：
- 处理上个 Cycle 遗留的小问题
- 更新文档和 field-journal
- 为下个 Cycle 做准备
- 团队/工作流回血
- 不安排新的开发任务
为什么必须有 cooldown：
- 防止技术债积累
- 给文档更新留时间
- 让经验沉淀下来
- 避免连续高强度交付崩溃
Key Activities Within a Cycle
Cycle Kickoff (Start)
□ 明确 Cycle 目标
□ 定义验收标准
□ 列出 Cycle 内的任务（用 wbs-decomposition）
□ 标注关键路径和风险
□ 启动 progress-tracking
Cycle Execution (Middle)
□ 按编排模式执行（来自 orchestration）
□ 实时维护任务状态
□ 阻塞按 L1/L2/L3 升级
□ 不接受新需求（除紧急 bug）
□ 时间预算监控
Cycle End (End)
□ 验证 Cycle 目标是否达成
□ 时间到了砍范围（如果未完成）
□ 输出 Cycle 报告
□ 简短复盘（5 分钟）
Cooldown
□ 处理遗留小问题
□ 更新 field-journal
□ 沉淀经验
□ 准备下个 Cycle
Cycle Report Template
## Cycle 报告：[Cycle 名称]
### 基本信息
- Cycle 类型：Standard / Extended / Multi-Day
- 时间范围：[开始时间] ~ [结束时间]
- 实际耗时：X 小时
### Cycle 目标
[明确写出本 Cycle 要达成的目标]
### 完成情况
| 任务 | 状态 | 备注 |
|------|------|------|
| T1 | ✅ done | 按预期完成 |
| T2 | ✅ done | 比预期快 |
| T3 | ⚠️ rework | 验收未通过，下个 Cycle 修复 |
| T4 | ⏰ skipped | 时间不够，移到下个 Cycle |
### 关键交付物
- [产出 1]
- [产出 2]
### 阻塞和异常
- 阻塞 1：[描述] - 解决方式：[L1/L2/L3]
- 异常 1：[描述] - 影响：[评估]
### 下个 Cycle 准备
- 待修复：T3
- 待处理：T4
- 新需求：[列表]
### 简短复盘
- 做得好：[1~2 条]
- 待改进：[1~2 条]
- 沉淀：[field-journal 条目]
Cycle vs Sprint Comparison
| 维度 | Cycle | Sprint |
|------|-------|--------|
| 时间盒 | 灵活（30min ~ 多天） | 固定（通常 2 周） |
| 范围 | 可变 | 固定 |
| 估算 | 不估，按 Appetite | 详细估算 |
| 仪式 | 简化（Kickoff + 简短复盘） | 完整（Planning/Daily/Review/Retro） |
| 节奏 | 连续 + Cooldown | 连续 Sprint |
| 适合 | AI 工作流 / 小团队 | 传统团队 / 大项目 |
Workflow
1. Cycle 规划：
- 确定 Cycle 类型（Micro/Standard/Extended/Multi-Day）
- 设定 Appetite（时间盒）
- 明确 Cycle 目标
↓
2. Kickoff：
- 加载 wbs-decomposition + critical-path + orchestration
- 列出任务
- 启动 progress-tracking
↓
3. 执行：
- 不接受新需求
- 实时追踪状态
- 时间监控
↓
4. End：
- 验证目标
- 必要时砍范围
- 输出 Cycle 报告
↓
5. Cooldown：
- 处理遗留
- 更新 field-journal
- 准备下个 Cycle
Quality Self-Check
□ Cycle 目标是否可验证
□ Appetite 是否合理（不要 100h 的 Cycle）
□ 是否真的不接受新需求
□ 时间到了是否真的砍范围（不是延期）
□ 是否有 Cooldown
□ Cycle 报告是否输出
□ 简短复盘是否做了
Common Pitfalls
- No Appetite——falling into estimation hell again
- Cycle too long——losing flexibility
- Cycle too short——overhead exceeds benefits
- Accepting new requirements within a Cycle——breaking the time box
- No Cooldown——technical debt accumulates
- Cooldown is compressed——"time is tight" → losing digestion time
- Not doing a brief retrospective——losing experience
- Cycle report becomes a formality——not a truthful assessment
Supporting Templates
templates/cycle-kickoff-template.md— Cycle Kickoff Templatetemplates/cycle-report-template.md— Cycle Report Templatetemplates/cooldown-checklist-template.md— Cooldown Checklist
Collaboration with Other Skills
上游：
okr-alignment → 用 OKR 指导 Cycle 主题
平行：
wbs-decomposition → Cycle 内的任务分解
progress-tracking → Cycle 执行追踪
下游：
retrospective → Cycle 复盘
dora-metrics → Cycle 数据用于 DORA 计算