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

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

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

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

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

Manifesto for Agile Software Development
个体和交互 胜过 工具和过程
可以运行的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

敏捷原则
1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。
2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。
3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。
4. 在整个项目过程中，每一天开发人员都要和业务人员合作。
5. 由个体推动项目的建设，为个体提供所需的环境，支持和信任。
6. 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面的交谈。
7. 衡量进展的重要尺度是可运行的软件。
8. 敏捷过程提倡可持续的开发。
9. 发起人，开发者和用户应该步调一致。
10.不断地关注技术上优越的设计会提高敏捷性。
11.简洁是最重要的，简洁就是尽量减少工作量的艺术。
12.最佳的架构，需求和设计来自于自组织的团队。
13.团队要定期反省如何使工作更有效，然后相应地调整行为。