精华内容
下载资源
问答
  • 敏捷开发与瀑布式开发的区别

    千次阅读 2019-03-04 11:30:30
    首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行详尽的需求调研,根据需求进行完全的架构设计,之后进入开发过程,在...

    敏捷方法与传统方法的区别与联系
      首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行详尽的需求调研,根据需求进行完全的架构设计,之后进入开发过程,在开发过程中,不再进行设计层面的事情,不再处理需求变化的问题,在这个阶段的任务就是对前期设计的功能实现,然后是测试,部署等等。 
      其次,说一下敏捷开发的方式流程,敏捷开发是在上个世纪90年代,传统开发方式不能够满足现实开发的需要,对传统方式进行总结,对成功失败的开发案例进行研究后,得到的一种不同于传统方式的开发流程,主要的特点是迭代式进行,这种方式把一个软件开发过程分成了若干个小的迭代过程,每一迭代完成一部分功能,每一次迭代过程的工作内容按照功能的重要程度不同而排列,首先完成重要的,同时也是风险比较大的功能,而后是次重要的,依此类推,同时在每次迭代中,都要进行分析、设计、开发、测试,因为分成了一个个小过程,一步步的逼近目标,所以,可以使得产品的用户能够逐渐得明白自己的真实需求从而能够提出真正的需求,而开发团队也可以根据更正后的需求进行下一次迭代的设计。 

      其一,敏捷开发是以人为中心,而传统开发以过程为中心。并不是说传统开发就没有人的参与,或者说人不是一个重要因素。应该说的是,敏捷开发和传统开发的侧重点、中心不同。那么为什么会是这个样子呢,或者说Martin   Fowler为什么要这么说呢?因为,传统开发中,设计已经是在初始阶段完成了,在实现阶段不再修改,换句话说,实现阶段就是对设计的完成,设计方案是不可改变的了。这样就忽略了用户的反馈、忽略了开发员的设计的主观能动性,使得开发员只是专注于代码层面的事情,这是很要命的事情,非常的考究需求工程师、设计师的能力,用一句话来形容这种设计-实现效果就是差之毫厘谬以千里。而敏捷开发提倡的是迭代,在每次迭代中都有分析、设计,也就意味着迭代阶段,可以把一部分完成的系统给用户演示,允许用户提意见、需求,也允许开发员将上一次迭代中得到的想法提出来,并且把这些需求意见想法融入到迭代的分析、设计中,从而在根本上、在理念上,促进了造、用双方的一个交流沟通,发挥了用户的分析评价和开发员设计的主观能动性。 
    其二,敏捷开发是adaptive的,而传统开发是plan驱动的。传统开发,设计阶段完成了,整个的过程就是按照设计方案进行,在设计阶段的后续过程中,无法再对设计方案进行修改,而敏捷开发需要一次次的迭代完成,正是这些迭代完成了对客户真实需求的软件的演进。

      一个控制大的流程,一个处理软件开发细节

    原文地址:https://blog.csdn.net/sghdls/article/details/64441512

    展开全文
  • 在软件开发时,经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的...最流行的两种基本方法是:瀑布开发和敏捷开发。这两种方法都是可用的、成熟的方法。 现在,说起...

    在软件开发时,经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法,那么适当了解开发方法和理论是必要的;简单地说,这是一种组织软件开发工作的方法。这与项目管理的风格或特定的技术方法无关,尽管您经常会听到这些术语混在一起或互换使用。最流行的两种基本方法是:瀑布开发和敏捷开发。这两种方法都是可用的、成熟的方法。

    现在,说起敏捷开发(Agile Model)和瀑布开发(Waterfall Model)模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。本文主要简单介绍敏捷和瀑布的区别和优劣。

    敏捷开发和瀑布开发
    1、瀑布模型
    瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时,开发才会应进入下一阶段。在瀑布模型中,阶段不重叠。在这种方法中,事件的顺序是这样的:
    - 收集和记录需求
    - 设计
    - 代码和单元测试
    - 执行系统测试
    - 执行用户验收测试(UAT)
    - 解决任何问题
    - 交付成品

    对于瀑布的开发模型来看,似乎依然具备很可靠的工作逻辑,一个工程或项目分为多个阶段,每一个阶段都投入相应的资源,来完成本阶段的工作。每一个阶段到下一个阶段,都有明确的输入输出产物,不同的阶段根据自己所需的输入,进行工作活动之后,产生自己阶段的产出,投入到下一个阶段的工作中。如果不放心的话,每一个阶段还可以增加一个审批环节,让每一个环节都可以经过可靠的审批之后,再投入到下一个环节当中。

    SDLC瀑布模型一般用于这些情况:要求稳定且不经常更改;应用程序很小;没有不明白或不明确的要求;环境稳定;使用的工具和技术是稳定的;不是动态的;资源可用。

    2、敏捷模型
    敏捷是一种迭代的、基于团队的开发方法。这种方法强调以完整的功能组件快速交付应用程序。所有的时间都被“固定时间盒”划分为“冲刺(通常称迭代)”阶段。而不是创建任务和时间表。每个迭代周期都有一个定义的持续时间(通常以周为单位),其中包含在迭代开始时计划的可交付成果的运行列表。交付物根据客户确定的业务价值进行优先级排序。如果迭代中所有计划的工作都不能完成,那么工作将被重新排序,这些信息将用于未来的迭代计划。当工作完成时,项目团队和客户可以通过每日构建和迭代演示对其进行审查和评估。敏捷依赖于整个项目中非常高水平的客户参与,特别是在这些评审期间。

    在敏捷看来,很多情况下面,我们都无法去了解到全部的内容,或者即使是了解到,我们也不能保证这些内容是不会变化的。所以先根据主路径,完成主要功能后,我们再通过不断地迭代,去完善我们的工作,这样当我们产生变化的时候,我们推翻的工作量也是少量的,可以很快的去完成新的需求变更。通过这样的不断地变更、重构,我们可以获得一个相对客户满意的产品。

    很多支持敏捷的同学会说,与瀑布方法相比,敏捷风险的风险要小得多。因为其专注于交付经过充分测试的独立、有价值的小功能。因此分散了风险——如果一个功能出错了,它不应该影响另一个功能。在这一方面,我们仍然在迭代中计划我们的工作,并且我们仍然会在每次迭代的末尾发布。而瀑布缺乏与业务的沟通和迭代次数,所以如果在项目的后期才发现要更改需求的话,则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

    在高举效率与拥抱变化的大旗之下,似乎敏捷模式,就是最好的开发模式。与之相比的是瀑布模式,在这样的呼喊之中,显得有些无法跟得上步伐,体现的是陈旧、死板的。

    “瀑布”对“敏捷”的驳斥
    敏捷本身不是项目管理框架,也不是“方法论”。它是一套与产品开发相关的原则和价值,特别是互联网产品经常会采用敏捷的方法来进行开发。但是,有一些基于敏捷原则的方法,这些方法是产品开发方法,而不是项目管理框架。

    说到需求变更,瀑布也可以走需求变更,提变更申请,按照环节一步一步走,去规划工作量。虽然比敏捷是要慢一些,但是我整个流程是可靠的!为什么就说瀑布是死板的,不符合时代的呢?

    似乎瀑布的做法也没有错误,我们何不按照这样的步骤,来完成我们的工作呢?这样的过程听起来是如此的可靠。看,我有明确的阶段;看,我有明确的审批;看,我有明确的变更流程。以瀑布模式进行开发的项目有这么多,已经证明了这是一个有效的实施方法,难道不是么?

    另外被敏捷所诟病的瀑布项目经常失败通常是发生了非常严重的错误情况下才会产生。实际上只有在对项目的控制很差的情况下才会发生这种情况。瀑布型项目没有迭代和用户的多次反馈也是不正确的 - 很多项目可以通过产品原型图的方式和业务部门确认操作的流程,只是很多项目中并没有使用这种方法。

    焦点碰撞
    敏捷模式,两周一个迭代,每个迭代都能进行一定功能模块的交付,让用户更早的看到交付物,虽然只有部分,也可以让用户来提出自己的看法,产生变更的时候,开发人员也可以在下个迭代中进行修改,让用户进行再次的确认。

    从这样看来,两者的碰撞就是在交付的及时性上与面对变更的成本上,所看到有极大的变化。瀑布在交付阶段比较靠后,交付的模块比较完整,在面对变更的时候,变更影响范围就比较大,变更的成本就极大。问题发现的阶段越靠后,解决问题所需要付出的成本就更高。这样,就体现出来了敏捷对瀑布在这样的情景下面的优势。

    时间和成本,看起来就是敏捷和瀑布在选择时主要考虑的两个方面。未来能更好的指导未来的选择,下面还列出了更详细的敏捷和瀑布的优劣势。

    敏捷开发的优势:
    • 开发的阶段性成果会在开发过程中尽早的进行审查,项目的风险会降低;
    • 适用于需求不明确情况,因为需求不明确,所以需要在不断迭代的过程中来逐步理清需求。
    • 灵活性较高,几乎可以在任何时间进行需求变更;
    • 敏捷鼓励开发人员与业务用户之间进行多频次的沟通,业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新,
    • 敏捷的协作通常要高得多,通常能开发出更高质量的产品;
    • 适用于快速变化的项目,特别是面向前端业务人员的CRM系统项目更容易根据业务的变化而变化。

    I 敏捷开发的劣势:
    • 敏捷的概念接受度还不算太高,初次尝试可能不会非常成功;
    • 最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;
    • 敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证;
    • 当存在乙方供应商的情况,敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高;
    • 在敏捷项目中,最大的问题可能是业务部门永远不希望有最终的截止时间。

    I 瀑布开发的优势:
    • 在管理良好的项目中,瀑布可以在早期提供交付的信心;
    • 项目团队成员不需要在同一地点频繁沟通;
    • 在需要大量的设计或分析的情况下瀑布是一种更合适的方法;
    • 如果在基本产品开发之外存在许多接口和依赖关系,瀑布式项目会使用工具来建模和管理这些接口和依赖关系。

    I 瀑布开发的劣势:
    • 许多企业和业务人员确实不容易在前期定义清楚需求,早期计划中所依据的假设需求可能存在很大风险;
    • 沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通,后期项目和业务人员的预期差别很大;
    • 瀑布项目的风险一般都很高,因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况。

    结论:
    敏捷和瀑布的实施方法差别还是很大的。现在,瀑布几乎可以应用于任何类型的项目,尤其是大型的项目。敏捷方法在这两年来越来越受欢迎,我们开始看到企业(甚至国防部和联邦机构)中大量采用各种敏捷方法,尤其是当前SaaS软件当道,如Salesforce、SAP等这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代。但总的来说敏捷并不能完全替代瀑布,它只是给了我们另外一种好的选择。

    现在,对于组织来说,将敏捷和瀑布方法结合在一起的混合敏捷方法也很常见。一旦我们决定了使用哪一种基本方法,我们就可以进一步细化过程以最适合我们的项目目标。最后,尽管我们工作的方式很重要,但是交付一个可靠的、可维护的、满足客户需求的产品才是最重要的。

    如需了解更多,欢迎访问怡海软件官网 http://www.frensworkz.com/

    展开全文
  • 瀑布模式 瀑布模型是比较传统一种开发模式,特别是在2B的传统企业,包括ERP,MES,WMS,CRM,OA,IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目...

    瀑布模式

      瀑布模型是比较传统一种开发模式,特别是在2B的传统企业,包括ERP,MES,WMS,CRM,OA,IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。

       

    如上图所示,瀑布模型优缺点都很突出。

    优点明显:

    • 阶段清晰。从计划到开发最后到上线运行,三个阶段非常清晰。

    • 时间顺序。每个阶段顺序必须是从上到下,严格按照时间先后进行。

    • 环环相扣。在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。

    • 黑盒模式。每个阶段都有各自的角色和分工,各自只关心自己的任务。比如需求阶段开发人员无需关注。

    缺点突出:

    • 需求隔离。由于各阶段的人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等,开发人员更像是定义为流水线上的工人。

    • 变更代价大。既然叫做瀑布,就意味着不应该走回头路。否则如果出现返工,付出的代价会很大。需求变更,编码人员会很强的抵触情绪。

    • 束缚创造性。由于强调文档管理,所以管理人员会比较喜欢,但是他束缚了开发人员的创造性。

    • 周期漫长。整个开发持续的生命周期很长,需求和设计的时间会耗费特别多,有时候会占用三分之一甚至更多时间,这样整个周期就会变长,大都在半年到一年左右的时间,所以更适合需求相对稳定的大项目。

    归纳总结

      根据以上分析,我们知道瀑布模式强调里程碑,重视文档,强调分工,避免变化,凡事喜欢规划和做计划,但是代价就是拖沓笨重,反应迟钝。

    敏捷模式

    发展背景

      敏捷开发借助互联网浪潮开始流行起来,这也是2C的业务特点决定的,看过QQ和微信长大的人,这种体会特别深。互联网产品不可能一步规划到位,一般都是核心功能优先,比如微信,先是实现聊天功能,然后才是漂流瓶,钱包,小程序……

    互联网业务有何特点呢?借用雷军的七字诀:专注、极致、口碑、快。

    • 唯有专注才能聚焦能量,引爆燃点。

    • 唯有极致才能排除竞争,争取用户。

    • 金杯银杯不如口碑。

    • 天下武功唯快不破。

      敏捷无疑更加贴近互联网的这种业务需求,如果纯用瀑布模式,估计黄花菜都凉了。敏捷还有一个更极致的做法,直接上PPT通过类似众筹的方式进行开发,这种从群众中来到群众中去的个性化定制功能非常的有创意,如果众筹的结果是没有人感兴趣,就可以直接否定该产品开发,可以避免无谓的“库存”导致的开发压力,节省巨大的成本浪费。

    Scrum是什么

      

      Scrum的意思是橄榄球运动的一个专业术语,表示“争球”的动作。把一个开发流程的名字取名为一项体育运动,你一定能感受到其中的碰撞,冲突,激情。如果是这样,Scrum如何能提高开发效率呢?敏捷开发是一种指导思想,Scrum和XP则是敏捷开发的具体开发流程,这里只选择Scrum进行探讨。

      我们先来看下Scrum的三个角色:

       

    • 产品负责人:提供整体产品需求清单,确定产品边界,功能组合图谱,交付内容和日期。另外产品负责人有权拒绝开发团队的开发成果。

    • 开发团队:因为追求快,开发人员需要很强的自我管理能力,需要主动反馈,主动沟通。

    • 流程管理员:主要任务是疏通开发和业务的障碍,起到一个胶水的粘合作用,所以一旦开发进行,流程管理员有权拒绝需求的变更或修改。

      Scrum是一个理想化的开发流程,前提条件是角色完整,分工明确,配合默契,沟通融洽。如果出现其中任何一个环节的故障,可能都会破坏流程的效率,比如,开发经理和流程管理员脾气一样倔强,脾气互斥,那么整个效率就打折扣。我感觉在招聘人员,团结组建的过程中,我们务必要寻找气味相投的人,这可以减少开发过程中的冲突。

      Scrum和瀑布的本质区别是,一个以文档为本,一个以人为本。在以人为本的团队里,领导者的文化就是团队的文化。如果领导者不透明,喜欢玩虚假,自大,官僚气十足,这个团队基本上就没什么希望了。人必须是主人,有能动性,这个高度困难。因为如何让团队觉得公司的事是我家里的事是高度困难的,因为有些开发人员自己家的事都没怎么认真过。想要做到这点,需要老板重视,否则中层领导我感觉一般都心有余力不足。

    Scrum流程图

       

    • 首先需要确定一个产品需求列表,由产品负责人负责;

      

    • 开发团队根据列表,做工作量的预估和安排

    • 有了产品需求列表,我们需要通过计划会来从中挑选出一个故事作为本次迭代完成的最小目标,这个目标的时间周期是1~4个星期,然后把这个故事进行细化,形成一个最小产品需求。比如该故事是登陆的功能故事,那么登陆的需求就要进行完整的细化工作;

    • 开发成员根据故事再细化成更小的任务(细到每个任务的工作量在2天内能完成);

       

      计划纸牌怎么怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...

    • 开发过程需要设置每日站会,每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报三个问题:A.你昨天完成了什么;B今天要完成什么;C.什么问题不能解决。

      每个人回答完成后,要走到黑板前更新自己的sprint燃尽图;

       

      

    • 每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本,可以机制CI,CD工具进行辅助开发;

    • 当一个故事完成,也就是最小目标被完成,这时,我们要进行演示会议,也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个开发成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

      

    • 最后就是回顾会议,也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮sprint的产品需求中;

      大家如果认真的看完整个Scrum的开发流程,会发现这个过程还真的是很完美,不妨可以用在你的团队开发过程中。

    瀑布vs敏捷

    对比一览图

      瀑布敏捷是有边界的,我觉得团队在整体学习开发模式优劣后,需要对二者的边界有一个清晰的认识,并在整个团队上下都要达成一致的共识,否则后果可能会很严重。双方的边界如下图所示

      

      为什么说共识很重要呢?就我踩过的坑进行盘点,有如下几个问题:

    • 领导指挥不当:老板重文档,觉得必须有文档往下开发才是规范的,否则后面的工作都是一种浪费,因为你的顶头上司不一定懂技术,这样导致的结果是文档没出来前,底下人只能泡茶聊天了。

    • 团队效率极低:因为瀑布强调分工,各自为战,所以有可能架构设计人员在等产品经理给需求文档,开发人员在等待架构设计文档,测试人员在等待开发成果,老板在等待产品交付。这里环环相扣,类似电流串联工作,一个环节出错,造成断电,导致交付延期,后果可能就是互相推诿和扯皮,严重的话可能会引发争吵,团队分崩离析。

    归纳盘点

      就个人的经验来看,瀑布和敏捷不是天然分割的,只是针对业务各有侧重,应该是你中有我,我中有你的混合体。比如微信第一版的时候,聊天核心功能的迭代一定也有内部的小瀑布,如果没有计划-开发-测试-运维根本就无法进行下去。再比如瀑布,特别对创业团队,刚开始人手不多,分工不明,架构师有可能要去画原型图,做需求调研;产品经理业务模糊,还在探索,各种短板和不足就像黑洞一样存在你的周边,你浑然无知。如果你一定要等整个调研完成,PRD文档周全再做开发,估计也要歇菜。

      既然各有利弊,那么中间的这个平衡点如何拿捏就非常重要,如何在前期设计的时候既能不过渡导致交付延迟,又能兼顾后续的演进和变化导致的修改可控,这需要开发经理丰富的实战历练和审时度势的判断力。

      另外叨叨一下,开发模式贯穿做整个开发的生命周期,但是团队各个成员包括产品经理,技术经理,架构师,开发人员对项目管理的流程理解各不相同,深浅不一,很难想象如果大家没有达成共识,整个开发团队的效率会有多高?但是现实当中,大部分团队成员没有开发模式的培训和上下达成一致依然在进行着开发的工作……

    出处:https://www.cnblogs.com/jackyfei/p/10078988.html

    展开全文
  • 最近和朋友谈起敏捷开发(Agile Model)和瀑布开发(Waterfall Model)模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些...

          最近和朋友谈起敏捷开发Agile Model瀑布开发Waterfall Model模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。我之前参与过敏捷开发的项目,但当时比较“年轻”,认识不是很深刻,于是最近又补习了下和大家一起分享下我对敏捷和瀑布的感悟。

           简单介绍敏捷开发和瀑布开发

           瀑布模型:瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时,开发才会应进入下一阶段。在瀑布模型中,阶段不重叠。下图演示了瀑布模型:

           对于瀑布的开发模型来看,似乎依然具备很可靠的工作逻辑,一个工程或项目分为多个阶段,每一个阶段都投入相应的资源,来完成本阶段的工作。每一个阶段到下一个阶段,都有明确的输入输出产物,不同的阶段根据自己所需的输入,进行工作活动之后,产生自己阶段的产出,投入到下一个阶段的工作中。如果不放心的话,每一个阶段还可以增加一个审批环节,让每一个环节都可以经过可靠的审批之后,再投入到下一个环节当中。

    Salesforce crm开发2.jpg

           SDLC瀑布模型一般用于这些情况:要求稳定且不经常更改;应用程序很小;没有不明白或不明确的要求;环境稳定;使用的工具和技术是稳定的;不是动态的;资源可用。

           敏捷模型:维基百科将敏捷模型定义为“一组基于迭代和增量开发的软件开发方法,其中需求和解决方案通过自组织,跨职能团队之间的协作发展。”该模型有自己的原则,往往会使流程置于backset。

    Salesforce crm开发.jpg

          
           在敏捷看来,很多情况下面,我们都无法去了解到全部的内容,或者即使是了解到,我们也不能保证这些内容是不会变化的。所以先根据主路径,完成主要功能后,我们再通过不断地迭代,去完善我们的工作,这样当我们产生变化的时候,我们推翻的工作量也是少量的,可以很快的去完成新的需求变更。通过这样的不断地变更、重构,我们可以获得一个相对客户满意的产品。

           很多支持敏捷的同学会说瀑布缺乏与业务的沟通和迭代次数,所以如果在项目的后期才发现要更改需求的话,则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

    Salesforce crm开发3.jpg

           在高举效率与拥抱变化的大旗之下,似乎敏捷模式,就是最好的开发模式。与之相比的是瀑布模式,在这样的呼喊之中,显得有些无法跟得上步伐,体现的是陈旧、死板的。

           “瀑布”对“敏捷”的驳斥

           敏捷本身不是项目管理框架,也不是“方法论”。它是一套与产品开发相关的原则和价值,特别是互联网产品经常会采用敏捷的方法来进行开发。但是,有一些基于敏捷原则的方法,这些方法是产品开发方法,而不是项目管理框架。

           说到需求变更,瀑布也可以走需求变更,提变更申请,按照环节一步一步走,去规划工作量。虽然比敏捷是要慢一些,但是我整个流程是可靠的!为什么就说瀑布是死板的,不符合时代的呢?

           似乎瀑布的做法也没有错误,我们何不按照这样的步骤,来完成我们的工作呢?这样的过程听起来是如此的可靠。看,我有明确的阶段;看,我有明确的审批;看,我有明确的变更流程。以瀑布模式进行开发的项目有这么多,已经证明了这是一个有效的实施方法,难道不是么?

           另外被敏捷所诟病的瀑布项目经常失败通常是发生了非常严重的错误情况下才会产生。实际上只有在对项目的控制很差的情况下才会发生这种情况。瀑布型项目没有迭代和用户的多次反馈也是不正确的 - 很多项目可以通过产品原型图的方式和业务部门确认操作的流程,只是很多项目中并没有使用这种方法。

           焦点碰撞

          敏捷模式,两周一个迭代,每个迭代都能进行一定功能模块的交付,让用户更早的看到交付物,虽然只有部分,也可以让用户来提出自己的看法,产生变更的时候,开发人员也可以在下个迭代中进行修改,让用户进行再次的确认。

          从这样看来,两者的碰撞就是在交付的及时性上与面对变更的成本上,所看到有极大的变化。瀑布在交付阶段比较靠后,交付的模块比较完整,在面对变更的时候,变更影响范围就比较大,变更的成本就极大。问题发现的阶段越靠后,解决问题所需要付出的成本就更高。这样,就体现出来了敏捷对瀑布在这样的情景下面的优势。

          时间和成本,看起来就是敏捷和瀑布在选择时主要考虑的两个方面。未来能更好的指导未来的选择,下面还列出了更详细的敏捷和瀑布的优劣势。

          I 敏捷开发的优势:
           • 开发的阶段性成果会在开发过程中尽早的进行审查,项目的风险会降低;
           • 适用于需求不明确情况,因为需求不明确,所以需要在不断迭代的过程中来逐步理清需求。
           • 灵活性较高,几乎可以在任何时间进行需求变更;
           • 敏捷鼓励开发人员与业务用户之间进行多频次的沟通,业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新,
           • 敏捷的协作通常要高得多,通常能开发出更高质量的产品;
           • 适用于快速变化的项目,特别是面向前端业务人员的CRM系统项目更容易根据业务的变化而变化。

           I 敏捷开发的劣势:
           • 敏捷的概念接受度还不算太高,初次尝试可能不会非常成功;
            • 最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;
           • 敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证;
            • 当存在乙方供应商的情况,敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高;
            • 在敏捷项目中,最大的问题可能是业务部门永远不希望有最终的截止时间。

          I 瀑布开发的优势:
            • 在管理良好的项目中,瀑布可以在早期提供交付的信心;
            • 项目团队成员不需要在同一地点频繁沟通;
            • 在需要大量的设计或分析的情况下瀑布是一种更合适的方法;
            • 如果在基本产品开发之外存在许多接口和依赖关系,瀑布式项目会使用工具来建模和管理这些接口和依赖关系。

           I 瀑布开发的劣势:
            • 许多企业和业务人员确实不容易在前期定义清楚需求,早期计划中所依据的假设需求可能存在很大风险;
            • 沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通,后期项目和业务人员的预期差别很大;
            • 瀑布项目的风险一般都很高,因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况。

           结论:

           敏捷和瀑布的实施方法差别还是很大的,瀑布几乎可以应用于任何类型的项目,尤其是大型的项目。

           敏捷方法今年来越来越受欢迎,尤其是当前SaaS软件当道,特别像Salesforce crm系统这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代,所以我们才会看到有越来越多的企业采用敏捷的方式来进行项目实施。总的来说敏捷并不能完全替代瀑布,它只是给了我们另外一种好的选择。

           如需了解更多,欢迎访问怡海软件官网 http://www.frensworkz.com/

     

    转载于:https://my.oschina.net/frensworkz/blog/3063878

    展开全文
  • 转:瀑布式开发和敏捷开发区别

    千次阅读 2019-02-28 14:03:19
    瀑布开发模式瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
  • 什么是敏捷开发和瀑布式开发

    万次阅读 2019-06-13 11:15:41
    瀑布开发模式瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...
  • 1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布模型式是...瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整, 代价高昂。瀑布式方法在需求不明并
  • 开发模式(敏捷开发,瀑布式开发,螺旋型开发,迭代开发,devOps开发 https://blog.csdn.net/sinat_35566306/article/details/90404606
  • 瀑布式开发和敏捷开发区别

    万次阅读 多人点赞 2017-09-27 21:42:15
    瀑布开发模式瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格...
  • 瀑布式开发的基本流程是 需求 → 设计 → 开发 → 测试 , 是一个更倾向于严格控制的管理模式 。 要求有明确的需求,大家按照需求一步步做好规划,每一阶段工作的完成是下一阶段工作开始的前提,每一阶段都要进行...
  • 瀑布式开发是将项目划分为多个有限阶段并按顺序逐步完成各阶段的软件开发方法。瀑布式开发能够简化项目控制,并减少开发阶段不必要的跨团队交流。无需频繁修改计划,项目评估与管理也不再繁琐。V 型开发流程以瀑布...
  • 瀑布开发模式瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...
  • 此外,“作坊”式开发特别倚重个人能力,大多都杂乱无章,软件质量也无从保障。 20世纪 70 年代开始,“工程化”思维开始进入软件开发流程。主要原因是,信息技术发展迅速,人们对软件的需求变大,软件生产必须提高...
  • 一、瀑布式开发:     二、迭代式开发:     两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说。 传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到...
  • 现在好多规模不大的非完全软件公司在开发软件项目时到底应该如何根据自己的实际情况选开发模式?为了节约大佬的时间我先说结论再分析原因,对于时间紧张的大佬可以不看后面的具体分析。结论:第一类:工具类软件和...
  • 瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行...
  • 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。主要还是以用户的需求进化为核心,采用迭代和循序渐进的方法进行软件开发...
  • 部门推广scrum敏捷开发已经小半年了、团队也从不适应、慢慢地开始变的习惯。之前领导安排我作为我们组的scrum...现在随着大家都开始慢慢习惯scrum的工作模式、我才开始慢慢地从每天1/3的时间、降到每天只要半个多小时花
  • 敏捷开发瀑布模式

    2019-07-14 15:33:51
    什么是敏捷开发? 敏捷开发=迭代开发+增量开发 迭代开发:将一个大项目分解成多个小项目,每个小项目都有类似的生命周期。开发者首先发布一个简单的版本,然后再不断的增加功能或者进行改进,这个过程就是不断迭代的...
  • 瀑布式开发总结

    千次阅读 2013-05-22 22:16:41
    各类大中小型企业所运用的传统软件构建方法,即是众人皆知的“瀑布”型开发方法。此模型存在很多变体,其典型性是在开发初期制定详细的计划,在计划中最终产品已被仔细研究,设计,并且一切详细资料都记录在案。任务...
  • 线性性质是瀑布式开发的主要特点:当这一阶段完成,下一阶段紧接开始,两者配合的几乎天衣无缝。“瀑布模式”开发过程是通过设计一系列阶段顺序展开的,只需朝一个单一的方向推进工作,而不幸的是,随着问题的不断...
  • 瀑布式开发及与迭代式开发的区别

    万次阅读 2013-11-25 11:09:54
    瀑布式开发及与迭代式开发的区别
  • 浅谈开发模式瀑布模型

    千次阅读 2018-02-15 10:49:48
    前面分享了N多干货,不知道看客有没有看吐,反正本凯总是写吐了。之前在合计着跳槽那点事,因为是半路出家,工作经验也只有一两年这样... 众所周知,当下圈内的开发模式,可以说有四种(瀑布,敏捷,快速应用,Dev...
  • 倒不是人们对微软的软件产品不满意,而是其更新周期太过漫长,比如Office、Windows、SQL Server和Exchange等主打产品的更新周期都长达3年左右,这其中的主要原因就是微软在软件项目的开发中采用了瀑布式开发模式。...
  • 说到软件开发,模式有很多,敏捷开发算是比较新颖的一种,经过近些年不断地发展,在国内逐步吸引了...相对于传统开发模式,它比较注重以用户需求为核心,采用持续迭代,循序渐进的开发方式,严格的来说,敏捷开发并...
  • 1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤...
  • 软件生命周期,又称为 软件生存周期 或 系统开发生命周期,是软件的产生直到报废的生命周期,周期内有以下八个阶段: 问题定义 可行性研究 需求分析 概要设计(总体设计) 详细设计 编码与单元测试 综合测试 软件...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,353
精华内容 5,341
热门标签
关键字:

瀑布式开发模式