敏捷开发

瀑布模型是软件工程史上第一个被广泛采用的过程模型，1970 年代初被引入，其形态借鉴自制造业与建筑业的线性流程，进度自上而下推进，如同水流沿瀑布逐级下落。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

瀑布模型把开发划分为需求、设计、执行（编码与测试）、确认、维护等离散阶段，每个阶段必须在前一阶段完成后才开始，阶段之间是严格的串行关系。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开|55数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

由于阶段串行，当某一阶段正在进行时，其下游阶段全部处于等待与阻塞状态，团队资源被闲置，整体效率被拉低——这是瀑布模型在资源利用上的结构性缺陷。^{55数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|66数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

瀑布模型要求在进入设计与开发之前一次性收集齐全部客户需求，需求收集是交付软件前唯一面向客户的阶段，此后需求被视为冻结。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

瀑布模型对需求变化不敏感、难以响应客户需求的变动；一旦团队推进越过了设计阶段，再修改产品的成本就会变得很高。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

在传统瀑布模型下，无论发布规模大小，两次发布之间的平均时间为一到两年，交付节奏以年为单位而非以周或月为单位。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

瀑布模型的优势在于为软件开发提供了集中、标准化的方法，易于管理，并让公司对预算与截止日期保有可见性和可预测的可交付成果；其局限并不在于不可管理，而在于缺乏灵敏性。^{77浅谈如何查找更适合软件开发且有效的模型 - 腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

1990 年代万维网开启商业化浪潮，以浏览器为核心的 Web 应用大规模增长，应用边界不断扩张，这种急剧变化的需求对当时的软件工程与开发模式形成冲击，构成了呼唤新开发方法的外部压力。^{66数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|55数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

1985 年后超大规模集成电路的迅猛发展带来算力的大幅提升，为应用的规模化发展提供了技术支撑，也使旧有开发流程与新的生产力之间的矛盾日益突出。^{66数字化 IT 从业者知识体系 | 软件开发方法 —— 敏捷篇-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

二十世纪九十年代出现的一批轻量级软件开发方法，是作为对当时流行的、被批评者形容为管理严格、计划繁重、微观管理的“重量级”方法的回应而发展起来的。^{88敏捷开发scrum.cn前往参考资料 ↓在新标签页中打开|99敏捷开发在互联网时代里的价值-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

这些轻量级方法在时间上先后出现：快速应用程序开发（RAD）始于1991年，统一过程与动态系统开发方法（DSDM）始于1994年，Scrum始于1995年，Crystal Clear与极限编程（XP）始于1996年，特征驱动开发（FDD）始于1997年。^{88敏捷开发scrum.cn前往参考资料 ↓在新标签页中打开}

上述方法大多在2001年《敏捷软件开发宣言》发布之前就已成形，后来才被统称为“敏捷软件开发方法”；换言之，敏捷宣言是对既有轻量级实践的事后归纳与命名，而非这些方法的起点。^{88敏捷开发scrum.cn前往参考资料 ↓在新标签页中打开|99敏捷开发在互联网时代里的价值-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

轻量级方法兴起的动因之一是市场环境的变化：上世纪八九十年代市场需求相对稳定、大型项目更新缓慢，瀑布式流程是首选；随着需求变化加快，瀑布、喷泉、螺旋等传统模型难以快速灵活地适应，才催生了迭代与增量式的轻量化方法。^{99敏捷开发在互联网时代里的价值-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

迭代与增量式的软件开发实践本身早于九十年代的轻量级方法：可追溯到1957年，进化式项目管理与自适应软件开发在七十年代初期即已出现。^{88敏捷开发scrum.cn前往参考资料 ↓在新标签页中打开}

与软件业轻量级方法兴起大致同期，制造业与航空航天业也发生了类似的管理变革，说明这一转向并非软件行业独有。^{88敏捷开发scrum.cn前往参考资料 ↓在新标签页中打开}

2001 年，17 位软件开发领域的领军人物聚集在美国犹他州的一个滑雪胜地（雪鸟雪场），共同发布《敏捷宣言》，敏捷开发由此作为一种新的软件开发管理模式和价值观开始推广。^{1010跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开|1111跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开}

雪鸟会议的地点常被表述为“滑雪胜地雪鸟雪场”，即美国犹他州的 Snowbird 滑雪度假地；这一地点信息在中文技术媒体的回顾性报道中被反复沿用。^{1010跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开|1111跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开}

在中文技术媒体的回顾中，雪鸟会议被定位为敏捷从“理论或流派讨论”走向“普及应用”的起点：会议之后数年，业界讨论长期停留在“什么是敏捷开发、敏捷开发的价值何在”这类问题上，而如何把敏捷精神与原则融入团队日常活动与工具使用，则成为后续关注点。^{1010跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开|1111跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开}

微软在 2010 年前后的中文材料中，把雪鸟会议视为敏捷开发进入推广期的标志性事件，并将敏捷描述为“以人为核心”、强调团队成员之间以及开发团队与客户之间充分沟通的开发模式。^{1010跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开|1111跟微软学敏捷开发learn.microsoft.com前往参考资料 ↓在新标签页中打开}

Scrum 是当前应用最广泛的敏捷开发框架之一，其基本思路是由小型、自组织的团队通过短周期迭代持续交付可用的产品增量，并依据反馈不断调整。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开|1515敏捷开发方法：理论与实践-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

Scrum 的核心迭代单位称为 Sprint（冲刺），长度通常为 2 至 4 周，每个 Sprint 结束时应当产出一个可用的、潜在可发布的产品增量。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

Scrum 定义了三种基本角色：产品负责人（Product Owner）负责定义和排序需求、对产品价值负责；Scrum Master 负责保障流程运转、帮助团队理解并践行 Scrum 规则；开发团队负责实际的开发与交付工作。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开|1515敏捷开发方法：理论与实践-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

每日站会（Daily Standup）是 Scrum 的日常仪式之一，团队成员每天用很短的时间同步进展、当日计划与遇到的障碍，目的是暴露问题、促进协作，而不是向上级汇报。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

Scrum 常被归纳出的优势包括：提升团队协作与沟通、通过频繁交付增量更快获取客户反馈、以及借助每个 Sprint 的回顾形成持续改进机制。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开|1515敏捷开发方法：理论与实践-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

在敏捷方法谱系中，Scrum 与看板（Kanban）、极限编程（XP）、DSDM、特征驱动开发（FDD）和水晶法并列，是若干常见敏捷方法之一；不同方法在迭代节奏、角色设置与实践重点上各有侧重，适用于不同类型的项目与团队。^{1414敏捷开发的6大方法与模型，帮助你快速适应项目需求变化-阿里云开发者社区developer.aliyun.com前往参考资料 ↓在新标签页中打开}

极限编程（Extreme Programming，XP）是敏捷方法族中最强调工程实践的一支，由肯特·贝克（Kent Beck）在 20 世纪 90 年代末提出，其核心思路是把被认为「有益但难得做好」的实践推到极致：如果代码评审有益，就做持续评审（结对编程）；如果测试有益，就让测试先于代码（测试驱动开发）；如果集成有益，就一天集成多次。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 的实践通常被划分为四类：fine-scale feedback（细粒度反馈）、continuous process（持续过程）、shared understanding（共享理解）与 programmer welfare（程序员福祉）。其中细粒度反馈包括结对编程、计划游戏、测试驱动开发、全体团队；持续过程包括持续集成、重构、小版本发布；共享理解包括编码规范、集体代码所有权、简单设计、系统隐喻；程序员福祉包括每周 40 小时工作制。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

结对编程是 XP 的标志性实践：两名程序员在同一台机器、同一个设计上并肩工作，一人写代码（driver），一人实时审视（navigator），并频繁交换角色。它把代码评审从阶段性活动变成持续活动，同时承担知识传播与缺陷预防的功能。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

测试驱动开发（TDD）是 XP 的工程核心：先写一个失败的单元测试，再写刚好能让它通过的产品代码，最后重构。XP 的表述是「编写所有产品代码的目的都是为了使失败的单元测试能够通过」，测试由此成为需求的 executable 形式与设计的驱动力。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 主张简单设计（simple design）：团队让设计尽可能简单、富有表现力，不为可预见的未来需求预先搭建基础设施，例如不一开始就选定数据库或中间件，而是以最简单的方式实现第一批用户故事，等真实需求出现时再通过重构演进设计。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

集体代码所有权（collective code ownership）是 XP 的共享理解实践之一：团队中任何人都可以在任何时候改进任何一段代码，而不必先获得「模块所有者」的许可。它与结对编程、编码规范、持续集成配合，用来降低知识集中在个别人身上的风险。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

系统隐喻（metaphor）是 XP 用于共享理解的实践：团队提出一个关于「程序如何工作」的公共图景，用统一的词汇描述系统结构，使成员在缺少大量前期设计文档的情况下仍能对架构形成一致理解。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 对需求采取「反复讨论、不提前固化细节」的态度：在真正实现某条需求还很早的时候就去捕获它的特定细节，很可能造成无用功和对不成熟需求的过度关注；因此团队与客户反复沟通以理解需求，但不在早期把细节写成不可更改的规格。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 的计划游戏（planning game）以短周期滚动计划取代一次性详细计划：为下两周做详细计划，为下三个月做粗略计划，更远的未来只做极粗糙的计划。其依据是计划在形态上会变化，而不只是日期滑动，因此预先画好的详细计划图并不适用。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 把可持续的工作节奏视为工程实践而非福利口号：团队测量自己的速度（velocity），不允许长期加班与透支，主张以能在整个项目期间维持最高质量标准的速度工作，因为跑得过快会导致短期行为和最终的崩溃。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 强调团队是自组织的（self-organizing）：不能把程序员当作可插拔的组件来管理，人不是「插入即兼容的编程装置」；要取得成功必须构建有合作精神的自组织团队，并持续调整团队的组织方式、规则、规范与关系，以适应不断变化的环境。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

XP 认为代码是唯一没有二义性的信息源，因此把重构、编码规范、持续集成等围绕代码的实践放在比文档更基础的位置；这与「大而笨重的过程会产生它本来企图去解决的问题」的判断一致——过重的过程会降低效率、拖长进度、推高预算并削弱响应能力。^{1616《敏捷软件开发：原则、模式与实践》笔记-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|1717《敏捷软件开发：原则、模式与实践》笔记 - 阅读清单 - 腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

看板（Kanban）是敏捷实践中一种以可视化工作流程和限制在制品数量为核心的框架：团队用看板上的列表示工作流的不同阶段，任务从“待办”列被拉入并逐列推进直至完成。^{1818敏捷方法论：拥抱灵活性、协作与持续改进，以实现有效的项目管理 - Visual Paradigm Guides Simplified Chineseguides.visual-paradigm.com前往参考资料 ↓在新标签页中打开}

精益（Lean）在敏捷语境下指一套以减少浪费、最大化客户价值为目标的框架，通过消除非增值活动、优化增值活动来实现持续改进；精益软件开发由 Tom 与 Mary Poppendieck 引入敏捷社群，其原则与实践取自丰田生产系统。^{1818敏捷方法论：拥抱灵活性、协作与持续改进，以实现有效的项目管理 - Visual Paradigm Guides Simplified Chineseguides.visual-paradigm.com前往参考资料 ↓在新标签页中打开|1919（五）敏捷方法（实践）有哪些？-腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

《敏捷实践指南》把敏捷方法与看板方法都视为精益方法的子集，理由是二者都是精益思想的具体实例，共同体现“关注价值”“小批量”“消除浪费”等概念。^{1919（五）敏捷方法（实践）有哪些？-腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

精益软件开发常被归纳为若干条原则，包括消除浪费、尽快交付、增强学习、团队授权、较迟决定、建立整体（把质量嵌入系统，依靠自动化测试、安装与持续集成）以及目光长远、快速试错快速学习。^{1919（五）敏捷方法（实践）有哪些？-腾讯云开发者社区-腾讯云developer.cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

在敏捷落地方法的谱系中，Scrum、看板、精益开发与极限编程被并列为最广为人知的几种实现路径；由于敏捷本身只给出简明扼要的准则、不规定具体步骤，这些方法多是从实践中总结衍生而来，彼此存在衍生或互补关系，因此严格横向比较并不容易。^{2020实现敏捷框架的比较：Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

看板与 Scrum 在机制上存在明显差异：Scrum 把工作切分为固定长度的冲刺、以一组用户故事为工作单元并配套站会与冲刺评审；看板则不预设迭代边界，强调按工作流状态持续拉动任务并限制各阶段的在制品数量。^{1818敏捷方法论：拥抱灵活性、协作与持续改进，以实现有效的项目管理 - Visual Paradigm Guides Simplified Chineseguides.visual-paradigm.com前往参考资料 ↓在新标签页中打开|2020实现敏捷框架的比较：Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

特性驱动开发（Feature-Driven Development，FDD）由 Jeff De Luca 与 Peter Coad 于 1997 年前后在新加坡一个大型银行软件开发项目中提出并成形，其标志性成果是 1999 年出版的《Java Modeling in Color with UML》一书，书中系统描述了 FDD 的建模与过程要素。^{2121Java Modeling in Color with UML: Enterprise Components and Processamazon.com前往参考资料 ↓在新标签页中打开}

FDD 的过程由五个阶段组成：开发整体模型、构建特性列表、按特性制定计划、按特性设计、按特性构建；其中后两个阶段以两周左右为周期、以单个“特性”（可在两周内完成、对客户有价值的最小功能单元）为单位迭代推进。^{2121Java Modeling in Color with UML: Enterprise Components and Processamazon.com前往参考资料 ↓在新标签页中打开|2222Feature-Driven Development (FDD) — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开}

FDD 在角色设置上强调“首席程序员”（Chief Programmer）与“类属主”（Class Owner）的分工：首席程序员负责特性团队内的设计与指导，类属主对特定类的代码一致性负责，这一设计被认为借鉴了贝尔实验室和 Cleanroom 工程中的首席程序员实践。^{2121Java Modeling in Color with UML: Enterprise Components and Processamazon.com前往参考资料 ↓在新标签页中打开|2222Feature-Driven Development (FDD) — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开}

FDD 以“特性”而非“用户故事”作为计划与跟踪的基本单位，并强调在编码前先建立领域模型（包括颜色建模）和一份按业务活动分组的特性列表，这与 Scrum 以产品待办列表和冲刺为单位、XP 以用户故事和工程实践为中心的做法形成对照。^{2121Java Modeling in Color with UML: Enterprise Components and Processamazon.com前往参考资料 ↓在新标签页中打开|2222Feature-Driven Development (FDD) — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开}

水晶方法族（Crystal Methods）由 Alistair Cockburn 提出，按项目规模与关键性把方法分为 Clear、Yellow、Orange、Red 等不同“颜色”，其核心主张是：方法应当随项目规模和人员数量调整，越大的项目需要越多的仪式与协调，而不是一套方法适用于所有项目。^{2323Crystal Methods — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开}

动态系统开发方法（DSDM）起源于 1990 年代英国的快速应用开发实践，1995 年发布 DSDM 框架，其核心是固定时间与资源、按 MoSCoW 优先级（必须有、应该有、可以有、本次不会有）调整范围，并强调在项目早期就交付可用成果。^{2424DSDM Agile Project Framework — Handbookagilebusiness.org前往参考资料 ↓在新标签页中打开}

DSDM 在 2007 年前后发布的 DSDM Atern 版本转向与敏捷宣言对齐，2014 年又更名为 DSDM Agile Project Framework，把治理、持续业务价值与团队协作放在框架中心，是少数明确面向项目治理层面的敏捷方法。^{2424DSDM Agile Project Framework — Handbookagilebusiness.org前往参考资料 ↓在新标签页中打开}

精益软件开发（Lean Software Development）由 Mary 与 Tom Poppendieck 在 2003 年的同名著作中系统提出，把丰田生产方式的七类浪费（部分完成的工作、额外功能、重新学习、交接、任务切换、等待、缺陷）映射到软件开发，并给出消除浪费、内建质量、延迟决策等原则。^{2525Lean Software Development: An Agile Toolkitamazon.com前往参考资料 ↓在新标签页中打开}

看板方法（Kanban）在软件开发中的推广主要归功于 David J. Anderson 2010 年的《Kanban》一书，其核心实践包括可视化工作流、限制在制品数量、管理流动、显式化流程规则与反馈回路，与以固定长度迭代为特征的 Scrum 在节奏机制上不同。^{2626Kanban: Successful Evolutionary Change for Your Technology Businessamazon.com前往参考资料 ↓在新标签页中打开}

Scrum 由 Ken Schwaber 与 Jeff Sutherland 在 1990 年代提出，其 2020 年版《Scrum 指南》把框架定义为由 Scrum 团队、事件、工件及其规则构成的轻量框架，并明确以经验过程控制（透明、检视、适应）为理论基础。^{2727The Scrum Guide (2020)scrumguides.org前往参考资料 ↓在新标签页中打开}

极限编程（XP）由 Kent Beck 在 1999 年的《Extreme Programming Explained》中提出，其第二版把实践分为主要实践与辅助实践，包括结对编程、测试驱动开发、持续集成、小型发布、重构与集体代码所有权等，是敏捷方法中工程实践密度最高的一支。^{2828Extreme Programming Explained: Embrace Change (2nd Edition)amazon.com前往参考资料 ↓在新标签页中打开}

在敏捷方法的比较研究中，FDD 常被归类为“模型驱动”或“架构中心”的敏捷方法，其前期建模投入比 Scrum、XP 更重，因而被认为更适合领域复杂、团队规模较大且需要较强架构一致性的项目；但这一适配性判断主要来自实践者经验总结，缺乏大规模对照实验证据。^{2222Feature-Driven Development (FDD) — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开|2929A Survey of Agile Software Development Methodsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

多项敏捷方法比较研究指出，各方法在价值观层面共享敏捷宣言的四条价值，但在迭代长度、计划单位、角色定义与工程实践强度上差异显著，因此“敏捷方法”并非单一可互换的实践集合，选型需结合项目规模、领域复杂度与组织约束。^{2222Feature-Driven Development (FDD) — Agile Alliance Glossaryagilealliance.org前往参考资料 ↓在新标签页中打开|2929A Survey of Agile Software Development Methodsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

Scrum 框架定义了三个角色：产品负责人（Product Owner）、Scrum Master（团队负责人）与开发团队（Development Team）。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

产品负责人负责确定产品的功能与达到要求的标准，维护产品待办事项列表（Product Backlog），并明确软件交付的内容。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

产品负责人有权力接受或拒绝开发团队的工作成果，并且是产品待办事项优先级变更的最终决定者；改变产品待办事项的优先级都必须经过产品负责人。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

产品负责人可以亲自完成待办事项梳理等工作，也可以委托开发团队完成，但产品负责人对产品待办事项列表负最终责任。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

Scrum 的机制建立在透明、检查、适应三个支柱之上：关键环节对相关人可见且理解一致，团队频繁检视工件与 Sprint 目标的进展，一旦发现偏离可接受范围就尽快调整过程或过程化内容。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

Scrum 规定了四个仪式（Sprint 计划会、每日站会、Sprint 评审会与 Sprint 回顾会），用于对过程与工件进行检视和适应。^{3232PMI-ACP考试知识点：常见的敏捷实践（1）_国际认证_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

在 Scrum 框架中，冲刺计划会（Sprint Planning）是每个冲刺开始时举行的第一个事件，其目的是确定本次冲刺的目标以及为达成目标需要完成的任务，即回答“这个冲刺做什么、怎么做”。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

冲刺计划会产出的核心工件是冲刺待办列表（Sprint Backlog），它由产品待办列表中挑选出的条目构成，并按任务粒度拆解，作为本次冲刺期间团队工作的依据。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

每日站会（Daily Scrum）是冲刺期间每天举行的短会，用于同步进展、暴露障碍，使团队能够及时调整当天的工作安排，而不是向上级汇报进度。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

冲刺评审会（Sprint Review）在冲刺结束时举行，团队向利益相关者展示本次冲刺交付的增量成果并收集反馈，其关注点是“做出来的东西对不对、有没有价值”，而非流程本身。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

冲刺回顾会（Sprint Retrospective）在评审会之后举行，团队反思协作过程与方法，识别可改进之处并形成后续行动项，是 Scrum 中承载持续改进（ Kaizen ）意图的固定环节。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

Scrum 的五个事件——冲刺、冲刺计划会、每日站会、冲刺评审会、冲刺回顾会——共同构成固定的节奏，使团队始终处于“检视与调整”的循环之中；其中冲刺本身是一个通常为一到四周的固定时间盒。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

冲刺评审会与冲刺回顾会的职能被明确区分：前者面向产品增量、对外收集反馈，后者面向团队过程、对内改进工作方式，二者不可互相替代。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

这些仪式若被机械照搬为形式化的会议流程，而失去拥抱变化与持续改进的实质，往往适得其反；因此仪式本身不是目的，而是支撑检视与调整的手段。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

在 Scrum 框架中，产品待办列表（Product Backlog）与冲刺待办列表（Sprint Backlog）是三个正式工件中的两个，第三个是产品增量；三者与三个角色、五个事件共同构成 Scrum 的「3-3-5」结构。^{3434什么是Scrum？apmg-international.com前往参考资料 ↓在新标签页中打开|3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开}

产品待办列表是一份按优先级排序的、产品中所有待完成事项的清单，由产品负责人负责维护和持续更新，回答「要做什么」的问题。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开}

冲刺待办列表是本次冲刺要完成的任务清单，由团队在冲刺计划会上从产品待办列表中选取条目后形成，是冲刺计划活动的输出。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开}

产品待办列表与冲刺待办列表之间存在层级关系：每一次冲刺都从产品待办列表中选取一部分条目，组成该次冲刺的待办列表，因此冲刺待办列表是产品待办列表在单个迭代内的子集。^{3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开|3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

产品待办列表的排序与梳理通常在产品梳理会（Backlog Refinement）上进行，由产品负责人与产品经理对需求进行评审、梳理并设置优先级，会议输出即为更新后的产品待办列表。^{3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开}

用户故事是填充产品待办列表的常见需求表达方式，把需求写成用户视角的故事并配合验收标准，使开发团队明确要交付什么、做到什么程度才算完成。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

产品待办列表的优先级维护被普遍归为产品负责人的职责，而冲刺待办列表的产出则发生在冲刺计划会上，二者分别对应「做什么」与「本次迭代做哪些」两个层次的决策。^{3333敏捷开发Scrum框架的核心实践与角色是什么_IT管理_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|3535Scrum 的三大角色、三大工件、五大会议分别指什么？tower.im前往参考资料 ↓在新标签页中打开}

Scrum 的规则把角色、事件与工件联系在一起，工件并非孤立文档，而是与冲刺计划、冲刺评审等事件相互衔接的活动载体。^{3434什么是Scrum？apmg-international.com前往参考资料 ↓在新标签页中打开}

在敏捷开发语境中，速度（velocity）通常指团队在一个迭代（冲刺）内实际完成的、以故事点或其他估算单位计量的工作量；它被用作预测未来迭代可承载工作量的经验性依据，而非对个人产出的考核指标。^{4141Five agile metrics you wonatlassian.com前往参考资料 ↓在新标签页中打开}

冲刺燃尽图（sprint burndown chart）以时间为横轴、以剩余工作量为纵轴，逐日描绘一个迭代内剩余工作的下降轨迹，用于直观呈现团队是否按计划逼近迭代目标，并在曲线偏离理想线时提示范围变更或进度风险。^{4141Five agile metrics you wonatlassian.com前往参考资料 ↓在新标签页中打开}

敏捷指标被定位为跟踪团队与项目进度、质量与效能的量化手段，其常见集合包括速度、提前期、周期时间、燃尽图与累积流图；这些指标的用途被描述为识别瓶颈、预测交付时间并推动持续改进。^{4141Five agile metrics you wonatlassian.com前往参考资料 ↓在新标签页中打开}

尽管软件工程研究反复强调绩效度量在使用敏捷方法时的重要性，但文献对如何在实践中具体应用这些度量、以及应用过程中会遇到哪些挑战，仍缺乏细节层面的说明；一项混合方法研究即以识别这些挑战为核心目标。^{4040How to Measure Performance in Agile Software Development? A Mixed-Method Studyieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

由于敏捷方法高度关注动态市场中的短期成效，质量与绩效的度量在敏捷软件开发中被视为具有高度重要性，并与软件过程改进能否成功直接相关。^{4040How to Measure Performance in Agile Software Development? A Mixed-Method Studyieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

速度与燃尽图都属于派生型度量：它们的数值依赖于团队自身的故事点估算口径与迭代长度，因此跨团队直接比较绝对数值缺乏意义，通常只适合同一团队在自身历史数据上做趋势对比与预测。^{4141Five agile metrics you wonatlassian.com前往参考资料 ↓在新标签页中打开}

在敏捷转型的评估实践中，度量通常被划分为定量评估与定性评估两类，并强调面向结果而非面向活动的评估取向；这一划分常见于中文敏捷转型实务著作的整理中。^{4242敏捷转型 打造VUCA时代的高效能组织（王明兰 著） 思维导图模板_ProcessOn思维导图、流程图processon.com前往参考资料 ↓在新标签页中打开}

团队能力评估的一种常见做法是让成员自评打分并录入数据库，作为后续新项目立项与人员配置的参考，目的是让员工能力与项目需求相匹配，避免明显不胜任或过度胜任。^{4242敏捷转型 打造VUCA时代的高效能组织（王明兰 著） 思维导图模板_ProcessOn思维导图、流程图processon.com前往参考资料 ↓在新标签页中打开}

敏捷团队能力发展的一个流行提法是「T型团队」：成员既有自己的专长深度，又具备跨领域的通识广度，能在他人需要时提供帮助；与之配套的做法是把产品所需技能逐一列出形成技能地图，并以产品负责人给出的高优先级 Backlog 与产品路线图作为技能地图的重要输入。^{4242敏捷转型 打造VUCA时代的高效能组织（王明兰 著） 思维导图模板_ProcessOn思维导图、流程图processon.com前往参考资料 ↓在新标签页中打开}

跨职能自组织团队被描述为拥有完成工作所需的全部技能、不依赖团队以外的人；跨职能包含跨工种（产品、架构设计、用户体验设计、开发、测试、运维等）与跨领域（前端、后端、中间件等）两个维度，其论证常引用康威定律，即系统架构是组织沟通结构的写照。^{4242敏捷转型 打造VUCA时代的高效能组织（王明兰 著） 思维导图模板_ProcessOn思维导图、流程图processon.com前往参考资料 ↓在新标签页中打开}

规模化敏捷框架（Scaled Agile Framework，简称 SAFe）是一套组织与工作流原则、实践及能力体系的知识库，旨在帮助组织——尤其是拥有复杂产品组合的大型企业——实现大规模敏捷转型，把精益、敏捷、DevOps 与系统思维整合为统一的可扩展模型。^{4444什么是规模化敏捷框架 (SAFe)？| IBMibm.com前往参考资料 ↓在新标签页中打开}

SAFe 由 Dean Leffingwell 于 2011 年提出，目标是解决传统项目管理流程在软件交付中的缺陷，提高大规模软件开发的速度、质量与客户关注度；Leffingwell 同时是负责管理该框架的 Scaled Agile Inc. 的共同创始人。^{4444什么是规模化敏捷框架 (SAFe)？| IBMibm.com前往参考资料 ↓在新标签页中打开}

SAFe 围绕业务敏捷性的七项核心能力构建：精益敏捷领导力、团队和技术敏捷性、敏捷产品交付、企业解决方案交付、精益投资组合管理、组织敏捷性、持续学习文化。^{4444什么是规模化敏捷框架 (SAFe)？| IBMibm.com前往参考资料 ↓在新标签页中打开}

SAFe 目前处于第六次迭代（SAFe 6.0），提供四种配置以适应不同规模、结构和业务需求的组织：Essential SAFe、Large Solution SAFe、Portfolio SAFe 和 Full SAFe。^{4444什么是规模化敏捷框架 (SAFe)？| IBMibm.com前往参考资料 ↓在新标签页中打开}

按国内行业媒体的概括，SAFe 通过「项目群级—价值流级—投资组合级」的分层架构，为大型组织提供从战略规划到团队迭代的全链路协同机制；其核心机制之一是项目群增量规划（PI Planning），即每隔约 8 至 12 周组织一次相关团队共同参与的面谈式规划，用于对齐目标、识别依赖、排除障碍。^{4343敏捷2026：规模化敏捷落地困境与SAFe框架的中国实践_IT管理_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

团队级 Scrum 与看板普及之后，多团队协同交付同一产品时会暴露「单团队敏捷」的边界问题：各团队迭代节奏不一致、跨团队依赖管理混乱、产品路线图难以在多团队间有效传导，整体交付效率可能不升反降——这正是规模化敏捷框架要回应的场景。^{4343敏捷2026：规模化敏捷落地困境与SAFe框架的中国实践_IT管理_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

有国内行业观察指出，SAFe 在中国企业落地面临两类本土化挑战：一是组织文化冲突，SAFe 要求管理层把决策权下放至团队，而部分企业仍习惯高度集中的自上而下指令模式，与自组织原则存在张力；二是工具链适配，官方推荐工具（如 Jira Align）在国内面临数据合规与本土化支持问题，企业常需在飞书、企业微信生态中自建工具链。^{4343敏捷2026：规模化敏捷落地困境与SAFe框架的中国实践_IT管理_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

国内实践者提出的落地经验是「从最痛的点切入」：先聚焦跨团队依赖管理这一最普遍的痛点，建立简化版的 PI Planning 机制，见到效果后再逐步扩展到更完整的框架应用，即所谓「价值优先、框架后行」。^{4343敏捷2026：规模化敏捷落地困境与SAFe框架的中国实践_IT管理_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

SAFe 设有分级认证体系，覆盖从普通团队成员到 SPC（SAFe 项目顾问，SAFe Program Consultant）的完整路径，由 Scaled Agile Inc. 管理。^{4343敏捷2026：规模化敏捷落地困境与SAFe框架的中国实践_IT管理_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开|4444什么是规模化敏捷框架 (SAFe)？| IBMibm.com前往参考资料 ↓在新标签页中打开}

Nexus 与 LeSS 是规模化敏捷框架中少数严格坚持「单一产品负责人、单一产品待办列表」的框架：两者都要求每个面向真实客户的产品只有一个 Product Owner 和一个 Product Backlog，而不采用团队级 Product Owner 的做法。^{4545How do Nexus and LeSS Differ?scrum.org前往参考资料 ↓在新标签页中打开}

LeSS（Large-Scale Scrum，大规模 Scrum）的优化目标是适应性（adaptiveness），即让变更变得廉价而容易；其理由有两点：一是人们普遍不擅长预测什么会命中客户价值，需要以低成本试错来发现方向；二是外部世界（竞争对手、技术、市场）本身在持续变化。^{4545How do Nexus and LeSS Differ?scrum.org前往参考资料 ↓在新标签页中打开}

Nexus 与 LeSS 面向的是三个以上团队、乃至数十个团队协作开发同一个面向客户产品的场景，二者在结构上有大量共同点，差异主要体现在成熟度模式与具体规则的取舍上。^{4545How do Nexus and LeSS Differ?scrum.org前往参考资料 ↓在新标签页中打开}

LeSS 采取「少即是多」的路线：它不引入新的角色、仪式与工件层级，而是把单团队 Scrum 的元素原样放大到多团队，靠团队自组织与整体回顾来应对规模化带来的复杂度。^{4545How do Nexus and LeSS Differ?scrum.org前往参考资料 ↓在新标签页中打开}

Nexus 在单团队 Scrum 之上增加了一个 Integration Team（集成团队）与 Nexus Sprint Backlog、Nexus Sprint Review 等跨团队活动，用以处理多团队之间的依赖与集成问题；这与 LeSS 尽量不增设新结构的取向形成对照。^{4545How do Nexus and LeSS Differ?scrum.org前往参考资料 ↓在新标签页中打开}

规模化敏捷面临的首要挑战是「协调成本随团队数量超线性增长」：当多个敏捷团队共享同一产品、同一代码库或同一发布节奏时，团队间的依赖管理与集成协调工作量会迅速超过单个团队内部的协作成本，原本在单团队层面有效的自组织与面对面沟通机制在跨团队场景下失效。^{4646Scaling Agile: Findings from the Literatureieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|4747Agile at Scalehbr.org前往参考资料 ↓在新标签页中打开}

SAFe（Scaled Agile Framework）在其官方文档中承认，规模化实施的主要障碍并非框架本身，而是组织现有的治理结构、预算模式与合规要求：传统的年度预算与项目制拨款方式与敏捷的增量投资决策节奏不匹配，导致规模化落地时出现「框架已就位、决策仍按旧周期走」的脱节。^{4848SAFe Reference Guide: Implementation Roadmapscaledagileframework.com前往参考资料 ↓在新标签页中打开}

规模化敏捷的度量挑战在于：单团队层面的速度（velocity）与燃尽图等指标在跨团队聚合时失去可比性，不同团队对故事点的估算基准不一致，导致组织级度量往往退化为「产出数量」而非「价值交付」，难以支撑投资决策。^{5050Metrics for Agile Software Development: A Systematic Literature Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开}

规模化敏捷在受监管行业（如金融、医疗、汽车）中面临合规与审计证据链的挑战：敏捷的迭代式需求变更与轻量文档实践，与需要可追溯需求基线、变更审批记录和验证证据的监管要求之间存在结构性摩擦，组织往往需要额外建立「敏捷—合规」映射机制才能同时满足两者。^{5151Agile and Regulatory Compliance: Challenges and Practicesieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

规模化敏捷的失败案例中，一个反复出现的模式是「照搬框架仪式而不同步调整组织结构」：组织引入规模化框架的规划会、同步会等仪式，但未改变职能型部门壁垒与汇报关系，导致仪式空转、决策仍在旧结构中做出，规模化投入未能转化为交付改善。^{5252Why Agile Transformations Failmckinsey.com前往参考资料 ↓在新标签页中打开}

规模化敏捷还面临「局部优化与全局优化冲突」的挑战：单个团队按敏捷实践优化自身交付节奏后，若上游需求方与下游运维方仍按批次式节奏运作，团队间的节奏错配会在集成点与发布点形成新的瓶颈，整体流动效率未必提升。^{5353The Principles of Product Development Flow: Second Generation Lean Product Developmentamazon.com前往参考资料 ↓在新标签页中打开}

在汽车行业，硬件开发传统上遵循与整车生产节点绑定的严格瀑布流程，而软件开发团队则追求敏捷节奏，两套方法论长期处于彼此分离的状态；智能座舱供应商的实践表明，二者不必二选一，而是可以在同一平台上协调。^{5454Hoe de joint venture van een wereldwijde autofabrikant meer dan 500 R&D-gebruikers over In-Car- en Out-Car-systemen verenigdeones.com前往参考资料 ↓在新标签页中打开}

嵌入式系统与 OTA 相关项目具有硬件长周期特征：新车型与固件绑定项目需要瀑布式的纪律、检查点治理和供应商协调，并与整车量产启动（SOP）时间线对齐，这构成了软件迭代节奏的外部约束。^{5454Hoe de joint venture van een wereldwijde autofabrikant meer dan 500 R&D-gebruikers over In-Car- en Out-Car-systemen verenigdeones.com前往参考资料 ↓在新标签页中打开}

协调硬件长周期与软件迭代的一种常见做法，是在组织层面保留与整车节点对齐的阶段性治理（检查点、供应商交付里程碑），同时让软件侧以固定节奏的迭代列车推进，并通过发布跟踪把两侧的进度对齐。^{5454Hoe de joint venture van een wereldwijde autofabrikant meer dan 500 R&D-gebruikers over In-Car- en Out-Car-systemen verenigdeones.com前往参考资料 ↓在新标签页中打开}

软件定义汽车使功能、传感器、控制逻辑或更新策略中的任何一处调整，都可能波及系统需求、嵌入式软件、电子电气架构、安全分析、网络安全考量、测试方案与供应商交付物；当这些关联散落在孤立工具或静态文档中时，团队在最需要全局视野的节点反而失去可见性。^{5555借助互联需求与实时可追溯性管理软件定义汽车的复杂挑战cn.jamasoftware.com前往参考资料 ↓在新标签页中打开}

在安全关键场景下，敏捷迭代需要与可追溯性结合：把高频的软件迭代工作挂接到上层需求、风险管控、设计评审与验证证据上，团队才能在快速响应变化的同时，明确变更内容、变更原因以及需要重新验证的范围。^{5555借助互联需求与实时可追溯性管理软件定义汽车的复杂挑战cn.jamasoftware.com前往参考资料 ↓在新标签页中打开}

实时可追溯性带来的全局可见性有助于减少后期返工、降低缺陷风险，并使复杂项目在硬件与软件并行推进时保持一致；反之，缺乏贯通的需求—软硬件—测试链路会在审计前难以识别合规缺口。^{5555借助互联需求与实时可追溯性管理软件定义汽车的复杂挑战cn.jamasoftware.com前往参考资料 ↓在新标签页中打开}

汽车产品正日益成为“带轮子的软件平台”，自适应巡航、车道保持、信息娱乐生态等功能在车辆全生命周期内通过更新持续演进，传统的五年开发周期难以跟上这一节奏，因此敏捷在汽车领域从可选项变为生存必需。^{5656Agile Project Management for Automotive: 7 Pitfallsones.com前往参考资料 ↓在新标签页中打开}

在汽车项目中直接套用通用敏捷实践会遇到结构性摩擦：一次硬件变更就可能打乱两周的冲刺，功能安全审核方要求 Scrum 看板无法提供的追溯证据，供应商又按完全不同的节奏运作。^{5656Agile Project Management for Automotive: 7 Pitfallsones.com前往参考资料 ↓在新标签页中打开}

硬件长周期与软件迭代的协调，实质上是把“变更影响分析”制度化的过程：任何软件侧迭代产生的变更，都需要回溯到受影响的硬件假设、系统需求与验证证据，从而决定哪些内容可以随迭代发布、哪些必须等待硬件节点。^{5555借助互联需求与实时可追溯性管理软件定义汽车的复杂挑战cn.jamasoftware.com前往参考资料 ↓在新标签页中打开|5656Agile Project Management for Automotive: 7 Pitfallsones.com前往参考资料 ↓在新标签页中打开}

智能座舱与车载软件领域普遍采用分层、分域的混合开发模式：上层应用、HMI 与算法模块采用短周期迭代的敏捷方式，而底层平台、安全相关与量产认证环节仍沿用瀑布式或阶段门流程，形成「前端敏捷、后端瀑布」的结构。^{5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

功能安全标准 ISO 26262 对 ASIL 等级提出严格的流程、文档与追溯性要求，任何代码修改都需进行安全影响分析与回归测试，这与敏捷所倡导的「轻量文档」理念存在直接张力，是座舱软件不能完全敏捷化的首要硬约束。^{5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

在汽车敏捷实践中，功能安全审计方要求的需求—设计—代码—测试双向追溯链，往往无法由 Scrum 看板或通用敏捷工具直接提供，追溯性缺口是团队导入敏捷后最先暴露的合规问题之一。^{5656Agile Project Management for Automotive: 7 Pitfallsones.com前往参考资料 ↓在新标签页中打开}

硬件依赖构成敏捷节奏与安全验证节奏之间的时间错配：ECU、传感器与芯片的开发周期长、成本高，无法为每个两周冲刺提供新硬件，而硬件在环测试环境搭建复杂，难以像纯软件那样按迭代频繁部署。^{5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

车规软件在量产前须完成极端环境测试、耐久测试与认证，这些测试周期可能长达数月，无法嵌入单个短冲刺，因此合规验证通常被安排在迭代之外、以独立的验证阶段或发布门禁形式存在。^{5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

针对软件定义汽车，学界提出了将快速迭代与 ISO 26262 对齐的定制化敏捷框架，例如 RoHo-ASI 框架，其通过 HO-Agile 与 ASI 模型、角色导向协作、硬件在环测试与动态冲刺周期，来弥合软硬件耦合与安全合规之间的时间错配。^{5858Re-imagining Automotive Software Development: RoHo-ASI Framework for SDVieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在跨公司供应链中，不同软件模块由不同供应商提供，需要严格的接口定义与合同约束，敏捷所倡导的「随时响应需求变化」在跨组织协作中难以落地，因此需求变更通常需经变更控制与安全影响评估后才能进入迭代。^{5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

实践中常见的融合做法是把安全生命周期活动（危害分析与风险评估、安全需求分解、安全案例编制）作为贯穿各迭代的并行轨道，而把每个冲刺的产出物映射到安全需求条目上，使迭代增量同时成为安全论证的证据单元。^{5858Re-imagining Automotive Software Development: RoHo-ASI Framework for SDVieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|5757座舱软件开发之敏捷开发与瀑布开发-CSDN博客blog.csdn.net前往参考资料 ↓在新标签页中打开}

在汽车行业，硬件与软件开发长期处于彼此分离的状态：硬件团队遵循与整车生产绑定的刚性瀑布流程，而软件团队则追求敏捷的速度；智能座舱方案商的做法是把两种方法论放到同一平台上，而不是二选一。^{5959How a Global Automaker's Joint Venture Unified 500+ R&D Users Across In-Car and Out-Car Systemsones.com前往参考资料 ↓在新标签页中打开|6060Come la joint venture di una casa automobilistica globale ha unificato oltre 500 utenti R&D tra sistemi In-Car e Out-Carones.com前往参考资料 ↓在新标签页中打开}

在智能座舱与嵌入式软件的语境下，敏捷与设计的协作并非以敏捷取代瀑布，而是按工作性质分层：新车型与固件相关项目仍需要瀑布式的严谨、检查点治理以及与 SOP（量产启动）时间线对齐的供应商协同，而软件侧则保留敏捷的迭代节奏。^{5959How a Global Automaker's Joint Venture Unified 500+ R&D Users Across In-Car and Out-Car Systemsones.com前往参考资料 ↓在新标签页中打开|6060Come la joint venture di una casa automobilistica globale ha unificato oltre 500 utenti R&D tra sistemi In-Car e Out-Carones.com前往参考资料 ↓在新标签页中打开}

有研究把源自规模化敏捷框架（SAFe）的 Scrum 方法加以裁剪，专门适配汽车嵌入式软件（EAS）的开发，并在裁剪过程中分析汽车嵌入式软件的开发环境、独特挑战以及相关的国际与安全标准。^{6161Architecture and development of embedded software in the automotive environmentvskp.vse.cz前往参考资料 ↓在新标签页中打开}

在嵌入式与智能座舱项目中，设计与敏捷协作的落点通常是共享的规划与交付平台：把规划、内部交付与供应商执行连接起来，使 OEM、内部团队与供应商在同一层协作，从而在瀑布治理与敏捷迭代之间建立可追溯的衔接。^{5959How a Global Automaker's Joint Venture Unified 500+ R&D Users Across In-Car and Out-Car Systemsones.com前往参考资料 ↓在新标签页中打开|6060Come la joint venture di una casa automobilistica globale ha unificato oltre 500 utenti R&D tra sistemi In-Car e Out-Carones.com前往参考资料 ↓在新标签页中打开}

「敏捷」名义下的形式主义，指团队保留了敏捷的外在仪式与术语（站会、迭代、看板、燃尽图、用户故事），却没有落实敏捷宣言所强调的价值观与工程实践，结果是流程形式压过了交付价值本身。^{6262敏捷，是灵丹妙药还是又一个忽悠？learn.microsoft.com前往参考资料 ↓在新标签页中打开|6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

一种常见的形式主义表现是把「响应变化」单独抽出来当作敏捷的全部，忽略敏捷宣言中排在它之前的「工作的软件」这一项，于是需求可以随时改、每个迭代都在赶工，交付物却不是可用的完整功能。^{6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

把流程置于人之上是形式主义的典型症状：例如要求开发人员每天填写格式统一的站会日报，原本十几分钟能说清的事要花半小时写文档，这与「个体和互动高于流程和工具」的价值观直接相悖。^{6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

形式主义式「敏捷」的常见成因是自上而下的推行方式：管理者听说同行用敏捷取得成效后，直接下令全公司改流程、砍掉需求评审、规定两周必须发版，把敏捷当成一套可以照搬的流程模板，而不是需要长期实践积累的能力。^{6262敏捷，是灵丹妙药还是又一个忽悠？learn.microsoft.com前往参考资料 ↓在新标签页中打开|6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

这种推行方式往往导致旧问题未解决、新问题又出现，团队与管理者由此得出「敏捷不管用」的结论，进而回退到原有做法，形成「引入—失望—放弃」的循环。^{6262敏捷，是灵丹妙药还是又一个忽悠？learn.microsoft.com前往参考资料 ↓在新标签页中打开|6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

有观察者用「先引进概念、再补实践」来解释形式主义的根源：国外通常是先有多年实践积累再为做法命名，而国内往往先引入概念，再依据概念反向设计具体做法，这些做法听起来符合概念，落到项目中却失效。^{6262敏捷，是灵丹妙药还是又一个忽悠？learn.microsoft.com前往参考资料 ↓在新标签页中打开}

形式主义敏捷的一个可观察后果是质量指标恶化：迭代节奏被压缩为「每个 Sprint 都在赶需求」，上线缺陷数量超过需求文档的厚度，功能逻辑不完整即被发布。^{6363敏捷开发方法：别把“迭代”做成了“反复横跳” - 产学研jscxyp.cn前往参考资料 ↓在新标签页中打开}

敏捷宣言在价值排序上把「可工作的软件」置于「详尽的文档」之前，但宣言原文同时明确「也就是说，尽管右项有其价值，我们更重视左项的价值」；因此宣言本身并未主张取消文档，而是主张在文档与可运行软件冲突时优先保证后者。^{11Manifesto for Agile Software Developmentagilemanifesto.org前往参考资料 ↓在新标签页中打开}

敏捷宣言的十二条原则中，只有一条直接涉及文档与设计——「最好的架构、需求和设计出自自组织的团队」，且该条并未规定架构工作应在何时、以何种形式完成，这为实践中把架构与文档工作无限期推迟留下了诠释空间。^{11Manifesto for Agile Software Developmentagilemanifesto.org前往参考资料 ↓在新标签页中打开}

Scrum 指南（2020 版）把 Scrum 定义为「轻量级框架」，并明确其「有意不完整，只规定足以实施 Scrum 理论所必需的部分」，即框架本身不规定文档、架构描述或技术设计工件，这些须由团队自行补充。^{2727The Scrum Guide (2020)scrumguides.org前往参考资料 ↓在新标签页中打开}

在受监管或安全关键领域，敏捷实践中的「可工作的软件优于详尽文档」常被误读为免除文档义务，而实际上 IEC 62304 等医疗器械软件生命周期标准仍要求可追溯的需求、架构设计与验证记录，二者需要显式调和而非二选一。^{6464IEC 62304:2006+AMD1:2015 Medical device software – Software life cycle processeswebstore.iec.ch前往参考资料 ↓在新标签页中打开}

CMMI 与敏捷的对比研究指出，二者在过程文档化上的表面冲突多源于对 CMMI 的过度解读：CMMI 要求的是「过程被定义与记录」，并不强制特定的文档形式或数量，因此组织可以在保留必要记录的同时采用迭代式开发。^{6666CMMI or Agile: Why Not Embrace Both!resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

在大型或长期演进的系统中，架构知识的流失是敏捷团队常见的隐性债务：当架构决策只存在于成员头脑与口头沟通中，人员流动会造成关键设计理由不可恢复，这类「架构知识蒸发」在缺乏架构决策记录机制时尤为突出。^{6767Documenting Architecture Decisionscognitect.com前往参考资料 ↓在新标签页中打开}

架构决策记录（ADR）作为一种轻量文档实践被提出，用以在敏捷节奏下以短小、版本化的记录捕获每项重要架构决策的背景、选项与后果，从而在不引入重量级文档流程的前提下保留设计理由。^{6767Documenting Architecture Decisionscognitect.com前往参考资料 ↓在新标签页中打开}

对敏捷方法的系统性文献综述发现，多数实证研究报告的是生产率、质量与满意度方面的结果，而关于文档充分性、架构可持续性等长期可维护性指标的实证证据相对稀少，这意味着「文档被忽视」的后果在学术上仍缺乏充分的量化刻画。^{6868Agile software development: a systematic review of empirical studiesdl.acm.org前往参考资料 ↓在新标签页中打开}

规模化敏捷框架（如 SAFe）在引入跨团队协调的同时，显式增加了架构跑道（architectural runway）与系统架构师角色等机制，这本身即是对「纯团队级敏捷容易忽视架构」这一批评的制度化回应。^{6969SAFe 6.0 Frameworkscaledagileframework.com前往参考资料 ↓在新标签页中打开}

在嵌入式与安全相关软件开发中，敏捷团队常面临「迭代交付」与「阶段性评审证据」之间的张力：认证机构通常要求在设计冻结点提交成套文档，而迭代开发倾向于持续变更，二者需要在项目层面预先约定证据生成节奏。^{6464IEC 62304:2006+AMD1:2015 Medical device software – Software life cycle processeswebstore.iec.ch前往参考资料 ↓在新标签页中打开}

在敏捷方法普及初期，一种常见观点认为分布式开发是应当避免使用敏捷技术的典型情形之一。2007 年 InfoQ 中文站转述《CIO》杂志文章时，把「需要进行分布式开发的应用」列为 IT 经理应考虑回避敏捷的四种情况之一。^{7070面向 IT 经理的敏捷入门infoq.cn前往参考资料 ↓在新标签页中打开}

针对「敏捷不适合分布式项目」的说法，敏捷实践者 Joshua Kerievsky 在 2007 年公开反驳，认为这类论断在 2001 年尚可成立，到 2007 年已属偏颇；他称「XP/敏捷对超过 20 人的团队或分布式项目水土不服」的说法早已被证伪。^{7070面向 IT 经理的敏捷入门infoq.cn前往参考资料 ↓在新标签页中打开}

Kerievsky 以自身公司 Industry Logic 为例，说明其开发工作「百分之百使用分布式 XP」且结果令人满意，具体做法包括用 ProjectCards 举行分布式计划会议、用 Skype 进行语音与视频会议、用 VNC 进行远程协作。这构成分布式团队可以实施敏捷的早期一手实践证据。^{7070面向 IT 经理的敏捷入门infoq.cn前往参考资料 ↓在新标签页中打开}

「敏捷不适合分布式团队」这一误区在中文技术社区长期流传，其来源可追溯到 2000 年代中期面向 IT 管理者的入门性文章，而非敏捷宣言或任一主流框架的原始文本；敏捷宣言与 Scrum、XP 等框架本身并未对团队的地理分布作出限制性规定。^{7070面向 IT 经理的敏捷入门infoq.cn前往参考资料 ↓在新标签页中打开}

分布式敏捷的可行性高度依赖协作工具与刻意设计的沟通机制。上述案例中，分布式计划会议、语音视频会议与远程桌面共享被明确列为支撑分布式 XP 运转的关键手段，说明「适用性」问题更多是实践条件问题而非方法论内在缺陷。^{7070面向 IT 经理的敏捷入门infoq.cn前往参考资料 ↓在新标签页中打开}