敏捷开发

什么是敏捷开发

敏捷开发是全球主流的软件开发模式,敏捷的开发方法并非凭空产生,它其实是软件工程数十年发展的一个重要阶段。这种方法被企业广泛采用,并且产生了十分深远的影响。

敏捷开发(英语:Agile software development),又称敏捷软件开发,并非近几年才兴起的一种软件开发方法,而是一种从上世纪九十年代就开始逐渐引起广泛关注的软件开发方法,它是一种应对快速变化的需求的一种软件开发能力。敏捷开发的核心理念,相对于「非敏捷」,更强调程序员团队与业务专家之间的紧密协作,面对面的沟通(这被认为比书面的文档更有效),并且频繁交付新的软件版本,适用于紧凑而自我组织型的团队,敏捷开发能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

敏捷开发是一种对开发过程控制的方法论, 也就是说,它是一种开发的方法:

1. 敏捷开发,更适用于软件,因为软件可以不断迭代,不断修改。硬件改起来就没那么方便了。

2. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。因此,针对市场竞争的情况而快速迭代产品, 才能使产品变得更加有竞争力。

3. 敏捷开发适用于快速变化的市场。市场变化快, 也就意味着产品功能变化可能会需要非常快,就像你在埋头造一辆汽车的时候,市场需求已经变成了开飞机满天飞了,这就要求你能一步步的把汽车改成飞机,还能按时交付。

4. 它适用于客户不知道自己要什么的情况。事实上,大部分的乙方面对甲方都会是这种情况,因为客户并不知道自己需要什么, 有可能做出来的产品不能一次使客户满意,便需要和客户沟通,合作,倾听反馈,持续改进。

5. 敏捷开发适用于在一个地方办公的小团队,通常10个人以内。这样能使敏捷中主要的沟通方式「Face to Face」 变成可行的。同时才能保证产品迭代小步前进,快速发布。

Teambition 是高效的敏捷开发项目管理工具:

1. 在 Teambition 里,同时管理多个迭代版本或者冲刺计划,可以将它们分别设置为任务分组,比如 [Feature 4.7],[Feature 4.8],并标注相应的上线时间。这样,既可以回顾历史版本,也可以快速切换正在开发和即将开发的版本。

2. 高效沟通与会议,可以在 Teambition 创建日程,为每个工作日早晨设置站会。

3. 打开任务板 ,员工就可以对照任务板总结这三个问题:

1) 昨天我完成了什么?

2) 今天我要做什么?

3) 在开发过程中遇到了什么阻力?

方便总结经验并且理清一天的工作头绪。

敏捷开发演变过程:

瀑布式开发 –> 敏捷开发

瀑布式开发 vs. 敏捷开发

瀑布式开发

瀑布式开发模型把大型软件开发分为:分析与编程,象工厂流水线一样把软件开发过程分成各种工序,并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路,所以成为软件开发企业使用最多的开发模型。

瀑布模型的特点:

瀑布模型更加强调文档,前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好  象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。

瀑布式开发从项目开始到项目结束,没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。

瀑布式开发的方法基于客户能够在需求阶段就给出完整、准确的需求的假设,所以期望于在项目初期获得详细的需求,然后严格控制需求变更,最终完成符合需求的软件。但现实式大部分需求是“涌现”出来的,也就是说是随着开发的不断进展而不断发现出来的,而无法在项目初期就明确的定义它,也就是说传统开发方法的基本假设是错误的,这一新的假设导致了敏捷方法的一系列实践。

敏捷开发的特点:

迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。

开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

常见的敏捷开发方法:

敏捷开发并非一种方法论,而是一种思想。目前应用较多的,主要有7中敏捷开发方法:

SCRUM

SCRUM是一种迭代的增量化过程,用于产品开发或工作管理。目前是敏捷开发最主流的开发方法之一。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

该方法由Ken Schwaber和 Jeff Sutherland 提出,旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进。

XP

XP(极限编程)的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计画永远赶不上变化,XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行,为了将以后出现bug的几率降到最低。

Crystal Methods

Crystal方法是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列,其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程,它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

FDD

FDD (Feature-Driven Development,特性驱动开发)是一套针对中小型软件开发项目的开发模式。此外,FDD是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、 易于被开发团队接受,适用于需求经常变动的项目。

ASD

ASD(Adaptive Software Development,自适应软件开发)强调开发方法的适应性(Adaptive),这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法,它更侧重为ASD的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

DSDM

DSDM(动态系统开发方法)倡导以业务为核心,快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国,由于DSDM在各种规模的软件组织中的成功,它已成为应用最为广泛的快速应用开发方法。DSDM不但遵循了敏捷方法的原理,而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

轻量型RUP

RUP其实是个过程的框架,它可以包容许多不同类型的过程, Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法,只不过是在接受能被视为RUP 的主流OO开发方法而已。

Scrum

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程,是一种敏捷的开发方法。原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前,都将有一个计画安排的过程,但冲刺开始后则由队员在原计画的基础上随机应发。

Scrum与敏捷开发

Scrum 是实现敏捷的一个最流行的方法之一,不过很多人会将 Scrum 和敏捷 混为一谈(事实上并不是。)实现敏捷有很多种方法,比如 Kanban 方法等。但是比起其他的方法,Scrum 还是独具一格,主要原因在于Scrum 短迭代周期的特性。

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个 Sprint ,每个 Sprint 的建议长度是2到4周(互联网产品研发可以使用1周的 Sprint )。满足用户不断变化的需求是软件开发的长期无法解决的难题之一,敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。

agile scrum 架构

Scrum中的角色

Scrum中有3种角色:

Product Owner(产品负责人)

  • 产品负责人可被认为是客户的代表
  • 产品负责人定义产品功能
  • 产品负责人决定交付日期和内容
  • 产品负责人按照市场情况为功能排优先级
  • 产品负责人最终负责产品的获利
  • 产品负责人可以接受或者拒绝开发团队的工作成果

Scrum Master(流程管理员)

  • 流程管理员领导开发团队,是开发团队的教练
  • 流程管理员确保Scrum流程的价值
  • 流程管理员确保团队高产
  • 流程管理员组建团队
  • 流程管理员为团队应用敏捷相关原理和方法,使系统高效运作

Scrum Team(开发团队)

  • 5-9 人的团队。
  • 有较强的自我组织性和纪律性。
  • 协同工作并且分担责任,共同完成产品。
  • 每个人充当一种或者多种角色(开发, 测试等)

scrum 角色

Scrum开发流程 :

scrum 活动

Sprint Planning (规划迭代)

目的:使团队计画和同意backlog上的项目,确认他们是否可以完成每个人的任务以及完成任务所需要的支持。

项目:

  • 定义需要做哪些事情
  • 确定如何实现目标

涉及参与方:

  • 产品负责人
  • 流程管理员
  • 开发团队

时间:

如果一个Sprint周期为2周,则大约需要4小时,在Srpint开始时进行

Daily Scrum Meeting(每日站会)

scrum每日站会

目的:团队计画好每日的工作,确保sprint目标能够按时完成

项目:

  • 昨天完成了什么
  • 几天计画做什么
  • 在遇到了什么困难,是否需要协助

涉及参与方:

  • 流程管理员
  • 开发团队

 

时间:

每天早晨15分钟,贯穿整个sprint

Sprint Review(迭代评审)

目的:总结整个开发过程,每个产品功能的评审

项目:

  • 开发团队介绍所有已经完成的功能
  • 产品负责人 记录新增需求或者更新 在产品backlog中
  • 产品负责人最终决定着某项功能是否接受或者拒绝

涉及参与方:

  • 产品负责人
  • 流程管理员
  • 开发团队
  • 相关业务方(如果有)

时间:

Spring发布的前一天,一般2小时左右

Sprint Retrospect Meeting(评审回顾会议)

评审回顾会议

目的:

Sprint经验总结,哪里需要改进,哪里完成的比较好,在日后的工作中使效率提升。

项目:

  • 回顾整个开发工作
  • 总结经验,包括做的不足的地方,完成的好的地方,以及团队成员之间相互合作

涉及参与方:

  • 产品负责人
  • 流程管理员
  • 开发团队

时间:

  • Springs之间,一般1-3小时左右

Product Backlog Refinement(调整产品Backlog)

目的:

确定产品backlog上的项目,为下一轮Sprint做准备。

项目:

1)产品负责人向开发团队以及流程管理员解释清楚产品Backlog上的项目

2)产品负责人调整产品backlog上的项目

3)开发团队理解产品Backlog上的项目,并且帮助产品负责人排优先级

涉及参与方:

  • 产品负责人
  • 流程管理员
  • 开发团队

时间:

  • Sprints之间,一般1-3小时左右

Teambition 是一款支持任何敏捷研究方法的项目管理工具,适用于Scrum、Kanban,以及您特有的研究方法。从敏捷白板到报告,您可以使用 Teambition 软件计划、追踪和管理所有敏捷软件开发项目。请选择以下框架,进一步了解 Teambition 将如何帮助您的团队更迅速地发布更高质量的软件。

您可能也感兴趣:

敏捷开发:故事板,看板
国内外CDN大全
使用Teambition进行销售管理
swift重载操作符实现一个字典添加到另一个字典中
[netCore]SQL Server on Linux and netCore2.0 开发初体验
SCRUM的五个活动
敏捷开发之API管理之道
如何打造学习型团队
站着开会效率就会好…吗_
免费项目管理