一、 敏捷开发模式介绍
软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。
另外，有一个问题一直是软件开发管理人员的心病：软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。
瀑布模型、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。
1. 瀑布开发
瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。
图0 瀑布式开发模型
瀑布模型的特点：
1） 强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
2） 没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
3） 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。
瀑布模型的用户很多，也有一些反对的意见：
第一、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。
第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。
2. 敏捷开发
敏捷开发改进了产品的开发流程，提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。
1） 敏捷开发"前"的产品开发过程
图1 敏捷前开发流程
上图是敏捷开发前我们产品一个版本的开发流程，整个开发大概持续一年左右。从图中可以看出，流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程，前提是需求在产品的初始阶段就完整的被捕获并正确的分析，这样才能保证最后交付的产品是客户所需要的产品，但通常这样的理想状况很难实现。
类瀑布的开发流程缺乏灵活性，无法通过开发活动来发现不够确切的需求，导致产品无法随着业务人员和市场的反馈而随需应变，开发出符合业务人员需求的产品。
2）敏捷开发"后"的产品开发过程
图2 敏捷后开发流程
上图是敏捷开发"后"我们产品一个版本的开发流程，整个开发大概也是持续一年左右，但每个迭代都是1个月时间。和敏捷开发前相比，有很多的区别和优点，下面是其中几点：
l 市场和需求驱动，拥抱变化
在我们产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开发的过程中，产品的业务人员和售前时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。
l 充分利用资源和时间
敏捷开发前，产品的需求设计阶段占用整个开发流程35%左右的时间，这段时间只需要几个核心的架构师和设计人员，无法充分地利用开发和测试人员。敏捷开发后，迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。
l 每日交付
产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。
l 充分自动化
敏捷开发强调拥抱变化，这必然带来动荡的产品代码变更。每一个新的功能和修改的功能，都可以影响到其他功能，造成副作用。所以，需要自动化去支持变化，在变化的同时保证质量和开发速度，包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。
