敏捷迭代周期的探讨
我们的迭代计划安排是这样的，迭代周期是10个工作日（去除周末和假日），计划会议和 Review、Retro 不计算在迭代周内，每个迭代结束后的第二天召开Review和Retro，再下一天召开 Planning Meeting。
但是发现，团队的故事有时在迭代结束后仍没有完成，导致 Review、Retro 和 Planning Meeting 延后。或由于其他原因（如没有预定到会议室）没有即时召开会议，这样导致迭代之间团队变得非常混乱和散漫。
调整一
为了解决会议不能即时召开的问题，我们调整了迭代计划，变成了固定2周迭代，第一周的周一召开迭代计划，第二周的周五召开Review和Review。一个迭代结束之后马上开始第二个迭代。
这样的调整解决了会议的问题，我们如此实践了3个迭代（1个半月）！
This chapter requires login to view full content. You are viewing a preview.
Login to View Full ContentCourse Curriculum
1
建立敏捷基础 —— 让流程“跑起来”（2013–2014）
以敏捷宣言为起点，通过站会、Planning、Review 和 Retro 建立基本节奏；引入看板实现需求可视化，制定上线准备项等规则。结合 JCSM 培训、“棒球大联盟”游戏及影响地图实践，完成从认知到初步落地的跨越。
2
提升团队效能 —— 让协作“顺起来”（2015–2016）
聚焦跨职能协同与迭代质量，运用用户故事地图对齐目标，优化燃尽图使用，强化“响应变化”能力。通过披萨游戏、PMI/TiD 外部交流等方式激发团队共创，推动开发、产品、测试形成高效交付闭环。
3
穿越震荡周期 —— 让系统“稳下来”（2017–2018）
面对交付压力与团队变动，通过深度 Retro 重构看板规则，加强代码质量与 CI 实践。借助 OpenSpace 会议和外部转型交流，在混乱中重建协作秩序，锻造出更具韧性的敏捷运作机制。
4
驱动持续进化 —— 让组织“强起来”（2019）
技术 Leader 主导流程规范，明确 DoR/DoD，标准化演示与回顾机制。强调“看板整洁不能太放肆”，将规则转化为对 Scrum Master 的赋能，推动团队从执行敏捷走向自主持续改进。
Speaker
Songran Zhang
@Aliyun | Qwen Chat
Songran Zhang is senior systems architect at Aliyun, a speaker, and an author. Over the past 15 years, he's mastered architectures from cloud-native systems to AI-powered LLM platforms, building deep technical expertise across large-scale, high-availability systems.
