敏捷开发模型_敏捷开发模型缺点 - CSDN
精华内容
参与话题
  • 什么是敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...

    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

    在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

    大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM 的工作流程

    学习 Scrum 之前,我们先要了解几个基本术语:

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。
    在这里插入图片描述
    如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

    当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

    那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
    在这里插入图片描述
    敏捷开发与 DevOps
    DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

    时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的...

    谈谈敏捷开发模型
    我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。

    但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是:

    1、项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发布各种测试版本。
    2、更充分与市场人员交流,在市场人员进行需求交底时,让更多的甚至全体成员参与会议,了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
    3、加强沟通力度,开发测试都在一起每天都会开个小会,通报每日的工作成果,将自己的问题说出来。
    4、不同以往的发布频率,测试从项目开始便要切入到产品生产过程,而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。

    在做这些工作的时候我并不知道敏捷开发这个东西,直到在2010年进入一个公司非常提倡敏捷开发,已经有了迭代周期、backlog、站立会议、周例会等等,在这个团队中对开发过程有各种规章要求,完全是制度化的,这在我加入的初期非常的不适应。事实上回头想想,那种方式已经变的不敏捷了,完全是一种教条式的应用。

    后来自己有机会回到了老东家,开始自己带团队,很巧老东家被收购后开始推广敏捷开发,只不过因为不是总部,所以这次没有范本,完全由我自己来组织及控制。很高兴这个小团队几个月下来,个人觉得比较成功,当然后面也得到了公司的认可。

    下面就敏捷开发分享一些应该着重注意的点,解决这些问题我想对任何开发团队都会有很大的帮助。

    需求在开发中的重要性

    大量的开发过程告诉我,需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析,这个过程对于一些正规的团队会产生大量的文档,而后交由开发展开产品生产。

    然而,事实却不是想象这么简单,无数的例子说明了一点,仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们,需求是会变的,变的原因很多。在极端的情况下,有些客户签字的需求在开发完后,有需要变更也很正常。

    所以需求是影响软件开发的第一重要因素,需求来源于业务,我们开发的产品不就是因为这些业务才去做的吗?如何需求都无法把握好,还谈什么开发出好用的产品?

    然而如何做好需求呢?我想首先要确立需求的地位,然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

    强调人与人的交流

    不管怎么样开发过程中主要还是靠人的,而且软件开发是个复杂的团体工程,一个小些的产品也会涉及到各类人:客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情,有一方没有处理好结果肯定就会有问题。

    有这样一个例子:客户提出了一个会员管理功能需求,需求人员了解后组织了解决方案,于是交付了开发实现。而经过二个月无尽的黑夜之后交付,需求一看有个模块做的有偏差,但是已经来不及修改了。交给客户看后,发现这不是他们要的会员管理功能相差较大,另外在功能开发的这一段时间,客户又有了新想法,要对原先需求做调整。

    这种例子可能大家经常经历吧?

    这种问题在敏捷开发方法中提出了解决方法,就是通过不断的交付可用的制品。看起来很抽象,其实很简单。同样是上面的例子:
    Ø 客户提出会员管理功能需求
    Ø 需求人员在了解需求后与开发负责人商量,确定一个快迭代的开发计划,每二周向客户演示一次,并将这个计划与客户确认
    Ø 确认后需求人员向全体成员讲解需求背景故事
    Ø 开发负责人组织并确定迭代计划内容,明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
    Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
    Ø 后面就是每二周向客户演示一次产品,并获得客户的反馈
    Ø 根据客户的反馈调整下个迭代计划,并继续下一个迭代
    Ø 直到产品交付

    通过上面的步骤,就不至于在开发完成后才知道用户的真实想法,因为很多用户对软件开发是没有概念的,他只知道自己有某种需求,但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型,这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内,这样一来可以大大的减少软件返工的情况,自然就不会拖延计划了。

    而这个过程中,需求已经完成了一个真正的过渡,不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的,在开发不断的交付制品时,需求也更加及时的了解到产品的进度,把握开发人员开发的功能是否符合需求。
    当然这并不是一个标准做法,不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去,及时的与客户沟通交流,了解到客户的真实想法。

    强调文档的作用

    我觉得很多对敏捷开发的一个误解就是不需要文档,敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中,特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理,最痛苦的是不好维护,文档需要随着变化而变化,比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性,太难了。特别是对于一些无法进行有效管理的开发团队就更加明显,经常是软件已经几个版本了,文档却是两年前的。

    但敏捷真的不需要文档吗?我想不是的,如何把文档做到好维护我想才是最重要的。文档到底指的指的什么?什么样的算文档?

    提出上面两个问题,我们先想想经常说的文档的作用是什么?不就是一个传播工具吗?可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题,比如wiki系统。维护一个wiki系统,可以随时写,随时维护,可以方便的查找。嗯,多方便。

    另外一个问题就是什么样的工作需要形成文档呢?

    记得在前一家公司,维护一个10多年的老系统修改一个公式计算的BUG,但是怎么也不知道这个复杂的公式是什么意思,问过了公司大部分的人也无人可解。这时想,如果当初有那么一份文档,谢天谢地。

    像这种关键的内容有份文档还是很重要的,否则随着时间推移,谁也不能保证能记得住当时为什么会这么干。

    记得多年前一次记笔记的经历,我看了一篇文章了解了DELPHI实现单实例模式的方法,这种方法很酷。于是整理成了笔记写在了wiki上,第二天就得到了回复,帮助到了别外产品开发组的同事。

    嗯,文档就是这样他具有传播性,你不可能跑去跟所有人说出你的想法,但是文档却更容易达成。他也有传承性,有些文档也许10多年后又起了重要作用。

    团队协作

    1、减少对开发人员的干扰

    曾经接手一个产品的开发,最初遇到一个很头痛的问题,原先写好的迭代计划,而且工作量也较大,大家都在忙着。即便在这样的状态下,客服人员却经常跑来找某个程序员A维护各种系统问题,程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力,而每天的这些问题又不得不解决,加之新版本又有很重的开发任务无法完成,最终导致整个开发计划变更。

    我无法再忍受,找到了需求及客服的负责人,沟通后发现这些问题很多都是重复性的,主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能,并交付给了客服人员,之后就没有再来找过这位程序员A。后续我又找到了客服负责人,要求不能直接找开发人员解决这类问题,并与负责人约定了处理过程。

    这是个例子,在实际情况中还有很多这种事情,甚至有很多开发人员要直接面对客户。我想对于职能型团队来说,开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

    大部分的人都不是超人,在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点,尽量让开发人员有比较好的工作进度环境,通过外界的方式来解决一些开发团队的干扰。

    我接触过的很多程序员都很反感这种干扰,虽然有些人在这种全面的工作强度下成长很快,但是并非所有人都适应,长期下来会有怨恨和不快,工作效率会下降。心情舒畅还是很重要的,记得有一次迭代总结时,有个程序员总结说:发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

    2、不要忽略测试人员在开发阶段的作用

    曾经多少次在项目发布前加班到深夜2点的情景还历历在目,那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了,产品却迟迟未集成完成,测试只能干等着上网聊QQ。就在下班前的一刻发布了,测试开始了紧张的测试,在屏幕闪动中,一个个的BUG提交,直到流程都无法都走不下去,测试无奈了。第二天就要发布,实施人员就等着制品第二天出差。只有不断的改,再发布,无尽的循环。直到大家都憔悴的看着老大,终于老大说:还剩下的这几个问题无关紧要,大家回去吧。

    几个月的开发过去后在总结会上,只能抱怨测试资源不足,时间太短,需求更改太多,需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

    上面的这个例子很多人应该经历过,真的测试只有最后一刻才能体现价值吗?我想不是的。

    在后面的项目中我总结了这个问题的,针对每个开发任务要求进行测试验证。而测试如何验证呢?他需要知道这个开发任务的需求是如何,提前做好测试计划及测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。

    另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交流,甚至有必要组成虚拟团队,位置调整到一起,这样可以及时快速的交流,参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度,反过来把握测试计划及测试内容。

    特别是测试从另一个角度来审视需求,这样也可以一定程度上发现或者改善需求上的不足。

    3、发挥团队人员的潜力

    敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

    之前在做一个新产品时,需要使用java,而我们团队是使用C#的,面临转型问题。而有一位同事很感兴趣,于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高,我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时,这位小伙已经成为了团队的大牛,大家有问题都找他解决。也正是因为这个过程,这位小伙被全面激活,也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

    所以充分发挥好每个人员的特点,让人能够在自己感兴趣的工作中,效果会很多。减少指派方式的任务的分配,充分发挥个人的主动性,这个团队精神面貌也会好很多。

    4、管理者不要离团队太远

    作为团队的Leader要参与到团队的工作中去,比如一个开发主管一定要写写代码,参与架构等对项目有关的事情,而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

    特别是有些开发主管在带队后离团队越来越远,有时对于开发进度不如意时就说:“这么个简单功能怎么会搞了这么久?”,其实每天都在加班的同事心里想着:“有本事你来?”,即使这个小组长有这个能力,但对于团队来说也不是一件好事,因为大家都抱有怨恨之心,还谈什么好好工作呢?这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因,并且自己要加入到解决问题的工作中去,而不是在边上抱怨别人。

    5、小组织不要搞太多的官

    中国几千年的文化,官本位一直影响着我们,大家都想坐在那指挥,自己啥事也不用干,想想都惬意。在我们这个行业是不是发现也很类似?大家都想着干几年当个小组长,然后升个部门经理,当上CTO迎娶白富美。

    团队的管理基本是事与人的管理,非常的伤脑和心。如果一个组织内,特别是小组织内“官”太多,协调就会非常的难,大家就会经常性的扯皮。

    结束

    与敏捷开发结缘也有几年,从开始的抵触到后面的认可经历了许多,这个过程并不是一蹴而就的,需要花时间花精力,特别是要去实践、总结。

    还有我觉得是不能太教条,很多事情都要有怀疑的心,然后去实践总结,找到合适自己团队的方式方法。

    展开全文
  • 敏捷开发模式

    千次阅读 2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。2、敏捷开发的流程(图为禅道...

    1、敏捷开发的概念

    从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。

    2、敏捷开发的流程

    (图为禅道敏捷开发流程管理)

    2.1 产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。(可以理解为需求或者要做的事情)

    2.2 召开产品迭代计划会议,确定哪些需求是需要在第一个迭代中完成的,评估迭代的时间(建议是2-4周),得到相应的迭代周期任务列表。ps:提前发布功能需求列表,会议提倡所有团队人员参与

    2.3 把迭代的功能需求写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把未完成、正在做、已完成的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )–>举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)–>绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个迭代就完成了)ps:在开发人员开始开发一个任务时,需要找来对应的测试人员讲解该任务功能,以便测试人员有一致的理解,并且一开始就进行测试用例、自动化系统测试脚本的开发(若需要自动化测试的话)。

    (上图为小编粗图)

    2.4 评审会议(演示会议)是在迭代完成时举行,要向客户演示自己完成的软件产品,并获得客户的反馈 。

    ps:很多用户对软件开发是没有概念的,他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型,这个过程用户才会逐步的对产品产生概念。

    2.5 最后是总结会议,以轮流发言方式进行,每个人都要发言,总结好的实践和教训,并落实到后续的开发中。不要流于形式。

    3、敏捷开发适用原则

    1、个人与互动:重于流程与工具

    ->强调人与人的沟通,所以尽可能要集中化办公。异地开发模式容易让人疲惫。

    ->个人技能要提高。尤其对于架构师要求要高。

    ->管理者要多参与项目有关的事情。

    ->减少对开发人员的干扰。

    2、可用的软件:重于详尽的文件

    ->强调文档的作用。必要的文件必须的。且文档要具有传承性。

    3、与客户合作:重于合约协商

    ->做好客户引导。客户都是想在尽可能短的时间内,交付尽可能多的功能。做好版本控制。

    4、回应变化:重于遵循计划

    ->无理变化,举棋不定的结果,并不是说都需要及时响应,会导致很多浪费。

    展开全文
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...

    一. 什么是敏捷开发

    1.1 敏捷开发的定义

    2001年,由Martin Fowler,Jim Highsmith等17位软件开发专家在美国犹他州召开了雪鸟会议,会议上正式提出了敏捷开发概念,并共同签署了敏捷宣言,敏捷联盟成立。
    敏捷开发不是具体的指导性方法,它是一种观点和价值观,敏捷开发提供了一种思维方法,但真正的敏捷开发并不告诉大家怎么做。

    敏捷开发以用户需求为核心,采用迭代循序渐进的方法进行软件开发。它强调适应性而非预测性,强调以人为中心,而不是以流程为中心。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果经过测试,都具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成。在此过程中,软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。开发宣言如下:

    • · 个体和交互胜过过程和工具。
    • · 可以工作的软件胜过面面俱到的文档。
    • · 客户合作胜过合同谈判。
    • · 响应变化胜过遵循计划。
      在这里插入图片描述

    1.2 敏捷开发的原则

    1. 通过早期和持续交付有价值的软件,实现客户满意度。
    2. 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 不断交付可用的软件,周期通常是几周,越短越好。
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
    6. 面对面交谈是最好的沟通方式。
    7. 可用性是衡量进度的主要指标。
    8. 提倡可持续的开发,保持稳定的进展速度。
    9. 不断关注技术是否优秀,设计是否良好。
    10. 简单性至关重要,尽最大可能减少不必要的工作。
    11. 最好的架构、要求和设计,来自团队内部自发的认识。
    12. 团队要定期反思如何更有效,并相应地进行调整。

    1.3 敏捷开发的特点

    敏捷开发用于软件开发工作时,主张最简单的解决方案就是最好的解决方案,其特点是:

    • 1.快速迭代

    采用复杂问题分解方法,对于小版本的需求、开发和测试更加简单快速。

    • 2.让测试人员和开发者参与需求讨论

    需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员开发者,这样可以更加轻松地定义可测试的需求,将需求分组并确定优先级。同时,该种方式也可充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。

    • 3.编写可测试的需求文档
      开始就要用“用户故事”(user story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早地提及技术实施方案,会降低对需求的注意力。

    • 4.多沟通,尽量减少文档

    任何项目中,沟通都是一个常见的问题。良好的沟通是敏捷开发的先决条件,强调高效沟通的重要性。团队要确保日常的交流,面对面沟通比邮件更有效。强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主体。

    • 5.响应变更胜过遵循计划

    在敏捷方法开发软件过程中,接收需求变更,预料系统需求的变更,并快速响应变更,设计系统使之适应变更。主动适应变化,而不是预测

    • 6.及早考虑测试

    及早考虑测试在敏捷开发中很重要。传统软件开发中,测试用例大多都是最后才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。若较早地开始编写测试用例,在需求完成时,可以接受的测试用例也基本同时完成。

    1.4 传统的开发模式和敏捷开发模式的对比

    • 在采用瀑布研发模式时:
      (1)以过程为中心,流水线工作方式
      (2)重视和强调过程文档,主要通过文档来进行沟通
      (3)线性模式,缺少迭代与反馈
      (3)用户直到产品发布才能看到是不是自己想要的,最终成品与需求的偏差率相对较大。
    • 在采用敏捷研发模式时
      (1)以人为中心,以客户需求为导向
      (2)强调软件,而不是文档,减少不必要的文档。
      (3)采用迭代方法
      (3)用户能持续看到阶段性可用的产品,并能及时提出改进反馈,最终成品与需求的偏差率相对较小。

    瀑布模型:
    在这里插入图片描述

    敏捷开发模型:
    在这里插入图片描述

    当前的软件研发所面临的环节是不断快速变化的动态环境,包括新的机遇和市场、不断变化的经济条件、出现的新的竞争产品和服务。软件几乎是所有业务运行中的一部分,所以非常重要的一点是新的软件要迅速开发出来以抓住新的机遇,应对竞争和压力。在这种背景下,研发者许多时候宁愿牺牲一些软件质量、降低某些需求来赢得快速软件的交付。

    传统软件研发建立在对需求描述,然后进行设计、构造,最后再进行测试的完整计划上的软件开发过程是不适应快速软件开发的。当需求发生改变,或者是当需求出现问题时,系统设计和实现不得不返工和重新进行测试。其结果是,传统的瀑布模型或基于描述的过程总是拖延,最后的软件交付给客户的时间远远晚于最初的规定。而敏捷软件开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。敏捷方法普遍依赖迭代方法来完成软件研发,其目标是减少开发过程中烦琐多余的部分,通过避免那些从长远看未必有用的工作和减少可能永远都不会被用到的文档的方法达到目的。

    1.5 敏捷开发的分类

    敏捷开发(Agile Development)本身是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,

    敏捷开发过程主要包括:SCRUM,Crystal,特征驱动软件开发(FDD),自适应软件开发(ASD)及极限编程(XP)等。
    (1)XP(极限编程eXtreme Programming,简称XP),是一个轻量级的、灵巧的软件开发方法,同时也是一个严谨和周密的方法。XP的基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从四方面入手进行改善,加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近似螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极交流、反馈以及其他一系列方法,开发者和客户都能够非常清楚开发的进度、变化、待解决的问题和潜在困难,等等,并根据实际情况及时地调整开发过程。XP无需开发人员在软件开发初期就制作出很多文档,以适应计划的不断改变。XP提倡测试先行,这是为了将后期出现bug的概率降到最低。XP将项目的所有参与者视为同一团队成员(开发人员、客户、测试人员等),并一起工作在开放场所中。
    **(2)SCRUM。SCRUM是一种迭代的增量化过程,**用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。该方法的核心是旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进。
    **(3)Crystal Methods(水晶方法族)。**它是一个系列,因为不同类型的项目需要不同的方法。虽然“水晶系列”不如XP有那样高的产出效率,但有不少开发者接受并遵循这一开发方法。
    **(4)FDD(Feature-Driven Development,特性驱动开发)。**这是一套针对中小型软件项目的开发模式。此外,FDD是一个模型驱动的快速迭代开发过程,它强调简化、实用、易于被开发团队接受,适用于需求经常变动的项目。
    (5)ASD(Adaptive Software Development,自适应软件开发)。ASD强调开发方法的适应性,这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法,它更侧重为ASD的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
    **(6)DSDM(动态系统开发方法)也是敏捷开发方法中的一种,**它倡导以业务为核心,快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国,由于其在各种规模的软件组织中的成功,它已成为应用最为广泛的快速应用开发方法。DSDM方法不但遵循了敏捷方法的原理,而且也适合那些相对成熟传统开发方法具有坚实基础的软件组织。
    **(7)轻量型RUP。RUP本质上是一个过程框架,**可以包容许多不同类型的过程,一些软件专家极力主张以敏捷方式来使用RUP,并认为如此推进敏捷方法,是因为开发者广泛把RUP当做面向对象开发方法的主流。
    敏捷方法将开发与测试过程融为一体。在敏捷方法中,测试以很多不同的方法扮演着同样的角色,而不同的测试种类扮演着不同的角色。大家知道,测试大体上可分为手工测试和自动化测试。根据敏捷原则,要确保能用自动化测试的事情绝不要用手工测试,同时要做到适于手工测试的内容绝不花高昂成本做自动化测试。另外,不因为某方面不能实现自动化测试而不去做测试。敏捷开发中,如何运用手工测试和自动化测试?如何设计测试用例?这些是敏捷测试面临的挑战。

    1.5 Scrum

    (1)敏捷软件开发是一种以用户的需求进化为核心、迭代、循序渐进的开发方法。
    (2)Scrum是一种迭代式增量软件开发模型,通常用于敏捷软件开发。
    (3)XP,又叫极限编程,也是一种敏捷软件开发的模型,它以代码为核心,且由4部分组成:交流、简化、反馈、勇气,我们常说的结对编程就是其中一种模式。

    在国内,我们听到最多的是Scrum,那是因为经过很多项目和团队的实践,证明了它有效、简单、持续交付的能力,所以很多初创型企业或小规模团队都比较青睐它。
    我们通过一段对话来了解一下Scrum模型中的角色投入程度。
    鸡跟猪说:“我们一起开一家餐馆吧。”
    猪问鸡道:“餐馆起什么名字呢?”
    鸡跟猪说:“就叫‘火腿与鸡蛋’吧。”
    猪跟鸡说:“谢谢!还是算了吧。我是全身心投入的,而你只是部分参与而已。”
    从上面“猪”和“鸡”的对话中我们不难看出,在Scrum中有以下两种角色:
    (1)内部角色(全身心投入的成员),如产品负责人、敏捷教练、研发团队。
    (2)外部角色(部分投入的成员),如用户、管理层、其他利益相关者。
    最后,我们通过一张图来快速了解一下Scrum中主要的角色、产物、会议和流程。
    在这里插入图片描述
    4个角色:
    Product Owner:PO,产品负责人,团队的掌舵人,引领团队朝着正确的方向前进。
    Scrum Master:SM,敏捷教练(这是我个人最喜欢的,也是认为最贴切的中文翻译)。
    Team:由开发和测试等相关人员组成的团队,每个迭代周期内所有任务的完成者。
    利益相关人:在敏捷里,利益相关人指的是被项目过程和最终产物所影响到的角色,比如管理者、客户和用户。
    5个产物:
    Product Backlog:产品清单。
    Sprint Goal:迭代目标,也叫冲刺目标。
    Sprint Backlog:迭代清单,也叫冲刺清单。
    Task List:任务列表。
    Increment Product:增量产品。
    4个会议:
    Planning Meeting:计划会议。
    Daily Scrum Meeting:每日站会,传说中的15分钟,“站”只是多种形式中效率最高的一种。
    Review Meeting:评审会议,也叫验收会议。
    Retrospective Meeting:反思会议。我认为,这是所有会议里最重要的一个,因为敏捷思想的核心就是持续改进,而持续改进来源于持续总结和反思。
    流程:
    (1)团队在产品负责人的主持下,通过计划会议、产品清单和冲刺目标产出冲刺清单。
    (2)团队在敏捷教练的指导下,通过冲刺清单、任务列表和每日站会,在一个迭代周期(图中是30天)内产出增量产品。
    (3)产品负责人和团队通过评审会议,验收每个迭代周期产出的增量产品。
    (4)敏捷教练和团队通过反思会议,反思每个迭代周期里做得好和做得不好的地方,持续总结和改进,以此来提高每个迭代周期的战斗力。

    最后附上一些相关的概念。
    User Story:用户故事,从用户的角度来描述用户渴望得到的功能。
    Task Board:任务墙,将Scrum过程中的各项事务放大并进行可视化展示的各种类型的载体。
    Burn Down Chart:燃尽图,在迭代周期内用于跟踪任务进度的可视化图形。

    任务墙:
    在这里插入图片描述
    燃尽图:
    在这里插入图片描述

    本节来源《软件测试进阶之路:测试路上你问我答》—何飞

    展开全文
  • 软件开发模式敏捷开发(scrum) 版权声明:本文为博主 android_Mr_夏 原创文章,未经博主允许不得转载。 https://blog.csdn.net/xiajun2356033/article/details/81513957 简介 这几年关于敏捷开发在互联网企业...
  • 敏捷开发模型

    2020-02-21 11:50:48
    Agile Unified Process Process of AUP Identifying requirements Deriving use cases to satisfy the requirements Allocating use cases to increments Carry out each increment 4.1) Use case modeling ...
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 软件开发模式敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    传统的开发模式敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • 敏捷开发的特点

    2020-09-06 21:03:01
    什么是敏捷开发 敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信,只要符合这两份文档的开发...
  • SCRUM(敏捷开发模式)演讲PPT,SCRUM(敏捷开发模式)演讲PPT
  • 一、敏捷开发/测试的特征  1. 敏捷开发提倡迭代式和增量式的开发模式,并强调测试在其中的重要性。  敏捷开发模式的三个特点:依赖客户的参与、测试驱动以及紧凑的迭代开发周期。  2. 敏捷测试是协同测试的一...
  • 敏捷开发模式下测试策略综述 2 过程管理角色 2 测试开发角色 2 持续交付 3 持续交付,是在产品开发过程……能够以较短地周期完成需求的小粒度频繁交付;频繁的交付周期【2~5周】带来了更迅速的对产品的反馈和改善...
  • 瀑布开发模式敏捷开发模式的区别和思考

    万次阅读 多人点赞 2017-04-12 14:18:54
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 敏捷开发模式下的BA岗

    千次阅读 2018-09-19 17:53:00
    敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • 常用的敏捷开发模式

    千次阅读 2015-09-15 15:05:28
    速度是企业竞争致胜的关键因素,软体专案... 这正是Agile Process (敏捷的软体开发流程)于近年来兴起的主要原因,本文将介绍数种广为接受的软体开发流程,及其在运用上的建议。 1 Agile Process -敏捷开发流程  几
  • 传统开发模型与敏捷开发模型的区别(!!!重点) 传统开发模型有: 瀑布模型, 螺旋模型, 增量迭代模型. 瀑布模型适合 "需求相对稳定或需求变更少"的项目 螺旋模型适合 "复杂度高, 风险大, 规模大"的项目 增量迭代模型...
  • 为什么互联网项目适用敏捷开发

    千次阅读 2020-05-09 22:12:18
    因为笔主经历过瀑布开发模式敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。 下面所以我们这边先来简单介绍下这两种模式: 瀑布开发模式: 瀑布开发模式是由W.W.Royce在1970年最初提出的...
  • 【转载】CMMI与敏捷开发模式比较

    千次阅读 2013-02-20 18:41:23
    CMMI与敏捷开发模式比较 四月 9, 2012 07:07 by FlySky 我曾经参与了一个新产品项目两个版本的开发,分别采用了CMMI与项目级敏捷方式,总结一下两种模式。 CMMI采用的是传统的瀑布模式开发,开发流程是...
  • 禅道的敏捷开发模式

    千次阅读 2017-05-25 09:20:06
    全面采用禅道的敏捷开发模式进行整个软件开发生命周期的管理,需求->设计->编码->测试->交付这四个阶段全部用禅道对应的功能进行规范化管理。岗位划分:1、项目经理2、技术经理3、测试经理4、高级程序员(一般担任...
  • 敏捷开发模式下的质量管理

    千次阅读 2016-11-04 16:56:56
    主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到...
1 2 3 4 5 ... 20
收藏数 84,982
精华内容 33,992
关键字:

敏捷开发模型