敏捷开发 订阅
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 [1] 展开全文
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 [1]
信息
外文名
Agile Development
方    法
迭代、循序渐进
中文名
敏捷开发
核    心
用户的需求进化
敏捷开发原则
敏捷建模(AM)定义了一系列的核心原则和辅助原则,它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于XP的原则,我们可以从另一个角度来看待。◆主张简单当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建 (overbuild)你的软件。用AM的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气:你现在不必要对这个系统进行过分的建模(over-model),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。◆拥抱变化需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Project stakeholder的观点也可能变化,你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此你的开发方法必须要能够反映这种现实。◆你的第二个目标是可持续性即便你的团队已经把一个能够运转的系统交付给用户,你的项目也还可能是失败的--实现项目投资者的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。就像Alistair Cockburn常说的,当你在进行软件开发的竞赛时,你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。◆递增的变化和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型,你只要开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型,或是在不再需要的时候丢弃这个模型。这就是递增的思想。◆令投资最大化你的项目投资者为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资,也可以要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。如果是这些资源是你自己的,你希望你的资源被误用吗。◆有目的的建模对于自己的产出,例如模型、源代码、文档,很多开发人员不是担心它们是否够详细,就是担心它们是否太过详细,或担心它们是否足够正确。你不应该毫无意义的建模,应该先问问,为什么要建立这个产出,为谁建立它。和建模有关,也许你应该更多的了解软件的某个方面,也许为了保证项目的顺利进行,你需要和高级经理交流你的方法,也许你需要创建描述系统的文档,使其他人能够操作、维护、改进系统。如果你连为什么建模,为谁建模都不清楚,你又何必继续烦恼下去呢?首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。一旦一个模型实现了目标,你就可以结束工作,把精力转移到其它的工作上去,例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型:如果你要做一些改变,也许是一个熟知的模式,你应该有做出变化的正确理由(可能是为了支持一项新的需求,或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众,即便受众是你自己也一样。例如,如果你是为维护人员建立模型,他们到底需要些什么?是厚达500页的详细文档才够呢,还是10页的工作总览就够了?你不清楚?去和他们谈谈,找出你想要的。◆多种模型开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,“要开发现今的商业应 用,我们该需要什么样的模型?”考虑到现今的软件的复杂性,你的建模工具箱应该要包容大量有用的技术(关于产出的清单,可以参阅AM的建模工件)。有一点很重要,你没有必要为一个系统开发所有的模型,而应该针对系统的具体情况,挑选一部分的模型。不同的系统使用不同部分的模型。比如,和家里的修理工作一样,每种工作不是要求你用遍工具箱里的每一个工具,而是一次使用某一件工具。又比如,你可能会比较喜欢某些工具,同样,你可会偏爱某一种模型。有多少的建模工件可供使用呢,如果你想要了解这方面的更多细节,我在Be Realistic About the UML中列出了UML的相关部分,如果你希望做进一步的了解,可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。◆高质量的工作没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。◆快速反馈从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候,例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这样,你就提供了快速反馈的机会。◆软件是你的主要目标软件开发的主要目标是以有效的方式,制造出满足投资者需要的软件,而不是制造无关的文档,无关的用于管理的工件,甚至无关的模型。任何一项活动(activity ),如果不符合这项原则,不能有助于目标实现的,都应该受到审核,甚至取消。◆轻装前进你建立一个工件,然后决定要保留它,随着时间的流逝,这些工件都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。类似的,你的模型越复杂,越详细,发生的改变极可能就越难实现(每个模型都更“沉重”了些,因此维护的负担也就大了)。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间,团队和项目投资者之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠,他一定会携带地图,帽子,质地优良的鞋子,水壶。如果他带了几百加仑的水,能够想象的到的所有求生工具,一大堆有关沙漠的书籍,他还能过得去沙漠吗?同样的道理,一个开发团队决定要开发并维护一份详细的需求文档,一组详细的分析模型,再加上一组详细的架构模型,以及一组详细的设计模型,那他们很快就会发现,他们大部分的时间不是花在写源代码上,而是花在了更新文档上。最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单——尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。 [2] 
收起全文
精华内容
参与话题
问答
  • 什么是敏捷开发

    万次阅读 多人点赞 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 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...

    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • SCRUM敏捷开发视频教程

    万人学习 2015-08-20 14:22:02
    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 八分钟敏捷开发(scrum)扫盲

    万次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...

    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。

    敏捷开发的特点就是下面4句话:

    「个体与交互」胜过「过程与工具」

    「可以工作的软件」胜过「面面俱到的文挡」

    「客户协作」胜过「合同谈判」

    「响应变化」胜过「遵循计划」

    敏捷开发(scrum)适用于竞争激烈,快速变化的市场。 敏捷的客户协作观念,快速迭代能帮助团队以最小成本,最快速度满足客户真正的需求。对比传统开发模式:

    传统开发模式以文档为驱动,而敏捷开发提倡少写文档

    传统开发模式下开发人员按照产品文档进行研发,过程中客户不参与到产品的验收和体验中,这样就会导致最后开发出来的成品并不是客户想要的。 而敏捷开发模式从开始就强调客户协作,分步提供产品模块客户体验。

    敏捷模式采取迭代式开发,传统模式采用瀑布式开发

    敏捷开发采取迭代式开发的形式,即每个阶段有每个阶段需要完成、并且能使用的产品,这一阶段只要开发某几个功能,且这些功能的产品必须是可以使用的,这一阶段产品完成之后与客户进行对接交付,再进行下一阶段的开发。

    敏捷开发更适应变化

    传统开发模式下软件开发过程是执行研发计划,而实际工作中,需求往往在开发过程中会产生巨大变化。敏捷开发更能适应不确定性强的产品和市场。

    接下面我们来具体看一下执行scrum的套路。

    Scrum的三大角色

    产品负责人(Product Owner)

    主要负责和客户沟通确定产品的功能和达到要求的标准,并指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果,一般是由产品经理担任。

    流程管理员(Scrum Master)

    问题清道夫!主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    开发团队(Scrum Team)

    开发主力!主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;不论过程只问结果!只要能达到目标,不论任何工作时间、方式。

    Scrum的组成

    Sprint:指的是一次迭代,而一次迭代的周期最好是1-4个星期,也就是我们要把产品需求分布到各个周期完成,这个过程我们称它为Sprint。

    Story:用户故事,也可以看做是用户需求点。

    Task:story的进一步细分。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

    Backlog:Backlog是Scrum中的一个专用名词,意思是待办工作事项的集合。在开发中需要明确2个Backlog。

    Product Backlog ——产品待办事项列表,产品负责人量化用户需求,逐条列出实际需要开发的需求(Story)。

    Sprint Backlog——任务列表,是一次迭代中需要完成的任务,主要是开发团队细化工作的列表。

    燃尽图(Burn Down Chart)

    是一个展示开发时间的图,但是展示的是每天累加所有任务的剩余时间。

    燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉,最后烧完sprint也就完成了。用蓝色线表示计划走向,红色线则是实际走向,两条线共同组成了燃尽图。如下图,每一个点代表一个用户故事,或者故事点,或者可度量的工作量。所有点组成sprint。

    4个会议

    Sprint计划会

    Sprint 计划会就是大家坐下来,PO 向大家介绍排好序的产品待办事项(Product Backlog),然后大家共同思考决定如何推进计划,梳理出 Sprint Backlog 来完成后续的工作。

    每日站会

    每位开发成员都要交代3点

    昨天完成了什么

    今天计划完成什么

    是否有困难需要帮助

    每日站会

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的看板和燃尽图。

    Sprint 评审会

    当一个Sprint完成,这时就要进行最重要的演示会议,也称为评审会议,产品负责人和客户都要参加,每一个开发团队的成员都要演示自己完成的软件产品,然后被判定产品合格、成功、需要修改还是重新做。

    Sprint 总结会

    总结会议以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

    以上的会议都不需要准备PPT或者大量的文档,但要注意会议的时长。

    使用鱼骨Scrum项目的开发步骤

    1.产品负责人使用产品Tab收集产品需求(story)。

    Product Backlog

    2.开发团队根据Product Backlog列表,在Sprint计划会议中做工作量的预估和安排,确定需求提交研发,进入Story看板。

    Story看板

    3.确定Sprint周期(1-4周)和本次开发迭代冲刺的开发需求(Stories)。进入Sprint的story出现在Task看板。 在Task看板,研发团队可以拆分Story到任务进行协作。

    Task看板

    5.每日立会,团队更新Task看板,和Story看板,保持信息的同步。

    功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。

    展开全文
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:18:20
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

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

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

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

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

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

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷开发

    2019-06-30 16:39:26
    敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 一、迭代开发 ...
  • 什么是敏捷开发?它有什么特点

    千次阅读 2020-05-15 10:12:45
    随着软件开发技术的不断发展,现在出现了很多种不同的开发模式,其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案。那么什么是敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发...
  • 7种敏捷开发方法

    千次阅读 2019-04-28 00:09:42
    XP极限编程 SCRUM迭代增量化过程 Cystal Methods水晶方法族 FDD特性驱动开发 ASD自适应软件开发 DSDM动态系统开发方法 轻量型RHRUP
  • 在十年前,没有人会想到互联网会发展成今天这个样子,同样,也没有人料到软件开发行业也会经历如此大的巨变,在开发这一行业,停下学习就等于死亡并不是危言耸听,不关注行业未来发展趋势的人可能错过了第一个十年...
  • 敏捷开发简介

    2010-04-13 13:19:00
    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐,在全球一百强的企业中,敏捷也已大行其道,受到许多资深项目管理者和开发人员的推崇。欧美软件企业中,有近半企业已采用敏捷...
  • 敏捷开发流程

    千次阅读 2011-11-22 17:01:17
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 这是敏捷开发一千零一问系列的第十四篇。(在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有...
  • 敏捷个人和敏捷开发

    2018-07-15 10:19:21
    转载:https://yq.aliyun.com/articles/408737自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开 发的一种主流方法。没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来...
  • 敏捷过程(小规模团队敏捷开发

    千次阅读 2018-05-10 09:31:13
    敏捷开发的价值观 敏捷开发应遵循的12条原则 敏捷开发的原则 敏捷团队运作机制 关键的团队角色 产品负责人(Product Owner) Scrum Master(流程主管) 关键的团队活动 敏捷团队的五个约定 约定1. 业务分析师...
  • 嵌入式系统软件敏捷开发

    千次阅读 2012-09-17 20:32:59
    本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发、敏捷的时间安排,敏捷的通信交流方式等等。...
  • 敏捷开发核心思想

    万次阅读 2011-04-20 09:00:00
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 敏捷开发 vs 传统模式

    万次阅读 2015-05-28 22:40:58
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 如何理解敏捷开发

    2019-06-09 22:41:01
    什么是敏捷开发 2.0 常用的 4 种开发模式 瀑布式开发 迭代式开发 螺旋式开发 敏捷软件开发 4 种开发模式总结 什么是 DevOps 精益管理的7个原则 DevOps的开发流程 提交 编译 单元测试 部署到测试环境中 ...
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:09:25
    敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 敏捷开发的起源在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对其...
  • 敏捷开发实例

    2013-10-29 09:10:35
    敏捷开发实例 介绍如何成功地完成了一个大型的(超过十万行代码)、分布式的以 Scrum 模型开发的项目。
  • 2012-12-25:新增松结对编程4页。预告:下一更新日期:2013-03-01(实际未发布)。致歉:因误以为新版本发布是4.1日,所以错过了发布期。作为普及读物,已经达到70页的上一版本版本已经基本满足需求。...
  • 敏捷开发实战经验

    千次阅读 2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。...
  • 敏捷开发的流程

    千次阅读 2015-08-31 20:26:19
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...

空空如也

1 2 3 4 5 ... 20
收藏数 166,824
精华内容 66,729
关键字:

敏捷开发