在阅读老师所推荐的文章之前，我先百度了一下有关敏捷开发的基本资料，对敏捷开发有了一个宏观的粗浅的认知。“简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。”
从百科的这段文字描述中我们可以发现，敏捷开发从根本上讲是一种软件开发方法，而且这种软件开发方法具有其他方法无法比拟的优势。有了宏观概念后，便开始着手阅读那篇又长又看不大懂的博客了，下面做一些笔记，用我的方式记录些学到的东西，也算做是一种feeling吧。
1.兴起由来：
起初，软件开发过程是一种很混乱的活动，即典型的“code and fix”，即边写边改。都是即兴的决定，没有完整规划。这就会有严重的隐患，当工程越来越大越来越复杂的时候，难以添加新的功能，bugs越来越多且难以排除。这就需要软件开发团队以漫长的时间为代价来换取软件的可靠性，而且还不一定利于维护。
这时，工程方法进入人们视线。工程方法要求十分严格，就好像把写软件模式化流程化了一样，对它进行细致的规定。这样虽然对软件有了预见性，一定程度上提高了效率，但是过程繁琐，coder们生性渴望自由，这种束缚难以让工程方法取得大的成功。
严格的环境下必定会产生叛逆。这时我们的主角便登场了——敏捷开发。它们在无过程和过于繁琐的过程中达到了一种平衡，既纠正了以往的官僚繁琐过程，又不是“无政府无组织”的放任创作，使得能以不多的步骤过程获取较满意的结果。敏捷开发，以其适应性性质和以人优先的理念迅速引起行业极大兴趣。
2.优势特点：
2.1适应性
说到适应性就不得不把它和预见性相比，这里又要提到工程方法。我们说的工程一般可以指土木工程、电气工程等等。这些工程都有一个共同的特点，就是可预见性。比如说我们要建造一座大厦，工程师们会做出一些设计，然后绘制各种图纸交给建造团队，然后高楼便在一切计划好的流程中建起。这建高楼的工程就是可预见的，事先做好规划然后严格执行就可以了。然而软件工程却不是这个样子的，因为“创作”不等于“制作”，“设计”不同于“建造”。软件是“软”的，需求是可变的不仅可预见的，这就需要我们的设计方法能够灵活多变，具有适应性，接受变化。而敏捷开发便具有这样的性质。
2.2把人放到第一位
刚读到这里时，我对此感到十分诧异，不明觉厉。也许没有走出过校门，没有参加过公司的软件开发，原来在曾经的的开发过程中，开发人员竟是相当于可替换的部件这样一个存在。完全把人当成机器，而非有血有肉有思想的一员。也许大家都是这样认为的，不过具体操作中还却不是这样做的。敏捷型开发则非常强调以人为本。并非管理人员决定开发过程，而是由实际开发的人员共同拟定的，是让大家接受一个过程，而不是强加一个过程。
3.个人的一些想法
粗略读了一些文章后我个人感觉，敏捷开发之所以敏捷，原因就是统一优秀的团队。团队中包括各种开发中的角色，大家在一起面对面的交流，误解能在第一时间得到更正，团队成员间多交流（并不限于工作上），多组织些活动，让团队成员间关系更和谐温馨，增加默契。
在保证了人员关系的基础上我们再来谈技术性的问题我觉得才是ok的。文章中多次提到迭代化开发，我觉得是一个很不错的方法。将开发时间分成一个一个固定时间长度的小阶段，每个迭代完成相应的用户故事，新的需求与改动按照优先级情况排在下一个迭代以后。每个迭代之初，进行迭代计划，按照需求的优先级，由小组成员自己领取适合自己规模的工作。然后，进行用户需求划分搞清任务。每个迭代完成的时候，会有一个迭代回顾会议，总结完成的故事点数，演示这个迭代的成果，听取组内成员的意见，以持续改进，增进默契。这样可以让可执行的部分软件第一时间问世，“可以工作的软件胜过面面俱到的文档”，我们可以一层一层排除问题，然后进入下一阶段，这样提高了不少效率。
最后，我想说的就是我们team会在接下来的team project中按照敏捷开发的要点进行实践来实际体会敏捷开发的优势！