敏捷架构设计的团队设计与简单设计理念

敏捷软件架构的一般设计过程包括需求分析（分初始阶段需求分析——只抓最高层、优先级最高、风险最大的需求，与迭代阶段需求分析——随项目进展逐步完善）、初始设计（在利益相关者间就项目生命周期目标达成协议，做全局抽象层次的系统处理流程/组织结构/模块划分/功能分配）、以及迭代过程（包含迭代设计、重构、确定架构、客户交流四个环节循环推进——重构是对架构的持续改进，原因可能是编码障碍或需求突变，重构过程需要文档化；”确定架构”指经测试验证达到预期要求、随软件产品发布而确定下来的架构，呼应”Code is design”）。在这套过程之上，敏捷思想最主要体现为两种设计理念。团队设计的理论依据是群体决策——群体决策结论更完整，但需要额外沟通成本、决策效率较低、责任不明确；在架构设计中若组织得当，群体决策能发挥很大优势，最好的方式是让所有开发人员都参与架构设计（避免”象牙塔式”架构——理论完美但程序员无法实现），退而求其次可以组织优秀开发人员组成设计组，但设计组产出的只是”原始架构”，需要在实现过程中分布到各开发领域、通过编写代码检验架构获得具体反馈，再回到设计组讨论架构演进。简单设计要求表达方式的简单化（弱化详细架构描述文档，减少不必要工件以降低维护和沟通成本）和现实抽象的简单化（仅针对当前需求建模分析，不做”多余的”工作）——这与模式/可重用组件/框架技术”先大量投入再节省后续成本”的逻辑正好相反：敏捷开发不追求处理第一个需求时就设计出近乎完美的弹性架构，因为总有考虑不到的问题，过早的”完美架构”反而会在后续阻碍改进、拉高成本；简单架构能加快团队理解架构的速度、方便交流协作，还能提高软件稳定性——架构越简单，稳定性越好。