第一个看到敏捷开发这个词，是前一阵子在看一本叫《精益创业》的书时。
这本书核心思想是建议创业者应遵循敏捷开发思想，有创业想法时，应该先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，灵活调整方向。在此期间，团队也应该紧密联系充分沟通。如果产品不符合市场需求，最好能“快速地失败、廉价地失败”，而不要“昂贵地失败”；如果产品被用户认可也应该不断学习，挖掘用户需求，迭代优化产品。
在读那本书时，便惊异于敏捷开发思想的巧妙。这周又有幸读到敏捷开发创始人之一Martin Fowler关于敏捷开发的文章（http://martinfowler.com/agile.html），让我对其有了更深的理解。于此文中做一些总结、摘录和感想。
1、敏捷开发的核心思想
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
Martin Fowler认为敏捷开发的核心是：adaptive rather than predictive & people-oriented rather than process-oriented。
翻译成中文大意就是迭代更新比预测更重要，以人为本。
由于用户需求的不可预测性，与其程序勉强预测用户需求的变化方法，不如采用迭代开发的方式。
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。通过这种方式，开发者能够降低风险，得到早期用户反馈，从而进行持续的测试和集成，使用变更，也提高了代码的复用性。
以人为本里的人，是指程序员们。
2、Extreme Programming（XP/极限编程)
Martin Fowler在《Is Design Dead?》一文中详细地对极限编程做了一些说明。
对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。"Do The Simplest Thing that Could Possibly Work."、"You Aren't Going to Need It".
极限编程挑战很多软件开发常见的假设，比如说自顶而下设计，而支持一种比较属于演进的方式。有人批评XP，觉得这是退回到了 "code and fix" 的开发方式。支持者也常看到 XP 对于UML、principle、patterns 等的排斥，作者在文中对此作出一些解释。我做如下一些归纳。
1、极限编程最核心的地方就在于简洁，不设计明天才需要的功能，把效益发挥到最大。
简洁的标准是：通过所有测试；呈现所有的意图；避免重复；最少数量的类别或方法。
2、极限编程虽然也是支持比较演进的方式，但是不同于code and fix。（这部分专业术语有点多没有读懂）
3，作者对于对于采用 XP 的人使用 patterns 的建议：花点时间学习 patterns。留意使用 patterns 的时机 (但是别太早)。留意如何先以最简单的方式使用 patterns，然后再慢慢增加复杂度。如果用了一种 pattern 却觉得没有多大帮助－不用怕，再次把它去掉。
4，作者对于采用 XP 的人使用 patterns 的建议：花点时间学习 patterns；留意使用 patterns 的时机 (但是别太早)；留意如何先以最简单的方式使用 patterns，然后再慢慢增加复杂度；如果用了一种 pattern 却觉得没有多大帮助－不用怕，再次把它去掉。
5、极限编程看上去和UML矛盾，作者的看法是，UML是为了沟通而存在的，在使用XP方法的时候建议做的简短，不要太详细。
3、《Manifesto of Agile Software Development》——敏捷开发宣言
宣言比较短，大意：
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。