架构与敏捷开发的三重关系

架构与敏捷开发的关系可以从三个层面理解，且这三层关系是递进的。第一层：两者出发点一致，都是一个权衡的过程。软件架构设计要权衡利益相关者的各种需求、在众多方案中确定唯一设计；敏捷开发要在两个极端之间权衡——一端是零管理成本、全部投入产出但容易导致混沌低质量团队士气低落，另一端是评审/变更管理/缺陷跟踪等大量管理活动加入、提升有序性但拉高成本和降低效率创新力。第二层：敏捷开发早期曾质疑架构（认为架构意味着大量预先设计活动，与敏捷”拥抱变化”的思想相违，且预先设计投入的成本可能被后续重构浪费），但学术界与企业界的多项研究最终确认敏捷开发同样需要重视架构：Abrahamsson指出敏捷开发中架构设计不可或缺，架构文档化应安排在开发末期而非开始；Faber强调架构师和设计原则是保障软件高质量的关键要素；Madison结合Scrum迭代模型说明架构师与编码人员的交流合作是质量关键；72位IBM开发者的调查显示多数人认为架构与敏捷能够共同存在且互相促进。第三层：敏捷开发改变了架构的设计方式，而非取消架构设计——传统架构设计包含详细设计（如具体UML图），敏捷开发不适合这种方式，原因有二：业务需求和技术快速变化的环境下，前期花费30%甚至更多时间做详细架构设计，要么不符合市场需求，要么需求一变就要付出巨大改动成本；编码阶段本身也蕴含大量详细设计内容，与前期详细架构设计存在重复。因此敏捷思想把架构拆成种子架构设计（关注系统骨架轮廓，包括架构层次和重要模块/类的说明，不设计全部类和方法）和详细架构设计（转移到编码、重构、单元测试阶段完成）——这正是从”Design is code”到”Code is design”的思路反转。