【转】瀑布开发与敏捷开发是什么
瀑布开发与敏捷开发是什么
一. 前言
软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。 另外，有一个问题一直是软件开发管理人员的心病：软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。
瀑布模型、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。
二. 瀑布开发
2.1 概念
瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。
2.2 特点
1、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好 象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。
瀑布模型的用户很多，也有一些反对的意见：
第一 瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。
第二 瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。
在这种背景下，敏捷开发带来了新鲜的空气！
三.敏捷开发
3.1 概念
敏捷开发是通过遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品，敏捷开发的软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长。敏捷开发的宣言是个体和交互胜过过程和工具，可以工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。但在敏捷开发过程中人是获得成功的最为重要的因素。文档需适度，在处理客户问题上，双赢比输赢更好，在响应变化过程中，要为下两周做详细的计划，为下三个月做粗略的计划，以后就做极为粗糙的计划。
3.2 开发原则
但敏捷开发也不是随心所欲，自我放纵的开发，他也有自己的开发原则，
（1）尽早并持续地交付有价值的软件以满足顾客需求。
（2）敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。
（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。
（4）业务人员和开发人员在项目开发过程中应该每天共同工作。
（5）以有进取心的人为项目核心，充分支持信任他们
（6）无论团队内外，面对面的交流始终是最有效的沟通方式 个人觉得在团队开发过程中这一点做得不是很好
（7）可用的软件是衡量项目进展的主要指标
（8）敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去。
（9）只有不断关注技术和设计才能越来越敏捷。
（10）保持简明 - 尽可能简化工作量的技艺 - 极为重要。
（11）只有能自我管理的团队才能创造优秀的架构, 需求和设计。
（12）时时总结如何提高团队效率, 并付诸行动。俗话说的好，没有规矩不成方圆，敏捷开发在自由范围之内又遵守自己的原则，兼顾了灵活与实用性。
3.3 方法
下面我们来认识一下敏捷开发的方法，其中包括：极限编程XP，Scrum，精益软件开发，动态系统开发，特性驱动开发，水晶开发。虽然方法不同，但他们都拥有共同的特征：①迭代式开发，②增量交付，③开发团队和用户反馈推动产品开发，④持续集成，⑤开发团队自我管理。
不难看出，敏捷开发的方法和特征正是当代高速发展的社会最需要的开发方法。
3.3.1迭代开发
迭代开发将整个软件生命周期分成多个小的迭代（一般2-4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。
好处：
1）通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险
2）通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要
3）通过小批量减少排队，提供更灵活、快速的交付能力
4）平滑人力资源的使用，避免出现瓶颈。
关键要点：
1）每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。
2）每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈
3）迭代推荐采用固定的周期（2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期，简而言之就是，迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上。
3.4 实践
让我们来看一下，敏捷包括三个层次，（1）理念（敏捷核心思想）（2）优秀实践（敏捷的经验积累）（3）具体应用（能够结合自身灵活应用才是真正敏捷），但我们在实际开发过程中应灵活选择最适合自己的实践，避免教条化。要想应用敏捷开发，必须要深入理解敏捷理念：
其一，深入理解“聚焦客户价值”，包括：标识和消除软件开发中的浪费；交付刚刚好的系统：在项目明显超负荷时，管理者简单地期望靠团队work harder来解决，最终导致：（质量下降，项目延期，客户不满意，团队疲劳，埋下长期隐患）；随时构建质量，不容忍缺陷，发现缺陷应立即停下来解决，以保证在坚实的质量基础上前行；及时消除技术债务，持续保持快速响应；
其二：深入理解“激发团队”，包括：认清团队的基本事实（不盲目冒进，对自己的能力做出正确的评估）；敏捷方式下管理者的转变（通过目标来牵引团队自主工作；帮助团队提供资源，排除障碍；营造团队自管理的工作氛围；作为教练辅导团队进步），敏捷方式下对管理者最大的挑战是学会放松“控制”；基于简单原则的管理，原则简单但必须被遵守）；敏捷方式下团队成员的转变（从被动到主动的心态转变是团队成员适应敏捷开发的关键）；
其三，深入理解“适应变化”，包括：认请“客户是逐步发现真正需求”，我们要意识到，客户是逐步发现他真正要的东西，开发人员逐步发现如何开发产品满足客户需求，在这个过程中随时可能发生变化；小批量是快速交付的关键，在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高。在资源利用率相同的情况下，批量越小，交付周期更短。减小批量不仅带来缩短交付周期，而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处，大幅提升商业价值；通过迭代计划不断调整以适应需求变化，变化无法一次性预测，一开始制作大而全的计划易造成浪费，应根据迭代积累的经验和需求变化的情况对计划不断调整和细化；应持续保持良好的软件架构，新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定；利用多层次反馈不断调整以逼近目标。
3.5 概览
下面让我们来看一下敏捷实践的概览，敏捷软件开发是以短周期迭代为核心，包含团队、工作件、管理和技术优秀实践的集合，其中，敏捷团队包括3个核心角色: PO(Product Owner)、Scrum Master(Scrum教练)和Team(开发产品)，产品Backlog是需求动态管理的载体。在软件开发过程中，团队的交流是必不可少的，这里我们简称“会议”，其中包括：迭代计划会议，每日站立会议，用户故事，结对编程，测试驱动开发和持续集成。
迭代计划会议：澄清需求、对“完成标准”达成一致；工作量估计、根据团队能力确定本轮迭代交付内容；细化、分配迭代任务和初始工作计划。关键要点为：充分参与，相互承诺，确定内部任务。
每日站立会议：是每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加的会议，主要聚焦在下面的三个主题：我昨天为本项目做了什么？我计划今天为本项目做什么？我需要什么帮助以更高效的工作？它的好处在于：增加了团队凝聚力，产生了积极的工作氛围；及时暴露风险和问题；促进团队内成员的沟通和协调。
用户故事：是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。
结对编程：提高代码质量和工作效率。
测试驱动开发：以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；TDD要求测试可以完全自动化运行。测试驱动开发保证代码整洁可用。
持续集成（CI）：是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。持续集成提供产品质量的快速反馈，保证随时拥有可工作的软件。
如有不对的地方，非常欢迎给予指导！
——【感谢】资料来源http://blog.csdn.net/chenleixing/article/details/45129161
——【感谢】资料来源http://blog.csdn.net/chenleixing/article/details/45129161
