精华内容
参与话题
问答
  • 螺旋模型:从制定计划、 风险分析、实施工程(需求确认、软件需求、软件产品设计、设计确认与认证、详细设计开发、测试)、 客户评估。每一次螺旋包括4个步骤:制定计划、风险分析、实施工程、客户评...

    软件研发中敏捷开发和迭代开发的异同

    在讲敏捷开发之前,先了解几个常见的软件研发模式

    瀑布模型:瀑布模型的软件研发过程与软件生命周期一致,由文档驱动,两相邻之间存在因果关系,需要对阶段性的产品进行review。

    螺旋模型:从制定计划、 风险分析、实施工程(需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试)、 客户评估。每一次螺旋包括4个步骤:制定计划、风险分析、实施工程、客户评估。螺旋模型强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
    接下来,本文主要在以下几个方面区别敏捷和迭代的异同

    一、定义:

    敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    迭代开发:整个开发工作被组织为一系列的短小的、固定长度(如2周-4周)的小项目,被称为一系列的迭代,这叫迭代开发。

    二、区别:

    1、性质不同:迭代开发是软件开发的生命周期模型,每一个迭代都是一个完整的瀑布模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一种开发方法。这是两者最根本的区别。

    2、开发方法模型不同:迭代开发对应的是瀑布模型,螺旋模型等;敏捷开发对应的是Scrum,XP(极限编程),Crystal(水晶编程)等开发方法。

    3、对需求要求不同:迭代式开发适合那些需求信息不明确的项目;而敏捷开发是紧紧围绕用户需求,以用户为导向,以快速开发,快速验证,快速修正的迭代式开发打造大量精品。

    三、联系:

    1、开发方法:
    敏捷开发和迭代开发都有采用迭代的方法进行软件开发。

    2、实际应用中的联系:
    1)敏捷开发的核心原则是拥抱变化,递增变化。迭代式开发适合那些需求信息不明确的项目,这样在开发过程中遇到需求的变化时,所带来的影响要比其他模型小。而现在的很多项目中,需求在项目进行中变化的事儿经常见,所以显得迭代式开发的优势更明显一些,这正符合敏捷开发的拥抱变化。而且迭代开发是不要求每一个阶段的任务做的都是最完美的,先将主要功能先搭建起来,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交,然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善,这正符合敏捷开发的递增变化。

    2)敏捷开发只是一个总体概念,而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)等等。总而言之,就是敏捷开发与迭代开发是整体与局部的关系,前者就像大家庭,而后者是大家庭中的一员

    3)敏捷迭代开发是对用户反馈的核心功能进行规划,从最小化可用产品 的用户试用反馈,到每个功能用户参与的反馈,形成 开发 、测试、 验证的快速循环。

    总结:敏捷和迭代虽然不一样,但是它们也是分不开的,迭代和敏捷开发方式的结合,既保证了产品的质量又在项目产品的持续改进中具有一定的优势。吸取精华,破其糟粕,只有这样,项目才会达到趋于完美的程度。

    展开全文
  • 敏捷实践总结(三)——Scrum敏捷开发

    千次阅读 热门讨论 2014-02-22 15:19:27
    瀑布模型中有严格的文档要求(需求、概要、详细等)、员工的工作量也有明确的定义与考量方法(代码量等等)。另外,瀑布模型对于开发者有着明确的分工:搞需求的专门搞需求,搞设计的搞设计,编码的只管编码,测试...

    采用敏捷开发进行项目开发已经有些天了,近几天又看了一本关于Scrum的书。在此跟大家分享一下感受。

    scrum本意是橄榄球运动中的争球。在中国不兴打橄榄球,在我的印象中,橄榄球运动是非常野蛮的,球员目的非常明确——破门得分。你可以抱着球跑,可以传给队友……各种方式都可以,就是要快速得分。敏捷开发就是需要这种精神。

    敏捷开发不同于以往的瀑布模型开发。

    瀑布模型中有严格的文档要求(需求、概要、详细等)、对员工的工作量也有明确的定义与考量方法(代码量等等)。另外,瀑布模型对于开发者有着明确的分工:搞需求的专门搞需求,搞设计的搞设计,编码的只管编码,测试的只管测试。所以说,各部门之间的任务相对明确。但是沟通效率很低,由于文档的要求严格,各部门机制臃肿,彼此之间不能做到及时有效的沟通,不仅耗资巨大,而且延误交付日期。另外,由于一般都是架构师整好设计,下面培训一批写代码的,所以开发者只能被动接受任务,每天干着暗无天日重复搬砖的日子,所以开发的效率也很低。

    但是瀑布模型相比与敏捷开发,无疑就成了重量级,而敏捷开发则是轻量级。

    瀑布模型风险较大,在实际中,并不是每个项目在前期都能够做到需求明确,就像这样:



    而敏捷开发则非常适合需求变动的情况,敏捷开发的工作量是随着需求的变化而不断发生变化的,所以整个过程中,浪费很少:




    Scrum是最常用的敏捷开发(Agile)方法。下面我们来看一下Scrum大概的流程:



    1、在一个Scrum项目中,产品负责人(Product Ower)建立待开发的产品条目(Product Backlog),并确定其优先级。开发中需求的改变也要写进去,对于调研、查阅资料、配置环境等也应考虑进去,因为这些也很占用时间,敏捷开发中不提倡冲刺,不提倡加班,讲究发挥团队最大价值;

    2、根据所列Product Backlog情况,确定产品一个迭代(Sprint)所要完成的东西,每一个Sprint大概是2-6周的时间;

    3、Sprint开始前,需要开一个迭代计划会议(Spint Planning Meeting)会议。会上,产品负责人(Product Owner)讲解本次开发要开发的条目(Story),将确定的Story放入Sprint Backlog中来;

    4、Sprint开发过程中,团队每天都要开一个15以内的站立会议(Daily Stand-up Meeting),以便团队之间了解彼此的开发进度。

    会议由Scrum Master主持,Scrum所有成员轮流回答三个问题:(1)昨天我完成了什么工作?(2)今天我打算做什么?(3)我遇到了什么障碍?会议的目的是团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。

    5、Sprint结束之后,需要开评审会(Review Meeting),Scrum团队会在评审会议上把这个迭代的开发成功展示给大家;

    6、之后还要开一个反思会(Restrospective Meeting),Scrum团队会回顾过去这个Sprint,从中总结经验教训。

    会议围绕三个问题讨论:上次迭代有哪些事情坐的好,希望继续;哪些事情坐的不好,希望改进;有何改进计划。会议目的旨在帮助团队总结经验教训,分享经验,使团队持续成长。


    上面就是Scrum的大概执行流程。

    另外一些注意事项:

    Scrum讲究开发团队坐在一起,有什么问题即时相互询问;

    用拍扑克的方式角色每个story的开发时间;

    测试要尽早加入到开发团队中来,可以与开发人员进行结对开发,尽早的了解需求,大大减少测试人员的工作量;

    开发人员工作量的评定要主要以团队开发的质量为标准;

    Scrum把软件开发中各种角色形象的分为两类:一类是“鸡”,一类是“猪”。这里源起于一个“肌肉火腿肠”的故事,不实际参与项目开的管理者称为“鸡”,全身心投入项目开发的团队成员称为“猪”;


    刚开始实施起敏捷开发是比较困难的。很容易走教条主义的错误,机械的实施敏捷开发。注意,敏捷开发认为人与人之间有效的交流和协作是最重要的,透过一切流程和工具看本质,实际上就是使人能够协作开发软件。敏捷开发随时拥抱变化、相应变化,而不是恪守计划。总之,敏捷开发的本质:第一是一切活动以价值为导向;第二是以人为本。

    展开全文
  • 严格地把软件项目开发分割成多个阶段:需求分析、要件定义、基本设计、详细设计、编码、单体测试、结合测试、系统测试等 强调文档,在开发后期才能看到软件的模样 瀑布式把所有开发人员定义为流水线上的工人,所有...

    瀑布式开发:

    严格地把软件项目开发分割成多个阶段:需求分析、要件定义、基本设计、详细设计、编码、单体测试、结合测试、系统测试等

    强调文档,在开发后期才能看到软件的模样

    瀑布式把所有开发人员定义为流水线上的工人,所有人都只能接触自己工作范围内的东西,所以对客户需求理解高低不一,这种情况下编码人员比设计人员对需求变更会有更大的抵触情绪

    严格的分阶段导致逆向的困难,也就是回头修改前期的错误要付出很大的代价,而它造成的影响也更大

     

    敏捷开发:

    核心是迭代

     

    可以工作的软件 胜过 精心设计面面俱到的软件

    客户合作 胜过  合同谈判

    响应变化 胜过  遵循计划

     

    简单设计,重复迭代

    客户最关心的功能优先完成

    根据客户对每次迭代成果的意见,进行下次迭代

     

    开发团队有两个队伍,业务团队和技术团队。所有开发人员对项目活动的理解应该是一致的,因此沟通是非常重要的,而沟通的平衡性也很重要,如果业务一方过于强势,在项目会议上就会不断要求功能和交付日,而忽略开发人员的完成的可能性和对需求的理解程度;如果开发人员控制了沟通,项目会议上技术术语会代替业务语言,而开发人员也很难真正了解客户的真实需求。因此项目经理的调节能力很关键。

     

    瀑布式项目管理是自上而下的命令式管理,敏捷式的管理是团队自我管理和项目经理服务式管理的结合

    展开全文
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...

    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体,也是一份契约。

    然而详细的需求说明书有以下5大弊端:

    • 单向的信息传递,容易出现理解偏差。
    • 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断。
    • 有了详细的文档,我们不会反复讨论它,相互确认。
    • 书面文档不利于团队共享责任,它扮演了证据的角色。Scrum强调团队共享责任,不论是需求人员、开发人员和还是测试员,大家的共同目标是通过讨论、协作,正确理解需求之后把这些需求变成客户真正需要的功能,而不是单向的任务传递。
    • 编制详细的、表达准确需求文档需要花费大量的时间,如果需求变化频繁,维护成本更高。

     敏捷使用产品Backlog来管理需求,产品Backlog是一个需求的清单,按照需求的商业价值排序, 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单,它有4个主要特点,称之为DEEP:

    • Detailed 合适的详细程度,高优先级需求更加明细,低优先级的需求粒度更大
    • Emergent 涌现式的,需求是慢慢涌现出来的,渐进明细的
    • Estimated 经过估算的
    • Prioritized/ Ordered 根据商业价值排好顺序的

    在产品Backlog中,需求的主要表现形式是用户故事。用户故事是从用户的角度对需求的简短描述。用户故事是将团队的焦点从描述、编写功能需求转移到讨论需求的最佳方式。

    用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

    • 角色:谁要使用这个功能。
    • 活动:需要完成什么样的功能。
    • 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

    用户故事通常按照如下的格式来表达:

    英文:
    As a <Role>, I want to <Activity>, so that <Business Value>.

    中文:
    作为一个<角色>, 我想要<活动>, 以便于<商业价值>。
    比如:作为一个网站的普通会员,我期望在我下订单后,未发货之前可以取消订单,这样对我来说更灵活。

     

    我们目前是用的国内的一款敏捷工具Leangoo在做需求管理!

    Leangoo是一个非常简洁的看板协作工具,我们可以通过Leangoo创建产品Backlog看板来管理敏捷需求。通过leangoo看板对产品backlog条目进行可视化管理,让整个团队非常直观的了解需求的优先级和规划安排。

    下图就是一个产品Backlog看板的示例:

    Leangoo看板上,我们可以创建多个列表,然后在每个列表上添加故事卡片。

    因为我们需要将近期高优先级的需求放到Sprint中,所以在看板上可以创建这几个列表:待整理原始需求,以后的迭代,下个迭代待梳理故事,下个迭代就绪故事,当前迭代,已交付。
    我们可以根据需求的优先级把需求分别放到这几个列中。当前迭代的优先级最高。

    建立好了列之后,我们就可以往列表里面增加卡片了,每个故事一张卡。

    我们可以为每一张卡片添加工作量,以及故事的验收测试要点。验收测试要点以检查项的方式体现。

    除了工作量,检查项,我们可以对这个故事进行一些讨论,也就是评论,也可以@某位成员!

    我们也可以为卡片设置标签

    标签通常是用来给卡片分类,也可以用卡片标注优先级!

    (每张卡片的优先级可以位置来决定的,每个list里面的卡片根据位置对卡片进行强制排序,高优先级的卡片放到最上面,低优先级的需求卡片在下面)

    卡片ID

    我们也可以为每一张卡片设置ID,便于卡片定位沟通和跟踪,在菜单栏开启就可以。

    卡片多选

    当我们开启卡片多选的时候  可以批量移动卡片,为卡片批量添加标签,为卡片批量添加成员等等 ,这也是我最爱的功能之一

    燃尽图

    当一个迭代结束时,我们要对完成的故事进行评审会议,评审通过的故事可以挪到已交付的列表中。

    Leangoo会根据故事卡的变化自动生成发布燃尽图,点击菜单-看板统计,就可以查看!不仅有燃尽图 还有任务周期,任务分布等

    如下图所示:

    通过上述的方式,我们就可以很好的管理我们的产品Backlog了。

    最后还有一点提醒,敏捷强调透明性,所以,可视化管理产品backlog很重要,如果条件允许,我们可以考虑通过大的显示屏幕将产品Backlog进行可视化,有触屏大电视会更好。

     

    转载于:https://www.cnblogs.com/shineshine/p/9505022.html

    展开全文
  • 软件工程-软件开发模型(瀑布/V/喷泉/原型/演化/螺旋/统一过程/敏捷) 瀑布模型 特性 文档为驱动 优点 容易管理 缺点 开发过程逆转代价大 ...现代客户难以明确需求,该模型...单元测试针对编码,以详细设计为依据...
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 敏捷 需求管理工具

    2018-08-20 12:38:00
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 他主要从事新兴技术的研究,研究方向包括数据库系统、版本系统、语义网和敏捷软件开发等。 目录 封面 -10 封底 468 扉页 -9 版权 -8 前言 -7 目录 -4 第一部分 MySQL开发入门 1 第1章 MySQL与开源运动 2 1.1 ...
  • 用Leangoo做敏捷需求管理

    千次阅读 2015-11-18 10:18:27
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 管理敏捷需求,进行需求协作

    千次阅读 2018-08-19 20:29:50
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 敏捷方法:总体目标是通过“尽可能早地,持续地有价值的软件的交付”使客服满意,敏捷过程的典型方法很多,主要有极限编程、水晶法、并列争球法、自适应软件开发几种。 需求分析: 概要设计的基本任务:...
  • 《iOS开发指南》(第二版 iOS7)源码

    千次下载 热门讨论 2014-03-20 11:11:59
     第24章介绍了完整的iOS应用分析设计、编程、测试和发布过程,其中采用了敏捷开发方法。此外,该项目采用分层架构设计,这对于学习iOS架构是非常重要的。  书中并没有包括多媒体等知识,我们会在另外一本介绍iOS...
  •  第24章介绍了完整的iOS应用分析设计、编程、测试和发布过程,其中采用了敏捷开发方法。此外,该项目采用分层架构设计,这对于学习iOS架构是非常重要的。  书中并没有包括多媒体等知识,我们会在另外一本介绍iOS...
  • 观点1:详细设计文档意义不大,代码就是最好的详细设计。 观点2:重构改善了既有代码的设计,颠覆了传统软件工程理论。 观点3:设计属于软件开发流程的一部分,必须随着程序的演化而演化。因此严格意义上的先设计...
  • 软件过程模型

    热门讨论 2018-10-31 11:11:27
    瀑布模型一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。 为软件开发和维护提供了一种有效的管理模式,根据这种模式制定开发...
  • 在软件整个生命周期中,测试应该尽早地开始,因为测试对象不只是程序,还有文档和数据,所以针对需求分析说明书、概要设计和详细设计说明书,测试如何快速理解项目需求,进行下一步的工作呢? 本人觉得,如果只是看...
  • 软件工程教程

    热门讨论 2012-07-06 23:10:29
    敏捷开发过程-Scrum 送餐管理系统--用例图 送餐管理系统--类图 送餐管理系统--顺序图 任务1 软件工程 软件的定义及其特点 软件危机 软件工程概念 软件的定义及其特点 软件的定义 软件是计算机系统中与硬件...
  • 程序流程图规范

    2021-01-12 17:58:08
    一个复杂的互联网应用,敏捷开发过程,业务系统从启动需求到研发实施,通常没有预留太多时间给测试去详细了解各个业务的具体规则、业务逻辑。产品经理仅提供文档资料,测试没有资料作为凭据,则可以使用流程图来梳理...
  • asp.net知识库

    2015-06-18 08:45:45
    Asp.Net(C#)利用XPath解析XML文档示例 XSL .Net框架下的XSLT转换技术简介 一个XSLT的简单例子 XSLXSLT板主题整理 xsl入门的好文章 新手学习XSL的好东西 XSL语法介绍 XSL学习心得 - 调用属性值 XSLT与XML转换的详细...
  • APIAuto 敏捷开发最强大易用的 HTTP 接口工具,机器学习零代码测试、生成代码与静态检查、生成文档与光标悬浮注释 UnitAuto 机器学习单元测试平台,零代码、全方位、自动化 测试 方法/函数 的正确性和可用性 apijson...
  • 20.2.3 面向敏捷开发团队的高效测试用例 294 20.2.4 持续集成和持续测试框架hudson 295 20.2.5 有效管理和跟踪测试任务 297 20.2.6 快速跟踪和解决缺陷 300 20.3 持续回顾和调整 304 20.4 小结:速度之美的真正含义 ...
  • 第6章 详细设计117 6.1 结构程序设计117 6.2 人机界面设计119 6.2.1 设计问题119 6.2.2 设计过程121 6.2.3 人机界面设计指南122 6.3 过程设计的工具124 6.3.1 程序流程图124 6.3.2 盒图125 6.3.3 PAD图126 6.3.4 ...
  • 说明:从项目上线到获得8w+星标以来,一直收到反馈说基础部分(前15天的内容)新手来说是比较困难的,建议有配套视频进行讲解。最近把基础部分的内容重新创建了一个名为“Python-Core-50-Courses”的项目,用更为...
  • 完成整个系统的可行性报告分析、需求分析说明书、开发计划说明说、系统设计书、项目测试、项目总结,概念模型、存储模式、完整性控制、存取权限等进行了定义,系统功能各模块进行了详细设计,定义了数据库总体...
  • Android 上百实例源码分析以及开源分析 集合打包4

    千次下载 热门讨论 2012-07-10 21:54:03
    3、jchat4android手机聊天程序 (内含开发文档) Android jChat 是一个 Android 手机上基于位置的聊天软件,采用P2P通讯机制。 为了编译jChat,你要使用Eclipse创建一个新的Android项目,然后添加外部JAR和移动的...
  • 这里我将推荐开发过程中的提效工具、开发利器、协作工具、文档技术等等。 XP 极限编程 敏捷软件开发中可能是最富有成效的几种方法学之一 技能图谱 backend skill 后台开发技能图谱,从程序员的内功修炼到后台...
  • EmEditor V12+注册码

    热门讨论 2013-01-22 11:53:13
    Windows系统自带的“记事本”的查找替换功能很弱,但EmEditor弥补了这一点,它支持的查找替换规则更加详细实用,查找出的结果可以突出显示,并可以批量查找替换未打开的TXT、HTML、DOC等格式的文件中的内容:选择...
  • MkDocs: Markdown 友好的文档生成器。 pdoc:一个可以替换 Epydoc 的库,可以自动生成 Python 库的 API 文档。 Pycco:文学编程(literate-programming)风格的文档生成器。 readthedocs:一个基于 Sphinx/...

空空如也

1 2
收藏数 30
精华内容 12
关键字:

敏捷开发对详细设计文档