对敏捷的一点思考 ---- 敏捷是强调结果的

现在软件工程项目管理流行使用“敏捷”。经历了一些敏捷项目，有了些感想。
现在的项目组强制执行结对编程。我喜欢敏捷因为敏捷是山寨版的CMMI。而山寨代表着先进生产力、代表着具体问题具体分析的思想与实践。

先看看Agile 宣言与原则。你就发现敏捷其实是强调结果的。它用结果督促、指导项目的进行。
但是我觉得敏捷开发忽略了对总体架构或者系统设计的要求与指导。

在最近的几个项目中，都号称用敏捷的模式进行项目管理：每天早上的15分钟会议、结对编程、与用户的直接沟通。但这些手段都不能很好的解决在软件框架的设计问题。因为大多数程序员的经验与水平还不能够为项目建立框架（spring, struts这些现有框架确实解决了很多问题。但是一但项目需要定制自己的框架时，问题就凸显出来。）
如何根据具体的项目特点搭建适合自己业务需求的框架能够敏捷出来么？我个人觉得是不大可能的。因为这要求开发人员在对业务、技术比较了解的情况下进行更深一个层次的抽象。如何抽象？哪些可以抽象？抽象后如何向外提供服务（提供调用接口或IoC）？都是需要有比较专业的思考，同时很多也是经验。
想说的是，敏捷并不能替代全部的传统的软件工程流程，尤其是系统设计这一块。
敏捷是方法论，并不是保证。就如，设计也需要敏捷一样。

虽然我自己对敏捷有了以上负面的感觉，但我依旧喜欢敏捷，因为它思想包括：个体和交互、客户合作。