2018-09-03 15:56:36 tangweiee 阅读数 4541
  • Android开源项目实践之UI篇

    本课程主要展现了如何利用Android开源代码进行app的开发。例如: 1.异步网络请求(android-async-http); 2.百变圆形滚动条(ProgressWheel);3.滑动导航栏(PagerSlidingTabStrip);4.瀑布流与上拉刷新,下拉加载完美结合(PinterestLikeAdapterView)...

    21096 人正在学习 去看看 李忠义

                               敏捷开发和瀑布模型对比


               瀑布、迭代、螺旋、敏捷——在这里讨论的敏捷,都属于过程模型

 

2019-07-03 21:13:48 skyejy 阅读数 108
  • Android开源项目实践之UI篇

    本课程主要展现了如何利用Android开源代码进行app的开发。例如: 1.异步网络请求(android-async-http); 2.百变圆形滚动条(ProgressWheel);3.滑动导航栏(PagerSlidingTabStrip);4.瀑布流与上拉刷新,下拉加载完美结合(PinterestLikeAdapterView)...

    21096 人正在学习 去看看 李忠义

 

 

 

敏捷开发

瀑布模型

 

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

软件生命周期划分为制定计划、需求分析软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

key word

“快”、迭代

文档驱动

适用场景

需求不明确 期限紧迫

需求明确 小系统开发项目

开发特点

适应变化,注重反馈,灵活性强

注重各个流程,一步一步,水到渠成

 

2014-05-03 12:38:37 lantingxv_jing 阅读数 2464
  • Android开源项目实践之UI篇

    本课程主要展现了如何利用Android开源代码进行app的开发。例如: 1.异步网络请求(android-async-http); 2.百变圆形滚动条(ProgressWheel);3.滑动导航栏(PagerSlidingTabStrip);4.瀑布流与上拉刷新,下拉加载完美结合(PinterestLikeAdapterView)...

    21096 人正在学习 去看看 李忠义

    技术交流会中,让我印象最深的是:大勇学长和丹姐在切磋实际项目中用到的“敏捷开发”,后来由向阳学长对比两人的观点发问“敏捷开发和瀑布模型的优缺点?人员要求?流程?”最终由我们敬爱的米老师做高层次的总结。

 

    下面,本人根据学长们的建议,并参阅网上资源对“敏捷开发和瀑布模型做对比分析

 

软件开发模型的由来

    20实际60年代中期,人们在软件开发过程和维护中所遇到的问题被称作是“软件危机”。

    1968年,在德国召开的NATO(北大西洋公约组织),首次提出“软件工程”的概念,希望能用工程化的原则和方法来克服软件危机。

    在此之后,人们开展了软件模型、软件方法、工具与环境的研究,提出了瀑布模型、演化模型、螺旋模型和喷泉模型等开发模型,出现了面向数据流方法、面向数据结构的方法、面型对象的开发方法,以及一批CASE(计算机辅助的软件工程)工程和环境。

 

瀑布模型

    1970年WinSTon Royce提出了著名的"瀑布模型",将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

   

      瀑布模型的特点:

1、各阶段划分很明确,便于项目经理对进度的把控,但是缺乏灵活性。

2、适用于需求很明确项目,因此对于客户需求的变化很难适应。

3、以文档作为驱动,作为每一阶段审核的标准,同时极大地增加了工作量。

4、强调了每个阶段的严格性,只有前一阶段通过审核才能进入下一阶段的设计。开发前期良好需求说明,是最终系统正确性和完整性的保证。

5、由于开发模型是线性的,早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

6、用户只有等到末期才能见到开发成果。

 

由瀑布模型引入敏捷开发

    敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。相对于"非敏捷"更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。


什么是敏捷开发?

    一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验,创建了敏捷开发宣言,让软件开发工作变的更容易更轻松:

  1. 个人和交互重于流程和工具
  2. 有效的软件重于全面的文档
  3. 客户合作重于合同谈判
  4. 因时制宜重于按步就班

 

  敏捷开发的优势?

1、以客户满意度为主。客户会看到产品设计的每一步并在此基础上做出反馈,这时候你需要迅速的做出调整。

2、拥抱变化。客户最关心的是设计出的软件能够满足其需求便阿虎,因此这就需要开发人员从客户那里得到什么,3、就要迅速实现什么。这样软件的每个子项目都会根据需求进行调整,并不会对其它子项目产生不好的影响。

4、频繁交付。从几周到几个月应该交付更新,时间越短越好。及时交付客户维系好的客户关系,并根据客户反馈的信息,并作出相应的调整。

5、面对面的交流。由于领域的区别,客户只是业务了解,而软件开发人员只对软件熟悉,这就可能导致沟通之间出现理解偏差,因为常常在一起工作显得很必然。


瀑布模型和敏捷开发对比分析图:


 

瀑布模型

敏捷开发

开发人员水平

普通。编码阶段是没有创意的机械劳动,容易产生抵触情绪。

一群开发经验丰富和才华横溢的开发人员。在有技术问题还没有解决的情况下不适合展开迭代。

与客户的关系

合同谈判

客户参与。以人为本,客户是软件的使用者,是业务理解的专家,没有客户的参与,开发者很难理解客户的真实需求。

项目经理的管理模式

瀑布模型的项目管理是自上而下的命令式管理

敏捷的管理是团队的自我管理和项目经理的服务式管理。

开发人员对项目的了解

各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等

注重沟通,所有人员对项目活动的理解应该是一致的。

 

 

 

开发流程

严格的阶段划分:需求分析、软件计划、概要设计、详细设计、编码、测试、维护

28原则,用户的核心功能最先完成。

成本计划

确定。瀑布模型适用于需求确定的项目,因为成本也可以确定。

不确定。因为需求不确定,所以项目的成本计划很难确定。

适用范围

需求明确的大型软件

需求变化

如何应对需求的变化

遵循计划。没有反馈,不适合客户需求不断变化的软件开发。市场的需求变动以及客户对需求描述不清会给瀑布模型带来困难。应。瀑布就意味着没有回头路。

相应变化。适应客户需求的快速变化,激发开发者的热情

对文档的要求

注重文档。前一阶段的输出是文档,只有文档经过严格的审批通过后,才可以进入下一个阶段,且把上一阶段的文档作为下一阶段的输入。否则工作不予以展开。

只写核心文档。强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主体。

阶段性产物

面面俱到的文档

具有核心功能的软件

产品交付时间

周期较长。只有到了开发后期,客户才可以看到软件。

周期较短。要求客户有时间对每次迭代的成果进行确认,提出改进意见。


 总结:

     “敏捷”就是快,是一种新的思路。极大地发挥人的创造力,只有快才可以适应社会的节奏。而对于需求明确的大型软件的应用开发,文档的管理与衔接作用是不可替代的。

     至于选择哪一种开发模型,这取决于项目的规模、开发的工期、领导者的素质……。瀑布模型和敏捷开发思想并不是二者只选其一的关系,还可能把敏捷开发的思想融入到“流水线工厂式”的管理中。

      只有认真分析环境因素(外界+人员素质本身)的变化,才能够选择最适宜的开发方式。要知道,最适合的才是最好的。这就是米老师常说的“认识论决定一个人的行为,决定你的未来发展方式,会不会少走弯路”。



2014-07-23 09:52:23 cczk8138 阅读数 588
  • Android开源项目实践之UI篇

    本课程主要展现了如何利用Android开源代码进行app的开发。例如: 1.异步网络请求(android-async-http); 2.百变圆形滚动条(ProgressWheel);3.滑动导航栏(PagerSlidingTabStrip);4.瀑布流与上拉刷新,下拉加载完美结合(PinterestLikeAdapterView)...

    21096 人正在学习 去看看 李忠义



敏捷开发是一种以用户的需求进化为核心、迭代、循序渐进的开发方法。在敏捷开发中,把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成


瀑布模型是一个项目开发架构,一般分成几个阶段: 可行性研究\需求分析\设计\编码\测试\运行维护,每个阶段都会产生循环反馈






2014-03-29 20:10:02 xiaoxian8023 阅读数 6522
  • Android开源项目实践之UI篇

    本课程主要展现了如何利用Android开源代码进行app的开发。例如: 1.异步网络请求(android-async-http); 2.百变圆形滚动条(ProgressWheel);3.滑动导航栏(PagerSlidingTabStrip);4.瀑布流与上拉刷新,下拉加载完美结合(PinterestLikeAdapterView)...

    21096 人正在学习 去看看 李忠义

   在去年12月底开始接触高校平台项目,到现在也快有小半年了。这次的开发不同以往。是以敏捷开发作为开发方式。以前都是遵循传统的瀑布模型,而新方式的开发思路直接与传统的开发思路来了个正面碰撞,擦出了阵阵“火花”。


    在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经根深蒂固,再加上对需求不熟悉,对开发环境不熟悉,新方式的开发反而让人感到别扭,麻烦,甚至抵触。


    由于对敏捷开发的不理解,大家也爆发了很多争论,不过也正是这些争论,引导我们逐步走向了敏捷开发的正途上。


    记得当初在做yh收银系统的时候,采用的是传统的瀑布开发模式。自己做需求也是很费力气的,首先整理当前版本的系统功能,收集和整理以往的维护记录,整理客户的建议。然后再加上自己维护过程中发现需要改进的地儿和参考同类软件,历时1周,需求算是基本做出来了,但是还是有很多问题,许多想要的动能,自己也不确定到底是什么样的。以至于到概要设计完成后,发现设计与最终想要的差距太大,最终决定推倒重来,又花费了1周的事件才搞定需求。加上前面浪费的时间,光是做需求,就花费了近一个月的时间了。也就是说这近一个月的时间,小组成员大部分的时间(项目方面的)都荒废掉了的。


    设计花费的时间就更多了,我们采用的是三层架构+2层接口+抽象工厂模式,实现差不多都是组长去设计,然后画出时序图来,再安排小组成员去完成。做的过程中发现当初设计有问题,还得推到重新去设计。结果就造成了代码没花太长时间,而反复修改设计和各种文档花费时间太多了。


    实现过程看着时序图也不一定可以搞定,而且大家当时的水平也的确有待提高,经常被问题卡住,开发停滞了。没有一个例子做参考,做起来也很费劲。甚至有时候为了完成功能,使用简单的但是不安全的方式实现了,以至于后来得反复修改。


    而且开发时间跨度有点大(最终耗时5个月),小组中有抵触情绪蔓延。。。


    当然我这里只是说在使用瀑布模式做yh系统时,所遇到的问题,并不是说我们开发的一无是处。相反我们开发突破了以前许多设计枷锁,让我们的系统变得很人性化,当然这不是本次讨论的重点,就不在这里说了。


    以上这些问题是有部分是能力所限,但是通过改变开发模式也能解决这些问题。而敏捷开发就是其中一种解决方案。


    本次在做高校平台项目时,采用的是Scrum敏捷开发模式,在简单了解了敏捷开发模式后,越发感觉敏捷开发的优势了。瀑布模式是以文档驱动的,而Scrum则是以人为核心,只完成必要的文档即可,它更强调人与人的交流。而且Scrum之所以成为敏捷开发,主要还是因为它能快速响应变化,快速迭代。


    按照Scrum的开发流程,建立backlog,列story,在迭代计划会上大家一起评story优先级(跟scrum稍有不同),然后制定迭代计划,并一起对本次迭代任务进行评估工时。用集体的智慧和知识对“做什么,怎么做”打成共识。每个人只专注分配给自己或者自己领取的任务模块即可。每日立会也是一个很不错的了解开发进度的方式。每次做完任务后,都要叫Scrum Master来检查一遍。而且在迭代中期和末期都有集体审查,在很大程度中减少了系统bug,不至于最后bug遍地,无法集成。


    当然在这过程中也会遇到问题,被一些难的问题卡住了,会在立会中提到,如果不是很重要的问题,给2天时间解决,否则放弃这个任务,换另一个人去做。或者采取结对编程,这个的确很有效。在对一个大家都了解都比较少的,或者一些逻辑复杂的问题上,一般采用2种方式。一是2个人同时领取相同的任务,各自做各自的,谁完成了就用谁的。另一种是结对编程,2个人坐在一起来完成一个任务。我更推荐爱你结对编程,它在这些问题上的投入往往是1+1>2的,绝对是一个very good choice。


    本次开发设计到许多陌生的知识,如果单纯的理解起来,比较费力,不过如果有工具辅助就是另一回事儿了。本次管理上的不论是“禅道还是“JIRA都是非常值得推荐的项目管理软件。也是通过这两款项目管理软件,才使得我能快速了解和熟悉敏捷开发流程。另一个我觉的非常值得推荐的则是Confluence。Confluence则是一个很不错的Wiki,自我感觉要比使用svn更专业,也更方便。


    当然并不是所有的项目都适合用敏捷开发来做,选择哪种开发模式是根据项目而定的。对时效要求比较高的比如互联网产品,比较适合用敏捷开发。而一些大型、超大型的项目如军工、航天的,就不太适合敏捷开发。还是那句话,适合的才是最好的。


没有更多推荐了,返回首页