基于团队规模的迭代周期

Sprint Length By Team Scale · sprint-length-by-team-scale--ideal-sprint-length-designer-vs-pm-roles-running-pm-team-mee

解决什么问题

团队在选择敏捷开发周期时长，尤其是小团队是否应该采用标准的两周 Sprint 时面临的决策困难。

核心内容

2-3人的极小团队（Zachary Cohn 提出用 Kanban；Aadil Maan 更进一步认为不必关注 sprint、持续发布即可）：应完全放弃 Sprint 和正式敏捷流程，采用 Kanban（看板）方法持续交付。因为在这个规模下，Sprint 引入的规划和行政开销远超收益，且业务变化太快，不应等待 Sprint 结束才调整方向。
20人左右的工程团队（Tyler Wince、Josh）：多位实践者表示已抛弃正式的 2 周 Scrum，转用 Kanban，仅保留优先级排序、Standup 和 Retrospective 等常规仪式，以减少会议并增加灵活性。
大型复杂工程团队（Aadil Maan）：6周是开发周期的"神奇数字"（Goldilocks）。推荐采用 8 周为一个完整周期：6 周功能开发（前 2 周深入探索和规划，后 4 周冲刺交付）+ 2 周测试与收敛期（此期间不做任何新功能开发）。这种节奏比按季度发布更专注，不易偏航。

适用边界

适用于探讨工程团队开发节奏的早期至成熟期团队。对于需要快速验证的小团队，短周期或无周期更好；对于大型复杂系统（如 iOS/macOS/Android），长周期配合固定收敛期更有效。

关键引述 · 原话

"I would go further and suggest that at this scale, perhaps you shouldn't worry about sprints at all. Just focus on continuously shipping features out when you feel like you have something."（Aadil Maan）

"There is something goldilocks about 6wks."（Aadil Maan）

"At 2-3 people, I'd ditch more formal agile and use either an agile ban or a full-on kanban approach."（Zachary Cohn）

"FWIW, we ditched Scrum in our 20 person engineering team... and just do Kanban now."（Tyler Wince）

— Aadil Maan, Zachary Cohn, Tyler Wince & Josh

关联卡片

与 Shape Up (Basecamp) 提出的 6-week cycles 概念高度一致。

出处：Aadil Maan, Zachary Cohn, Tyler Wince & Josh · 02-newsletters/ideal-sprint-length-designer-vs-pm-roles-running-pm-team-meetings-running-post-m.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2+fixed