谈谈敏捷团队协作的那点事
序
"现在运营/产品/研发/测试不好，换一个可能还不如现在这个，忍着点，妥协点。"
这个想法，第一个悖论，为什么换了不一定有现在的好。其次，没有任何人有义务负责别人成长的。"你如果不成长，我们就换一个比你强的来。" —— 这是职场，不是过家家。
无论什么原因而造成的版本延期，这是一件多么严重的事情！这也许不关乎 KPI 考核，但这关乎团队的承诺。
无论是作为运营、产品、研发或测试，在自己的领域都需要定义自己的游戏规则和底线。制约别人，也约束自己。
问题
版本功能和发布计划在迭代中多次被修改，尤其是造成版本延期的故事。
版本需求在前期没有进行竞品分析。
部分需求和变更存在不合理，当出现问题时，多是靠打补丁方式进行补救。
规则
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.
