【转】瀑布开发与敏捷开发是什么

瀑布开发与敏捷开发是什么

一. 前言       

  软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的观点就是让最聪明的人应该选出来做官,做官就是管理人的。软件开发不仅是代码编程,而是人员的有效组织,如何既发挥人的主观能动性,避免情绪变化对工作的影响,又可以让大家有效的交流,让多个大脑的思路统一,快速完成目标呢?多年来软件企业的管理者一直在不断地探索。       另外,有一个问题一直是软件开发管理人员的心病:软件是工具,开发的是客户业务的应用,但客户不了解软件,开发者不了解业务,如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法,让软件企业付出的代价也是昂贵的。
       瀑布模型、敏捷开发是有代表性的开发模式,在对开发者、客户、最终的产品的关注上的变化,体现了软件开发管理者在管理模式上的变化。

二. 瀑布开发      

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

原文地址:https://www.cnblogs.com/engraver-lxw/p/7375890.html