第三章：敏捷开发核心概念
好，咱们进入正题。这一章我打算聊聊敏捷开发的几个核心实践——Scrum、Kanban、极限编程，还有那个被无数人挂在嘴边的敏捷宣言。说实话，我在汽车电子这行干了十几年，见过太多团队把敏捷当成「每天站个会、两周发个版」的皮毛功夫。嗯，这其实挺可惜的。
我个人习惯把敏捷理解为一套「应对不确定性的生存法则」。尤其在咱们ASPICE的语境下，流程合规和快速响应之间，从来就不是非此即彼的关系。你想想看，一个项目如果需求天天变，你还死守着V模型从头到尾做完再验证，那风险有多大？
核心观点：敏捷不是无序，而是更高级的秩序。它用更短的反馈循环，来替代传统流程中「事后诸葛亮」式的检查。
3.1 敏捷宣言的底层逻辑
先说说敏捷宣言。2001年那17个老哥在雪鸟城写下的四句话，我反复读了很多遍。很多人只记住了「个体和互动高于流程和工具」，但忽略了后半句——「虽然右项也有价值」。说白了，这不是要你扔掉流程，而是让你别被流程绑架。
我在一个ADAS项目里遇到过这种情况：团队严格按照公司流程写了上百页的文档，结果客户一看，说需求已经变了三次了。你说这流程还有意义吗？所以敏捷宣言的底层逻辑，其实是「价值驱动」——你做的每一件事，都要能直接或间接地创造客户价值。
- 个体和互动：强调面对面的沟通效率远高于邮件和文档。我建议每天站会不超过15分钟，站着说，说完就干。
- 可工作的软件：在汽车电子里，就是可运行的代码、可测试的模型。别拿「还在写文档」当借口。
- 客户合作：合同谈判是死的，客户需求是活的。我见过最成功的项目，客户代表就坐在开发团队旁边。
- 响应变化：计划赶不上变化，这是常态。敏捷给了你一个优雅地拥抱变化的框架。
我的经验：在ASPICE评估中，很多审核员会问：「你们怎么处理需求变更？」如果你能拿出一个基于敏捷的变更管理流程（比如Scrum的Sprint Backlog调整机制），他们会很满意。因为这证明了你有「受控的灵活性」。
3.2 Scrum框架：不是银弹，但很实用
Scrum是目前用得最广的敏捷框架。它的核心就三个角色、五个事件、三个工件。听起来简单，但真正用好的人不多。
三个角色：
- 产品负责人（PO）：负责定义需求、排优先级。我见过最差的PO是「传话筒」，最好的PO是「懂技术、懂业务、懂客户」的三懂人才。
- Scrum Master：不是项目经理，是教练和服务者。我曾经在一个项目里兼任过Scrum Master，说实话，最难的不是教大家怎么开会，而是帮团队挡住外部的干扰。
- 开发团队：自组织、跨职能。3-9个人最佳。人多了沟通成本指数级上升。
五个事件：
- Sprint计划会：确定这个Sprint要做什么。我建议用「计划扑克」来估算工作量，避免一个人说了算。
- 每日站会：回答三个问题——昨天做了什么？今天打算做什么？有什么阻碍？别变成汇报会。
- Sprint评审会：演示可工作的增量。记住，是「演示」，不是「读PPT」。
- Sprint回顾会：这是最重要的会。我习惯用「开始/停止/继续」的格式，让团队自己找改进点。
- 待办事项梳理：持续进行，不是一次性的。
三个工件：
| 工件 | 说明 | 我的建议 |
|---|---|---|
| 产品待办列表 | 所有需求的优先级列表 | 用MoSCoW方法（Must/Should/Could/Won't）来排序 |
| Sprint待办列表 | 当前Sprint要完成的任务 | 粒度要细，最好不超过8小时 |
| 增量 | 每个Sprint结束时的可交付成果 | 在汽车电子里，可以是通过单元测试的代码模块 |
避坑指南：我曾经见过一个团队，把Sprint周期定成4周，结果每次评审会都变成「补作业大会」。后来改成2周，节奏感一下子就出来了。记住，Sprint周期越短，反馈越快，风险越小。
3.3 Kanban方法：可视化你的工作流
Kanban和Scrum最大的区别是什么？Scrum是「时间盒」驱动的，Kanban是「流量」驱动的。说白了，Kanban更适合那种需求源源不断、优先级经常变动的场景。
Kanban的核心原则就三条：
- 可视化工作流：用看板把「待办→进行中→完成」的状态展示出来。我习惯用物理白板加便签纸，比电子工具更直观。
- 限制在制品（WIP）：这是Kanban的灵魂。比如你规定「进行中」的任务不能超过3个，那团队就必须先完成一个，才能开始新的。这能有效避免「半途而废」的烂尾工程。
- 管理流动：关注任务的流转速度。如果某个环节经常堵塞，比如「代码评审」卡了两天，那就得想办法优化。
在ASPICE的语境下，Kanban特别适合用于「维护阶段」或「缺陷修复」场景。因为这类工作通常无法提前规划Sprint，但你又需要控制工作负载。
我的经验：在一个BMS项目中，我们用了Kanban来管理「软件问题报告」的处理流程。每个问题从「提交→分析→修复→验证→关闭」都清晰可见。审核员看到这个看板时，直接给了个「优秀」的评价。
3.4 极限编程实践：把质量内建到代码里
极限编程（XP）是敏捷家族里最「硬核」的一个。它强调通过一系列工程实践，来保证代码质量。我个人觉得，XP的很多做法，和ASPICE的「软件详细设计」和「单元测试」要求是高度契合的。
核心实践：
- 测试驱动开发（TDD）：先写测试，再写代码。红-绿-重构，循环往复。我刚开始觉得这很反直觉，但坚持了三个月后，发现代码的bug率下降了至少40%。
- 结对编程：两个人一台电脑，一个写代码，一个审查。听起来效率低，但实际上减少了后期返工的时间。我建议每周至少安排两次结对编程，尤其是处理复杂逻辑时。
- 持续集成（CI）：每天多次合并代码到主干，并自动运行测试。在汽车电子里，CI还能自动触发静态代码分析（比如MISRA规则检查）。
- 重构：在不改变外部行为的前提下，改善内部结构。我见过太多「屎山代码」，就是因为不敢重构。记住，重构不是重写，是「小步快跑」地优化。
关键点：XP的底层逻辑是「质量是设计出来的，不是测试出来的」。这和ASPICE的「软件详细设计」要求不谋而合。你想想看，如果每个模块都有单元测试覆盖，那集成测试的压力会小很多。
3.5 敏捷与ASPICE的融合思路
最后，我想聊聊怎么把敏捷和ASPICE结合起来。很多人觉得这两者是矛盾的——一个强调灵活性，一个强调文档化。但我在实际项目中发现，它们完全可以互补。
我的融合建议：
- 用Scrum管理迭代：每个Sprint对应一个ASPICE的「软件实现」阶段。Sprint结束时，产出通过单元测试的代码和对应的测试报告。
- 用Kanban管理缺陷：把缺陷修复流程可视化，确保每个缺陷都有明确的负责人和状态。
- 用XP保证质量：TDD和结对编程，能有效满足ASPICE对「软件单元测试」和「代码评审」的要求。
- 文档化要「刚刚好」：不是不写文档，而是写「有价值」的文档。比如，用用户故事代替冗长的需求规格说明，用测试用例代替测试计划。
避坑指南：我曾经见过一个团队，为了「敏捷」而完全抛弃了文档。结果在ASPICE评估时，审核员要求提供「软件架构设计文档」，他们拿不出来。最后花了三周时间补文档，得不偿失。记住，敏捷不是不要文档，是要「恰到好处」的文档。
好了，这一章的内容就到这里。下一章我会深入聊聊「如何在ASPICE的SWE.1到SWE.6流程中，具体应用敏捷实践」。到时候我会结合一个真实的ADAS项目案例，把每一步怎么做、怎么过评估，都掰开揉碎了讲给你听。