敏捷开发
敏捷开发的定义：
是一种以人为核心、迭代、循环渐进的开发方法。在敏捷开发中项目被切分为多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简而言之，就是把一个大项目切分成多个相互联系但可独立运行的子项目，并分别完成。在此过程软件一直处于可使用状态。
敏捷开发 5 大价值观
- 沟通: 团队内部的开发人员之间沟通。
- 简单: 就是指简单的建模，如画一两张图表来代替几十甚至几百行的代码。
- 反馈: 过度自信是编程的职业病，反馈则是其处方。
- 勇气: 当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构你的工作，修正你的方向。
- 谦逊: 这个就不用我解释了。
敏捷开发核心做法
- 测试驱动开发
- 结对编程: 指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或同一组测试。
- 持续集成:
- 每日站立会议
- 共同拥有代码
- 系统隐喻
除了敏捷开发模式，目前所具有的开发模式还有好几种,如：瀑布模型，快速原型模型，增量模型，螺旋模型，喷泉模型。 我在大学的实验室中使用 Rails 框架进行开发，使用的是敏捷开发模式。虽然如此，但是我们团队的敏捷开发还是带有其他模型的特征，可能因为我们还是学生团队，不是一个真正意义上的商业团队(我们平常还必须上课)。
我先通过我们团队负责的一个项目（在这里我们叫它为ce）来阐述，我们为什么不是真正的敏捷，而是有有快速原型和增量的特征的敏捷，或者说我们是采用混合模式。
ce 首先通过实现前台大部分界面（没有功能）的样品给客户观看并给予讲解。客户可以清楚的看到有具体形态而无功能的样品，从而有助于客户提出有针对性的修改意见。而参与调研的师兄们对样品进行再次修改，并再次呈现给客户看，直到双方达成共识为止；之后师兄们就对这些调研后的资料进行讨论并据此形成规格说明文档（我们的规格说明文档是前台界面的图片，并用文字等方式对其功能进行阐述，当然还有一些流程图），然后把之前做的不具有功能的样品抛弃。很明显这是结合了快速原型模型，从而得到它的优点：规格说明文档正确的描述客户的需求，减少了设计和编码阶段发生的可能性错误。
当进入开发阶段时，团队要求将这个 ce 项目分成三期；每期有几条流程，而各个阶段的流程互不影响。并在第一期开发结束后部署给企业使用，这样企业就能拥有充裕的时间学习和适应此系统,减少一个新系统可能给客户组织带来的冲击。第二期进行开发直至完成后再部署给企业，这样企业已经事先使用过系统，对系统的排斥性不会那么强了。增量模型是将软件产品作为一系列的增量构件来设计，编码，集成和测试。而 ce 的这种开发方式明显和增量模型类似,当然，也可以说是敏捷开发的增量交付。
最后，我想要通过实验室的 ce 项目来说明敏捷开发的特征。
持续集成：一开始，我已经提到 ce 调研，那时候形成的规格说明文档有项目每个页面的设计方式，这样 ce 的每个模块以及每个页面都已经划分好，剩下的就是开发人员对每个页面的实现。实现一个页面后进行白盒测试，一个模块的所有页面完成时进行集成测试，这符合敏捷开发的方式。
测试驱动开发：很可惜，团队的成员（包括老成员）没有 TDD (测试驱动开发) 的经验，我们使用一个星期的时间学习，最后在讨论中决定不使用 TDD，主要原因是 TDD 讲究先写测试后开发，而我们已经进入了开发阶段；再加上没有经验，如果使用TDD很大可能会拖慢项目进度。
每日站立会议：我们每天都会在实验室进行工作，并且在每天晚上进行一个名叫三分钟站立会议的谈论，这个会议是就是要求每个人用三分钟左右的时间回报当天的工作内容、任务目标及所遇到的问题；我们希望从这次会议获得团队中每个人的任务进度和状态，从而有效的对进度进行把控。这就符合敏捷开发的五大价值观的其中两个：沟通和反馈。
我清楚的记得我当初被任命开发一个叫做“生产通知单”的页面，这个页面设计上不合理，集结了很多表，关系复杂，数据量大，并且由于 Extjs 特性，导致页面加载速度慢。后来团队选择废除这个页面，上千行的代码就这样被废除了。这也符合敏捷开发的一大价值观：勇气。
系统拥有共同的代码：我们使用 Git 对 ce 的代码进行版本管理，由于 Git 巧妙的设计，团队每个成员都用有 ce 的代码（可能是各自不同的版本），不会因为仓库的代码错误和丢失而导致项目失败。
代码的评审和重构：由于进入第一期末尾时，发现有很多 bug ，最终讨论设立一个代码评审人员(一个师兄，他的经验比我们丰富)，他负责对代码进行评审，并将需要重构的代码标记出来形成一个新的任务，将任务授予相应的开发人员。