敏捷开发方法和结构化开发方法是否可以共存

编辑概论
敏捷开发和结构化开发：可以共存？
Pekka Abrahamsson Unisiverty of Helsinki
Muhammad Ali Babar IT Unisiverty of Copenhagen
Philippe Kruchten University of British Columbia
敏捷开发在很大程度上影响了工业软件开发的做法。但是，尽管敏捷开发的广泛流行，对软件架构师在敏捷开发中充当的角色和重要性越来越使人感到困惑。对于庞大而复杂系统，提倡架构在达到高质量软件目标的人们怀疑任何其他不太注重结构化开发方法的可扩展性。这尤其适合于汽车、电信、财政和医疗设备领域。那些习惯于结构化开发的公司认为敏捷开发是业余的，未经证实的和对于小型基于web的社会技术系统是有限制的。
反过来，敏捷开发的支持者通常认为系统的前期设计和架构评估对系统用户的价值不大。他们感觉软件架构是过去时了，和BDUF（Big design up-front 导致繁琐的文档和一些完全没有必要实现的特征）没有什么区别。他们相信结构化设计的价值不大，一个在大多数情况下都满足的比喻，一个架构应该作为成功的小重构一步一步渐渐出现。
区分关于敏捷开发和结构化开发方法共存的必要性、重要性、有利条件和不利条件的事实和神话的兴趣逐渐增长，这就是这个问题的主题。
任何讨论、争论或者评估结合敏捷开发和结构化开发方法的努力都应该以这样的一些问题开始：这些观点是矛盾的、相对的或者是互补的？区分敏捷开发和结构化开发是否有一些意义？什么样的步骤将会使项目组从不关心没必要的价值和要求中获益呢？
悖论、矛盾、完全相反？
Jim Highsmith将敏捷开发定义为一个组织创造和为了从混乱的业务环境中获取利益而做出对变化的反应的一种能力。Sanjiv Augustine认为敏捷开发方法，如极限编程（XP）、Scrum、特征驱动开发、lean、Crystal等等有一些共同的特征，如下：
增量迭代的生命周期
关注于小的发布
并行的团队
一个基于发布计划的计划策略，该发布计划以一个特征或者是产品背景
一个处理任务的迭代计划
他们或多或少的依赖于Agile Manifesto的价值。
统一软件开发过程（RUP）将软件架构定义为软件系统组织所做出的有意义的决定的集合、以及组成该系统的结构元素和接口和相互协作元素之间的行为，这些结构元素组成的模块在日益增长的子系统之间的行为，这个组织、这些结构元素、接口、它们之间的合作、它们组成的小模块等的架构风格。软件架构不只是关注架构和行为，还关注软件的可用性、功能性、性能、弹性、重复使用性、易理解性以及经济性和技术限制、综合权衡和美学方面。
拉力似乎位于改造和预料的轴心上。敏捷方法想坚决的适应：在最后时刻或者是变化发生时作出决定。敏捷方法认为软件架构花费太大的努力在前期预料阶段：在前期阶段计划太多。或许我们可以找到一个在这两个极端方法和思维方式中间的平衡点。
错误的区分？
当讨论这个特别问题的方向时，Craig Larman声称敏捷开发和结构化之间的紧张情况是一个错误的分歧。实际上，有很多像这样的认为的区分。一些被忽视了，一些事有意的，为了支持一个特定的信息：敏捷开发vs瀑布开发或者敏捷开发vs原则开发。像其他许多在实验室或者是实际应用中的软件开发一样，一个好的集中于架构的软件开发方法不与任何敏捷开发方法相对立。各种敏捷开发方法的支持者都同意这个观点。按照如此方法，Satoshi Basaki指出，开上去很多敏捷开发方法的用户都误解了敏捷开发方法的实际含义，不顾架构，把一味的重构作为唯一的灵丹妙药。
我们还有来自于第一次迭代的“向利益相关者分发金钱的权利”。但是如果开发这是这个利益相关的人，而不是最终的用户呢？Alistair Cockburn开发了开始行走的骨架的策略，然后进一步的完善它。Mary 和 Tom Poppendieck提出可拆分系统架构的见解。最后，Kent Beck的建议是架构在极限编程中的重要性和在其他任何软件架构中的重要性是一样的。架构的一部分被系统隐喻（一个极限编程的实践方式）所占据。我们必须开始解决什么问题呢？
发现问题的所在？
可以从多个级别理解敏捷开发和结构化开发的表面上的冲突：语义、范围、生命周期、角色、文档、方法和价值。
阐明语义
一个项目架构的详细说明意味着什么呢？这个概念的边界模糊。特别的，不是所有的设计都是架构。达成一个一致定义是一个有用的实践和一个好的起始点。