老师推荐了Martin Fowler前辈博客中的一篇关于敏捷开发的文章，文章很长，在Chrome词典插件的帮助下总算囫囵吐枣，大致了解了一些关于Agile Software Development的知识，再结合课本上的介绍，还算了解了敏捷开发吧，下面谈谈我自己所学习到的一些东西。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
一、关于技术创新：
技术的创新总是在人们已经认识到旧技术的缺点，而且反思总结出了一些经验教训之后，由某个人或者某些人提出的，绝不会是偶然产生。就如敏捷开发，90年代研究软件开发的人们已经认识到传统的任务驱动型开发方式存在诸多毛病，尤其在开发大项目时，也已经有人开始尝试新的开发方式，但在总结了各类开发方法学的共通点和差异点之后，Twelve Principles of Agile Software提出了Manifesto for Agile Software Development，于是乎，才有了越来越热门的敏捷开发技术，甚至她不算是一种技术，而是“一种哲学理念和一系列开发指南的综合”。
技术更迭往往如此，随着时代的发展，项目在变，需求在变，人们也在变，而技术也必须改变，并且往往需要通过总结已有的经验思考差异和共通来实现真正的改进。
二、关于敏捷开发本身：
Martin在文章最初就表达了他认为的敏捷开发和传统方式最深层的不同：Agile methods are adaptive rather than predictive；Agile methods are people-oriented rather than process-oriented. 我认为这也是实际开发过程中最根本的要求，按照我们的话说就是“实事求是，一切从实际出发”。第一条，实际开发过程中，需求往往变化，即使不是大变动也会反复细微调节，（文章中举了很多幽默而浅显的案例来反映现实开发过程中的一些问题），要预测需求总是困难的，利用迭代开发过程，开发加反馈模式可以控制不可预知性，但是按照敏捷开发模式，软件工程师和其他项目利益相关者共同组成一个敏捷开发团队，持续良好的互相交流合作，这样可以很大程度上化解这个问题，需求和预算都在计划范围之内，开发的适应性也就出来了。第二条，以人为本，团队里的个人以及团队内部的交流合作才是首要，虽然我不太明白“The goal of engineering methods is to define a process that will work wellwhoever happens to be using it”，保证团队内每一个人面对工作总是轻松的而且良好的更像是一种理想，但不得不说，能保证每个人的意义高于任务的意义的确让人称道。把团队中的人当作个体，而非可以更换的兼容部件！这将极大刺激鼓舞每一位团队成员，同时管理人员和开发人员见建立起两良好的合作依赖关系使得整个流程更为顺利自然，同时保证每一个成员的专业能力，有一个明确而正确的方向，那么一切都将极其自然，同时，自适应过程也将保证每个成员找到最适合的位置。
只有经历过很多次实际开发，见证过许多失败的开发过程，反思总结过够多的开发实践，才能找出最为根本的问题，并且寻找到最合适的解决方案。
三、我适合敏捷开发吗？
文章中也提到目前，“code and fix”的开发方法仍使用广泛，也许并没有必要进行敏捷开发，但尝试敏捷开发总是必要的。前辈给出的建议很诚恳也很明确，敏捷开发在过去的十几年里发展迅速，为人们所接受，我想我也是乐意学习的，找一个老师（算已经有了吧~），还有一个团队，我们的目标也显得清晰，相信在不断地总结和自适应过程中，我能学到很多东西。
