2014年,记一次敏捷Retro的会议记录

问题

Standing Meeting

之前7~8人的早会,大家都很爱发言;现在15~20人的早会,每个人都不爱说话啦

当团队大了之后,且之间合作密切的时候,SOS也不会很好地解决问题

Planning Meeting

1. 计划会议之前没有设计评审,故事拆分都是调研、设计、开发和测试,评估2周开发,这和瀑布开发有什么区别?迭代过半之后基本没有指导作用

This chapter requires login to view full content. You are viewing a preview.

Login to View Full Content

Course Curriculum

1

建立敏捷基础 —— 让流程“跑起来”(2013–2014)

以敏捷宣言为起点,通过站会、Planning、Review 和 Retro 建立基本节奏;引入看板实现需求可视化,制定上线准备项等规则。结合 JCSM 培训、“棒球大联盟”游戏及影响地图实践,完成从认知到初步落地的跨越。
3

穿越震荡周期 —— 让系统“稳下来”(2017–2018)

面对交付压力与团队变动,通过深度 Retro 重构看板规则,加强代码质量与 CI 实践。借助 OpenSpace 会议和外部转型交流,在混乱中重建协作秩序,锻造出更具韧性的敏捷运作机制。
4

驱动持续进化 —— 让组织“强起来”(2019)

技术 Leader 主导流程规范,明确 DoR/DoD,标准化演示与回顾机制。强调“看板整洁不能太放肆”,将规则转化为对 Scrum Master 的赋能,推动团队从执行敏捷走向自主持续改进。