2014-11-30 15:33:17 u010191243 阅读数 1710
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师
    用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。
    从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触,理解的不好还请读者见谅。
    一、从技术角度看:传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档,导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化,甚至产品完成后早已和时代脱节,失去了其本应产生的作用。造成的后果很明了:用户不满意,而且耗资很大。
    而敏捷开发显得更为轻灵多变一些。首先,轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录;另外,对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
    二、从组织管理角度来看,1、我们传统的团队开发很可能存在以下现象。如:部门之间不协调,缺乏充分的沟通,人际交流成为一纸空谈;小组内各成员也常常是各自开发自己的部分,对项目整体或与自己相关的部分也不很了解;沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题,甚至引发矛盾。
     这些问题的根源就来自于缺乏相应的机制进行组织和交流,把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
     2、在项目把控上,传统的开发都是定义好的,根据计划把整体的任务都一次性定好,缺乏灵活性,难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题,使得在项目需求有较大变化时通过先急后缓的方式充分应对。
     3、在部门划分上,敏捷开发提倡按产品划分,而不是部门。把编码和测试人员绑定在一起,使整个开发的过程成为一个流畅的整体,避免了出现相互争资源;把单元测试放到每一个Sprint阶段之后进行,减轻了集成测试的压力,缓和了测试人员由于不理解需求,测试不彻底或描述不准确与程序员产生分歧。
    三、从学习角度看,我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划,在应对变化上要做到灵活,给自己预留足够的缓冲时间。
     做好人际交流,了解集体状况、优秀的或与自己紧密相关的个人的状况,这是自我调整的强有力参考。
     最后,要做好选择,找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上,我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
    
    
2010-03-08 23:22:00 sunny_8510 阅读数 214
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

      敏捷开发可以分为三个层次,理念,实践,应用。

      软件的价值,在于实现客户的需求,和客户合作可以更好的澄清需求,所以敏捷强调和客户合作,过度的和过早的设计很多情况下偏离了实际需求,所以敏捷更强调代码的交付,软件开发有很高的沟通成本,人们讨论分析的时间和编写代码时间大概是七比三,而人与人面对面的沟通是最有效的,所以敏捷强调沟通, 敏捷本身是一种轻量级的开发模式,注重逐步的演进和快速的反馈,根据反馈对过程和及其产生的结果进行修正。

      敏捷的核心理念为关注价值,激励团队,适应变化。通过和客户合作来明确需求,消除开发过程中的浪费,在开发过程中注重质量,开发进度紧张情况下主张通过需求精简来解决问题。团队管理上主张放松控制,任务非指派而由团队成员主动认领和完成。不提倡制定大而全的计划,主张细粒度制定近期计划,粗粒度制定远期计划,根据分层次的反馈对计划和经验进行调整和适应。

      敏捷实践上以迭代开发为核心,包括团队,交付件,技术实践,管理实践四大元素。 敏捷团队组成有PO(Product owner),scrum master, Team.PO对整个产品的投资价值负责,关注产品回报,Scrum master主要对团队的敏捷实践进行引导,推动问题解决,Team负责进行具体实现。敏捷交付件有产品Backlog,迭代Backlog,完成标准。产品backlog为需求清单,有PO进行维护。迭代backlog为任务清单,在迭代会议上根据产品backlog 输出,包括任务内容,责任人,任务状态。敏捷的实践可以分为技术实践和管理实践。技术实践有持续集成,TDD,重构,anatomy 系统解剖,结对编程等,管理实践有迭代会议,站立会议,回顾会议,状态墙,迭代验收等。迭代开发是在前期坚实的基础上小步快跑。前期的基础要坚实,需要CI,TDD等架构上的保证。敏捷虽然倡导简单设计,但也关注构架,并提倡通过不断的重构来优化构架。敏捷的管理实践的目的主要是团队激励和反馈,通过反馈来调整计划和经验。

      敏捷是在提倡一种更好的软件开发方式,其更符合规律,顺应自然。

    

 

    

 

2014-10-23 18:27:47 xmt1139057136 阅读数 2472
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

敏捷、敏捷开发这类词最近很火!敏捷开发,就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多的和敏捷相关的名词是:极限编程(XP)、结对编程、测试驱动开发(TDD)等。

敏捷建模(Agile Modeling,AM),的价值观包括了XP的四个价值观:沟通、简单、反馈、勇气。此外,还扩展了第五个价值观:谦逊。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。

SCRUM敏捷开发规则一栏,我们看看图表吧,下载下来看着更清楚!!!


原图下载地址:http://download.csdn.net/download/xmt1139057136/8074061

点击下载           推荐原图浏览

如有疑问,请加qq群:135430763 共同学习!

2020-01-19 13:27:18 wwd0501 阅读数 49
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

本文是 Quora 上的一篇回答,作者是一名前谷歌工程总监,他认为敏捷宣言从较高层次而言,与谷歌工程师对软件开发的看法是很接近的。但如果落实到细节,比如敏捷宣言背后的某些原则,其所代表的主张短迭代和低文档的 Scrum 流程,过于集中于短期思维,不适用于谷歌这样革命性的工程项目。

在 Quora 上有人提出了 " 为什么像谷歌这种公司的开发人员认为敏捷开发是无稽之谈?" 的问题,关于此,作为一名前谷歌工程总监,David Jeske 提供了一些个人见解,以下是 David Jeske 的回答。

对很多人来说,敏捷意味着很多事情。我认为敏捷宣言从较高层次而言,与谷歌工程师对软件开发的看法是很接近的。

  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划

然而,一旦把这些高层次的观点落实到细节,这些协定就开始褪色。敏捷有一些很好的想法,但它也存在一些问题元素,即过于集中在短期思维,对于像谷歌这样的公司进行革命性工程项目并不太适用。在不深入细节的情况下,让我们来看看敏捷宣言背后的原则

让我们从共通点谈起。谷歌的发展风格是敏捷宣言背后的原则中所提到的激励赋能个体的例证。在这些原则中,最符合硅谷风格,可能本身就是受到硅谷启发的几条原则包括:

  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 最好的架构、需求和设计出于自组织的团队。
  • 团队定期反思如何能提高成效,并依此调整自身的行为。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。

这些原则对于聪明的工程师来说几乎是常识。我认为,硅谷打造了一种以赋能和信任个人为中心的文化。

然而,这些原则的其他部分却并不符合谷歌的开发文化。而这些部分实质上造就了短期迭代的 Scrum 流程。它们似乎更适用于特定类型的开发,最显著的是面向咨询或合同的软件编程,在这种情况下,客户是组织的外部人员,因为他们为开发付费,所以客户占主导地位操纵局势,可以在任何时候改变主意:

  • 我们的首要任务是通过持续不断地及早交付有价值的软件来满足客户。
  • 在整个项目中,业务人员和开发人员必须每天一起工作。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面交谈。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程对变化进行掌控。
  • 频繁地交付可工作的软件,从几周到几个月不等,倾向于采取较短的周期。

这种短期规划、直接与客户接触和持续迭代的风格,非常适合具有简单核心和大量客户可见特性的软件,这些特性的可用性可以增量方式上升,不太适用于那些只有非常简单的用户接口和大量隐藏的内部复杂性软件,这些软件可能直到相当完整时才具有可用性,或实现客户无法想象的飞跃式解决方案。

像谷歌这样的公司一直在编写革命性软件,这些产品以前从未有人编写,在复杂的子组件编写完成之前,软件是无法工作的。这让我立刻想到了 Bigtable 和 Borg 项目。Bigtable 是一种广泛复制的分布式数据库设计,而 Borg 是最早出现的超大规模集群 / 云管理器之一。这种类型的颠覆性创新需要大量的预先设计时间,并且需要在超过一周的迭代中为编写组件而工作。由于项目的外部接口如此简单,以及内部复杂性如此之高,以至于许多工作对“客户”甚至无法可见的,因此没有办法编撰客户可见的相关用户故事。这种类型的软件需要 8-20 个月的时间向客户交付第一个工作版本。

像 Bigtable 和 Borg 这样的项目是反 scrum 的。它们代表了技术领导者非常长远的考虑。在单独一周的时间里,他们并没有做一些可以满足少量需求的事情,而是为集群软件开发方式的根本性转变打下了基础。这项投资不仅在谷歌获得了令人难以置信的回报,而且影响了整个行业。

其他行业也有类似的情况。从税务会计软件到电脑游戏,有些软件在部分完成后并不适宜交付给终端客户。

如果我被要求重写上面的敏捷原则,使之更符合谷歌风格的开发,它们可能会是下面这个样子:

  • 我们的首要任务是提高客户(和程序员)的生产力和对信息的访问。处理你能找到的最迫切、最常见的问题,并产生最大的网络影响。不要仅仅满足客户的要求,要去深入了解客户,并彻底改变他们的世界。
  • 开发人员应该创建一个谷歌设计文档(一个相当小型的,但是结构化的设计文档),对项目做出解释,这个项目希望实现什么目标,以及为什么不能用其他方法来完成目标。此文档应该分发给所有项目干系人,以便在项目开始之前获得早期反馈。书面记录是必不可少的,因为它确保对项目何时抵达成功以及如何达到目标有一个清晰和一致的理解。
  • 在项目的所有阶段,大型组件的关键设计元素应该在设计文档中得到简明的解释和记录。
  • 飞跃式创新。完成并部署一个飞跃式创新比追求完美更重要。不可能做到完美无暇。相反,要灵活,并计划在技术栈的每一层不断地重新创造和改造。
  • 在合理的情况下,尽可能快地交付工作软件,并非一味地追求尽快交付。在对外交付之前先在内部使用自己的产品。确保产品在交付前达到高质量标准。产品的质量比交付产品所花费的时间更重要。

虽然敏捷宣言从高层次而言有足够的灵活性,可以和以上这些原则配合应用,但是我认为这些重写的原则与主张短迭代和低文档的敏捷 /Scrum 流程还是有很大区别的,而这些主张短迭代的低文档敏捷 /Scrum 流程如今几乎已经成为敏捷开发的同义词。

文章来源:https://www.infoq.cn/article/6A-uiolKDFyNNQzze4gl

2017-04-05 19:32:58 u010958446 阅读数 380
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

认识敏捷开发


1,提要


软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加整个软件项目的风险。

如何在保证效率的基础上还能安计划、保证质量的完成软件项目?于是产生了软件开发的一些方法,这个方法不是指具体有编码阶段的各种设计模式和技巧,而是在整个软件开发策略层面的方法。

传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识。

2,常用的开发模式


  1. 传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到交付大概这样的流程,要求每一个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。下面就是典型的瀑布模型。
    这里写图片描述
  2. 原型模型, 原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。

  3. 螺旋模型,将瀑布模型和快速原型模型结合,并特别强调项目风险。通常分为四个阶段组成:制定计划、风险分析、实施工程和客户评估。一般第一个原型只是双方交流的参考,随着后面的版本完善,最终达到目标。比较适合大型项目。

  4. 新型的敏捷开发,即迭代式开发,不要求非常完美的需求分析、设计、文档,而是在最短时间内完成一个框架,然后不断迭代,不断测试,直至交付。

    但它并不是不需要文档,不需要从需求、设计、开发、测试这样一个过程,在每个迭代过程中仍然需要做这样的事情。

    但是敏捷开发更加注重人的因素,不像瀑布式开发那样,由专门的需求人员采集用户需求,由设计师完成设计文档。敏捷开发每个人都是需要了解项目的需求,并不断的进行小会议,不断的测试修改,直到提交。

    敏捷开发则是以测试驱动开发,而瀑布式开发是以文档驱动开发。

下图是Scrum(敏捷开发的一种)敏捷开发模式

3,传统开发模式和敏捷开发的优缺点


主要对比比较常用的瀑布模型和敏捷开发。

瀑布式开发:

  1. 讲求阶段明确,严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。 软件生命周期前期造成的Bug的影响比后期的大的多。

  2. 特别强调文档,在开发的后期才会看到软件的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

  3. 流水式的开发,瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等。对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。当然好的方面就是按一定规范开发,如果有人员流失,短时间内可以补上去,除了核心的东西有文档参考外,开发过程本身就是在一定框架内的。

  4. 进度一目了解,瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。

敏捷开发

  1. 唯快不破,敏捷即是快之意,不仅思维快节奏,而且行为也是快节奏,因上受到当今快节奏社会的喜爱。

  2. 以人为本,和瀑布开发对应的文档为主来说,在敏捷开发中更强调人,在细节开发上个人可以发挥主观性,使用自己善长的技术和模式开发,而非机器式的开发,容易激发团队成员兴趣和创造力。除了项目参与者,人的因素中更考虑到与客户的沟通。每个成员都需要从沟通中,会议交流中,不断实现迭代。

  3. 结果第一,不强调文档,突破束缚,软件的最终结果才是重点,文档等都是为软件开发本身服务的,完成了一个优秀的、质量可靠的软件才是敏捷开发的重中之重。

  4. 迭代开发,迭代是敏捷开发的核心,不断迭代测试的过程,实际上就是精益求精的过程,正和现在这个社会的工匠精神相吻合。

  5. 整合不易,快速迭代,就需要分割整体业务,对于复杂的客户需求,如何兼顾分割与整体,并不容易,这个需要在项目设计之初考虑到。

4,敏捷开发管理方法


敏捷开发的管理方法有很多种,比较广泛应用的有XP、Scrum等。既然都是敏捷开发,他们都有共同点,强调高速响应变更、以人为主重视团队成员自身发展,倾向采用迭代式的软件开发生命周期模型。

敏捷开发中,XP和Scrum的区别:
1. 迭代周期不同,XP的每个Sprint(冲阶)的长度大概为1~2周,而Scrum为2~4周。

  1. 迭代周期内专一性不同,XP在一个迭代中,如一个User Story(用户素材,也就是一个用户需求)还未实现,可以考虑另外需求替换,原则是时间当量相等。而Scrum不允许这样,一旦迭代开发会毕,任何需求不允添加进入,并有Master严格把关,使团队不受干扰。

  2. User Story优先级机制不同,XP必须遵守优先级(当然需要先确实优先级),Scrum更灵活,可以不遵循优先级。比如依赖关系中,虽然 US-A高于US-B,但由于要完成A需依赖B,则需要先开发B。

  3. 实施中是否采用工程方法问题两者做法不同,Scrum这点上没有工程实践处方,体现的是以人为本,自我创造;而XP必须严格按TDD,自动测试,结对编程,简单设计,重构等约束团队,似乎看起来XP的方式束缚了团队,但需要看这个约束的程度,过细则会让人感觉与“以人为本,自我创新”思想不符,但优点就是一定程度上的规范更有利于保证软件质量。
    一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, …等等”

通过区别,看出: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

5,总结


通过了解传统瀑布开发模式和新型敏捷开发模式的差异,理解敏捷开发的在现在快节奏时代有更好的适用性:唯快不破,以人为本。

相信每个软件从业者心中都向往着开放、包容的环境中开展工作,并不是我们要求高,而是我们不喜欢被束缚,不喜欢做一个机器式开发者,我们需要的是尊重和创造。那么来学习敏捷开发吧!

[参考](http://www.cnblogs.com/yubinfeng/p/6594456.html

敏捷开发与层展论

阅读数 785

没有更多推荐了,返回首页