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

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

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

   在去年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更专业,也更方便。


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


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

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

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

 

 

 

敏捷开发

瀑布模型

 

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

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

key word

“快”、迭代

文档驱动

适用场景

需求不明确 期限紧迫

需求明确 小系统开发项目

开发特点

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

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

 

2019-07-14 15:33:51 qq_29924227 阅读数 97
  • Android开源项目实践之UI篇

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

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

什么是敏捷开发?

敏捷开发=迭代开发+增量开发
迭代开发:将一个大项目分解成多个小项目,每个小项目都有类似的生命周期。开发者首先发布一个简单的版本,然后再不断的增加功能或者进行改进,这个过程就是不断迭代的过程,每次迭代都有完整的生命周期(包括需求分析、设计、编码、测试、部署评估)。
增量开发:迭代开发只是将一个大项目分成多个小项目来完成,但是没有规定如何划分项目进行迭代。这时,就要按照增量开发的方式进行迭代,迭代的每个版本都会增加一个用户可以感知的完整功能,就是按照功能进行划分迭代。

敏捷开发的优点

  1. 及时交付:敏捷开发完成第一个版本就可以先进行交付,而不需要等到完成所有功能再进行交付
  2. 反应迅速,拥抱变化:当前市场需求变化很快,当需求发生变化的时候,敏捷开发可以及时的做出相应,进行改变。
  3. 80/20原则:根据增量开发,可以先完成具有80%价值的20%的功能。

什么是瀑布模式?

一种由需求文档驱动的开发模式,开发人员严格按照文档进行开发,瀑布开发模式分为几个阶段:
在这里插入图片描述

瀑布模式的缺点

  1. 需求隔离:每个开发人员只能接触到自己负责的阶段,对用户需求理解不高,开发人员像流水线上的工人。
  2. 变更代价大:正如这个开发模式的名字:瀑布 一样,如果开发过程中需求变更,代价极大。
  3. 束缚创造力:由于强调文档驱动,限制了开发人员的创造力
  4. 周期漫长
2019-02-28 17:43:55 weixin_44702197 阅读数 115
  • Android开源项目实践之UI篇

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

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

        敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。主要还是以用户的需求进化为核心,采用迭代和循序渐进的方法进行软件开发。

        用通俗易懂的话来说就是客户交付给你一个大的项目。你们研究以后将其分为几个小的可独立运作的小项目分别完成。期间你会影响软件的使用。但是当你们已经完成了小项目的时候客户又提出这个东西不用了或者要变成另外一个东西,那么就需要快速的进行更改。保证快速完成。

敏捷开发的基本流程如下:

1、产品经理将整个项目做一个需求。

2、 召开产品会议,确定哪些需求是需要在第一个迭代中完成的。完成整个产品需要多久。

3、把迭代的功能需求写在纸条上贴在任务墙,让大家认领分配。

4、每天组织十五分钟左右的立会。总结昨天任务完成情况、领取今天任务。在任务墙上更改任务进程。

5、在迭代完成时开评审会议,向客户展示产品,听取客户意见。

6、完成后召开总结大会,总结得失。

 

谈起敏捷开发不得不提瀑布式开发。

 

传统的瀑布式开发一般流程如下:

1、需求分析

2、方案设计。

3、实施/编码

4、测试/评估

 

瀑布式开发流程如下:

1、概念阶段

2、需求阶段

3、开发实现

4、功能测试

5、系统测试

6、内部体验

7、产品发布

在这七个流程中需求阶段、开发实现及功能测试可看做一个敏捷迭代。

瀑布模式把每个环节都可以看做一个黑盒,每个员工只关注自己阶段的工作。这样做的好处是员工可以更加专注的做好自己的本职工作,坏处是沟通不到位,如果有员工离职后面就会很麻烦。同时前面出现的BUG远远大于后面BUG对软件的影响。而敏捷开发则不会出现,因为分为不同个迭代完成,所以可以随时根据客户的需求更改。BUG影响也相对较小。同时客户可以在一次迭代完成以后对产品做一次反馈,可以及时更改,客户满意度更高一些。瀑布式开发较适合相对稳定的大型开发,敏捷开发则更加灵活。

 

 

2019-03-05 10:57:01 weixin_39835036 阅读数 137
  • Android开源项目实践之UI篇

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

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

传统的软件开发模式主要被称为"瀑布法"或者是V model。核心就是自动化生产线的思路。业务用户首先要提出明确、无歧义、有时效性的业务需求,系统分析人员根据业务需求设计系统功能组件和系统整合策略,细化成为软件架构设计、系统整合方案并进行分模块开发。模块开发完毕后从单元测试、集成测试、系统测试直到用户接受度测试一级级往上扩展。

 

瀑布型开发与敏捷开发引起的思考

 

传统的软件系统开发方式路线清晰,管控容易,但最大的前提就是需要业务需求清晰稳定。一旦需求发生变更,尤其是核心需求和关键功能流程的调整,往往会给开发和架构带来灾难性的影响。就好像根据确定车型的生产流水线已经搭建起来了,产品经理说,麻烦把车加长10厘米。生产总监一定会两手一摊说,给我三个月改造生产线吧。一般情况下,程序员对产品经理动了杀心就是在传统软件开发方式+重大需求变更时发生的。

另外,传统的系统开发路线的确清晰,但从设计到开发再到上线往往要经过漫长的等待。最要命的是,在等待期间需求不能随意修改,术语叫做"需求冻结"或者是"需求窗口关闭"(当然需要懂技术的售前进行正确引导客户)。但是在互联网世界里客户的要求是不可能被冻结的,所以传统的软件开发方式玩互联网行不通。

为了在瞬息万变的互联网行业里活命,一些脑子机灵对软件开发熟悉的产品经理捣鼓出了和传统软件开发流程完全不同的开发方式-敏捷开发(Agile Development)。

敏捷开发嘛,顾名思义,最大的特点就是快。那它是怎么实现快速开发的呢?核心思想就是快速迭代,不断优化,永远在改进,永远在发布新版的路上。

瀑布型开发与敏捷开发引起的思考

 

从图中我们可以看到,敏捷开发的起点往往是并不非常清晰的业务需求(但框架不是乱变,这跟盲人摸象还是有本质区别的)。但随着开发的进行和原型开发过程中与业务用户的交互,核心的功能点逐渐清晰并形成测试用例。在完成最基本的核心功能后,系统就可以内部上线并供业务人员使用,让业务人员试用"第一批的新鲜产品"。

业务人员在试用后认为基本达到业务目的,就可以小范围开闸交给友好用户使用。如果业务人员认为不够成熟,那就会返工重新修改调整。我们看到的互联网app经常是1-2周就有一个新版本发布,往往就是采用这种"短平快"周期的敏捷开发模式,术语一般称为"持续交付"。

所以有人形象地做了个比喻:从河岸这一侧的A点到河岸那一侧的B点,传统开发就是设计桥梁,建造桥墩,铺设桥板,按部就班;敏捷开发就是先用弓箭射一根线到对岸,然后线带细绳,细绳带粗绳,粗绳带钢缆,逐步把通行能力从蚂蚁、老鼠,猫最后提升到人甚至汽车。

但无论是瀑布型开发还是敏捷开发,变中不变的都是系统可伸缩框架定义+模块化设计,无论对于哪种模式下的快速迭代开发以及测试效率都有不可替代的作用。跳出现有局限的设计模式,用更上层的思路来解决问题,做到脱胎于设计模式又不拘泥于设计模式,也许是软件架构师最好的归宿。

敏捷开发:瀑布模型

博文 来自: cczk8138
没有更多推荐了,返回首页