软件架构与项目执行的关键要点
1. 架构态度
创建客户价值意味着实现能够满足最终用户需求的用例。虽然软件架构本身通常与最终用户无关，但它对大多数其他利益相关者（如设计师、开发人员和测试人员）极为重要。他们可以从理解架构方法中受益，从而编写符合既定准则且适配底层架构框架的代码和测试用例。架构与开发相互影响，新的实现可能引发架构变更，而架构变更通常需要对实现进行重大修改。
对于小型、交付物生命周期较短的项目，偶然形成的系统架构或许可以接受；但大型系统则需要经过深思熟虑的有意架构，以适应未来需求的发展。
架构如同其他规划与设计工作一样，需要文档记录。敏捷开发虽具有自发性，但不能成为工作草率的借口。规范的敏捷项目应产出高层架构概述、用例描述、合同文档和 API 规范。关键在于使架构及其文档尽可能精简和便捷，架构与设计工作是一个持续进行的任务。
良好架构的系统应易于描述，可按需扩展，并且由能独立实现的组件构建而成。在敏捷开发项目中，架构考量与其他规划活动类似，需遵循以下原则：
-保持简单：复杂系统应拆分为更小的子系统，以便不同团队能并行且独立工作。虽需有整体架构概念，如面向服务架构或软件栈分层，但每个组件都应有独立的架构和设计。目标是创建可更好理解、更易实现和更灵活管理的组件化软件或服务。组件间功能依赖越多，设计增强功能和协调实现工作就越困难，也需要更多规划来协调不同团队。软件架构应简单易懂、直接明了，代码也应如此。避免不必要的泛化，不满足客户需求和非源自客户要求的功能会增加开发、测试和维护成本，却无显著价值，这在精益软件开发中属于可避免的“浪费”。例如，可定制大量参数的软件虽能适应多种情况，但对客户而言设置复杂，维护