软件测试中让敏捷方法和企业架构和谐共舞
一份来自Cutter Consortium的报告向我们提出了这样一个问题：“敏捷方法和企业架构兼容吗?”并且也给出了这样一个答案：“是的，但需要付出努力”。该报告的作者推荐运用特殊技巧以允许敏捷方法和企业架构互相受益。此外，他们的观察结果、分析和建议也直接是适用于敏捷方法和“面向服务的架构SOA”之间的结合。
企业架构(EA)和敏捷方法(AM)拥有共同的目标——交付能够跟业务需要对齐的软件，并响应对这些业务需要无可避免的变更。然而，EA和AM在达成这个目标时却采用了截然不同的方式。在报告中，对EA和AM定义如下：
EA处理如下的企业级问题：
通过提供一个整体的业务过程蓝图将业务策略连接到IT系统，蓝图可以映射到架构模式、核心服务和应用兼容性等方面。
通过维护一个当前的数据模式(schemas)、过程流和服务定义等内容的详细目录来改进贯穿于整个企业的一致性
通过减少系统间的冗余以及标识可以统一的组件和系统来改进操作效率
确保灵活的IT能力，能够响应技术厂商以及新的或者增强性的业务流程自动化的变化
通过维护IT 组合(portfolio)、当前和目标架构以及迁移路线图来支持项目成本化和优先级划分
为正在进行中的操作和系统开发提供一个稳定的、可信赖的基础设施平台和公用服务
敏捷方法关注于以下观念：
改进效率：关注于近期的问题，仅开发能够满足当前需要的的部分，允许以后形成设计
改进项目可见的可管理性：关注于允许任务的完成能被有效评估的短期的、迭代的开发周期
通过提供一个完整的过程，关注于广泛的自动化测试、尽可能早并且经常解决集成问题、允许多个(缺少丰富经验的)开发人员在共同的代码上开展工作以及从最终用户处得到持续反馈等方式来改进质量。
通过建立在持续重构过程上的集成来改进(内部质量的)可维护性
改进处理变更的能力：它是一个需求变更、一个澄清、一个新的需要优先处理的特性?通过综合客户反馈计划迭代内容。
通过隐式知识的使用、共享的团队空间以及关注问题的小的组成部分来改进交流效果。
我们会先从EA的视角来检验AM然后反过来检验以分析EA和AM之间的鸿沟。从EA的视角来看：
敏捷迭代提出的使用一到六个周的时间盒来构建一个可运行的部分系统的要求，很少得到采纳。当在一个迭代发生时尝试EA时，常常会割裂时间盒——在这个周期结束时并没有得到可工作的软件。
在一个典型的敏捷项目中，当系统的设计激增时，采用演进的设计、有机的增量的方式风险很大，可能会导致冗余和不同应用间的不兼容性。EA组希望引领设计和推荐的公用基础设施组件、数据库模式定义等……
敏捷非常依赖于可执行的的工件，例如：编写好的测试(不管是单元测试还是系统测试)。EA的工件不是可以测试的。它们限制了项目的影响范围，因为他们没有反馈环——当没有遵照设计时，不会给出警告。
敏捷提倡的客户作为团队成员是不能被承认的。EA组中不会存在任何一个客户，但是它有一个从IT到运营到开发团队到最终用户的间接的大型的广泛客户群。
从AM的视角看，EA也不是非常有意义的：
EA关注于对齐IT系统和业务策略。一个映射了从现在到将来系统的计划被开发出来，然后落到一个独立的项目中。使用了AM的团队可能会使用此类文档中的信息，但当这些文档到达团队时它们已经失去了上下文环境，会变得难以理解。而且，文档是可测试的。不能接触现实状况，这也是EA团队被视作“象牙塔”架构的一个主要原因。
为了减少冗余并增进一致性，EA组会针对如何构建应用而产出参考架构、推荐框架、发布指南。AM团队将这些决定看做是单个项目的领域，不会由未在”前线“上的人来口述。
EA也关注于企业内不同应用的集成。同样，EA组推荐使用参考架构和框架的特定方案。许多的AM团队任务这些决定的是不成熟的甚至是毫无根据的。
文章来源于领测软件测试网 https://www.ltesting.net/
