43 lines
1.6 KiB
Markdown
43 lines
1.6 KiB
Markdown
---
|
||
title: "Time Boxing"
|
||
type: concept
|
||
tags: [project-management, workflow-pattern, scope-control]
|
||
last_updated: 2026-04-25
|
||
---
|
||
|
||
## Definition
|
||
|
||
为每个工作阶段设定严格的时间上限（Time Box），无论该阶段是否"完成"，时间到达后必须停止并交付当前状态，进入下一阶段。
|
||
|
||
## Core Principle
|
||
|
||
Time Boxing 是对抗"完美主义"和"范围蔓延"的武器——在敏捷/Scrum 中广泛使用，在 Multi-Agent 工作流中同样有效。
|
||
|
||
## Usage in The Agency
|
||
|
||
- [[workflow-landing-page]]：每个 Agent 任务都有明确的时间盒
|
||
- 09:00–11:00：Content Creator + UI Designer（2小时并行）
|
||
- 11:00–14:00：Frontend Developer 构建（3小时）
|
||
- 14:00：完成第一版
|
||
- 14:00–14:30：Growth Hacker 审查（30分钟）
|
||
- 15:30：应用反馈完成
|
||
- 16:30：交付上线
|
||
- [[workflow-startup-mvp]]：每周一个阶段有明确交付物截止日期
|
||
- [[scenario-incident-response]]：P0 事件 15 分钟必须恢复，P1 1 小时内解决
|
||
|
||
## Why Time Box Works
|
||
|
||
1. **催促决策**：没有无限时间，团队必须优先处理最重要的部分
|
||
2. **可预测节奏**：所有参与者知道何时会有产出
|
||
3. **避免过度工程**：不追求完美的 100 分，而是在时间限制内交付 80 分的价值
|
||
4. **促进迭代**：第一版快速上线 → 收集真实反馈 → 下一轮 Time Box 改进
|
||
|
||
## Anti-Pattern
|
||
|
||
不要将 Time Boxing 变成"赶工"的借口。每个 Time Box 内部应该有明确的**最小可用产出（MVP）定义**，确保即使提前完成也能交付有价值的东西。
|
||
|
||
## Aliases
|
||
- Fixed Time Window
|
||
- Time Limit Discipline
|
||
- Sprint
|