2017-04-06 09:06:53 huver2007 阅读数 622
  • SCRUM敏捷开发视频教程

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

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

从敏捷开发说起

“敏捷”概念最先是从软件开发领域引入的。传统的软件开发采用的是瀑布式开发的流程,把整个开发过程分成了需求、设计、编码、测试、发布等阶段,前面阶段达成后再进入下一个阶段,整个过程按照事先制定的计划前进。

但问题在于瀑布式开发这种预定义计划的方法,每个阶段之间都有强烈的依赖关系,前一个阶段被视为后一个阶段的输入,如果输入质量不高,便会严重影响后续阶段的输出质量。同时,如果前一个阶段未能达到标准,也会造成后续阶段的停滞,导致开发周期拉长。并且,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。

有数据显示绝大部分采用瀑布式开发方法的软件开发项目均延期,甚至失败告终。原因在于,市场的需求瞬息万变,很难实现产品需求的明确且完整地收集;同时,技术的发展也日新月异,对于所定义功能的可实现性也面临着多重不确定性的因素。所以当需求收集和产品定义工作无法得到很好地完成,瀑布式开发方法自然无法摆脱高失败率的命运。

所以从需求的明确性和工程实现的确定性两个纬度出发,当需求的不明确性和工程实现的不确定性均超出一定范围之后,呈现出复杂系统(Complex System)的特征,瀑布式开发这种结构化的开发方法便不再实用。而敏捷开发方法便是在这样的背景下诞生。

敏捷开发的一个核心思想的转换是:从瀑布式开发所代表的“Fix Feature, Flex time”(固定范围,弹性时间)转向“Fixtime, Flex Feature”(固定时间,弹性范围)。

在市场变化和技术变化的背景之下,既然市场需求和产品定义所代表的“范围”无法实现固化,因而无法确定应该投入多少资源来完成,那不妨固定好已有资源的,以资源为约束,实现“范围”的最大化实现。因此从“计划驱动”转向为“价值驱动”。

在敏捷开发的思维模式提出后,2001年,一方面诞生了 “敏捷宣言”, 充分发挥“人”在软件开发过程中的价值。

同时在敏捷宣言的指引之下也产生了多种多样的敏捷开发方法,如冲刺和迭代式的“Scrum”方法,更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。

对比瀑布式开发所代表的预定义计划的工程方法,敏捷开发方法通过测试驱动/价值驱动的手段,更加贴近最终的应用环境,于是也具备了更好的适应性。同时在敏捷宣言指引下,更强调发挥人的价值,可以更好地挖掘出团队的潜能。

2017-03-24 10:08:51 u012562943 阅读数 1151
  • SCRUM敏捷开发视频教程

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

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

1,提要
软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加整个软件项目的风险。
如何在保证效率的基础上还能安计划、保证质量的完成软件项目?于是产生了软件开发的一些方法,这个方法不是指具体有编码阶段的各种设计模式和技巧,而是在整个软件开发策略层面的方法。
传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识。
2,常用的开发模式
(1)传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到交付大概这样的流程,要求每一个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。下面就是典型的瀑布模型。


认识敏捷开发
(3)原型模型,原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。
(3)螺旋模型,将瀑布模型和快速原型模型结合,并特别强调项目风险。通常分为四个阶段组成:制定计划、风险分析、实施工程和客户评估。一般第一个原型只是双方交流的参考,随着后面的版本完善,最终达到目标。比较适合大型项目。
(2)新型的敏捷开发,即迭代式开发,不要求非常完美的需求分析、设计、文档,而是在最短时间内完成一个框架,然后不断迭代,不断测试,直至交付。
但它并不是不需要文档,不需要从需求、设计、开发、测试这样一个过程,在每个迭代过程中仍然需要做这样的事情。
但是敏捷开发更加注重人的因素,不像瀑布式开发那样,由专门的需求人员采集用户需求,由设计师完成设计文档。敏捷开发每个人都是需要了解项目的需求,并不断的进行小会议,不断的测试修改,直到提交。
敏捷开发则是以测试驱动开发,而瀑布式开发是以文档驱动开发。
下图是Scrum(敏捷开发的一种)敏捷开发模式


认识敏捷开发
3,传统开发模式和敏捷开发的优缺点
主要对比比较常用的瀑布模型和敏捷开发。
(1)瀑布式开发:
a.讲求阶段明确,严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。 软件生命周期前期造成的Bug的影响比后期的大的多。
b.特别强调文档,在开发的后期才会看到软件的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。
c.流水式的开发,瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等。对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。当然好的方面就是按一定规范开发,如果有人员流失,短时间内可以补上去,除了核心的东西有文档参考外,开发过程本身就是在一定框架内的。
d.进度一目了解,瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。
(2)敏捷开发
a.唯快不破,敏捷即是快之意,不仅思维快节奏,而且行为也是快节奏,因上受到当今快节奏社会的喜爱。
b.以人为本,和瀑布开发对应的文档为主来说,在敏捷开发中更强调人,在细节开发上个人可以发挥主观性,使用自己善长的技术和模式开发,而非机器式的开发,容易激发团队成员兴趣和创造力。除了项目参与者,人的因素中更考虑到与客户的沟通。每个成员都需要从沟通中,会议交流中,不断实现迭代。
c.结果第一,不强调文档,突破束缚,软件的最终结果才是重点,文档等都是为软件开发本身服务的,完成了一个优秀的、质量可靠的软件才是敏捷开发的重中之重。
d.迭代开发,迭代是敏捷开发的核心,不断迭代测试的过程,实际上就是精益求精的过程,正和现在这个社会的工匠精神相吻合。
e.整合不易,快速迭代,就需要分割整体业务,对于复杂的客户需求,如何兼顾分割与整体,并不容易,这个需要在项目设计之初考虑到。
4,敏捷开发管理方法
敏捷开发的管理方法有很多种,比较广泛应用的有XP、Scrum等。既然都是敏捷开发,他们都有共同点,强调高速响应变更、以人为主重视团队成员自身发展,倾向采用迭代式的软件开发生命周期模型。
敏捷开发中,XP和Scrum的区别:
a.迭代周期不同,XP的每个Sprint(冲阶)的长度大概为1~2周,而Scrum为2~4周。
b.迭代周期内专一性不同,XP在一个迭代中,如一个User Story(用户素材,也就是一个用户需求)还未实现,可以考虑另外需求替换,原则是时间当量相等。而Scrum不允许这样,一旦迭代开发会毕,任何需求不允添加进入,并有Master严格把关,使团队不受干扰。
c.User Story优先级机制不同,XP必须遵守优先级(当然需要先确实优先级),Scrum更灵活,可以不遵循优先级。比如依赖关系中,虽然 US-A高于US-B,但由于要完成A需依赖B,则需要先开发B。
d.实施中是否采用工程方法问题两者做法不同,Scrum这点上没有工程实践处方,体现的是以人为本,自我创造;而XP必须严格按TDD,自动测试,结对编程,简单设计,重构等约束团队,似乎看起来XP的方式束缚了团队,但需要看这个约束的程度,过细则会让人感觉与“以人为本,自我创新”思想不符,但优点就是一定程度上的规范更有利于保证软件质量。
一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”
通过区别,看出: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束
5,总结
通过了解传统瀑布开发模式和新型敏捷开发模式的差异,理解敏捷开发的在现在快节奏时代有更好的适用性:唯快不破,以人为本。

2012-08-16 09:01:15 nabila 阅读数 820
  • SCRUM敏捷开发视频教程

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

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

敏捷开发确实是一个非常不错的开发模式,但是它有太多难以实现的地方。首先就是对开发人员的要求太高。几乎要求每个项目的开发人员都要了解项目架构,熟知各种设计模式原则,有丰富编码经验。这一点很难做到。

对于我这菜鸟来说,看敏捷开发最大的收获就是知道了软件是怎样腐化的,在这里面我看到了自己前一段时间编程的影子。原来虽然知道自己写的代码质量是不高的,但是并不能从客观上把握到底哪里写的不符合标准,这本书里详细介绍了软件腐化的过程和特点。我们为什么说有部分代码的软件质量是不高的呢?虽然好像看起来实现了现在的功能,但是这不部分代码不能应对迎面而来的需求变更。需求变更是一个项目里永恒不变的,编写的代码要有适应性和便于修改性。这就是高手和新手之间的区别。我们要致力于写出便于理解,便于修改的代码。

软件会腐化的特征主要包括:僵化性:设计难以改变,脆弱性:设计易于遭受破坏,顽固性:设计难以重用,粘滞性:难以做正确的事情,不必要的复杂性:过分设计,不必要的重复:滥用鼠标进行复制、粘贴,晦涩性:混乱的表达。要在写代码的时候时刻关注自己的代码是不是脱离了这些腐化性,时刻保持代码的高质量。

我们采用什么样的办法能够保证代码保持干净整洁的设计,而且是高质量的呢?编写的代码要符合以下这些原则:单一职责原则SRP, 开发封闭原则OCP,里氏替换原则LSP,依赖倒置原则DIP——高层模块不应该依赖于低层模块。二者都应该依赖于抽象,抽象不应该依赖于细节。细节应该依赖于抽象,接口隔离原则ISP——不应该强迫客户程序依赖并未使用的方法。当然编码中还有很多编程细节需要去注意,这些原则是基本必须要遵守的。但是我们使用设计的目的是为了让代码更加易读便于理解,更加便于扩展,切记为了设计而设计。

 

2013-07-08 11:28:21 wuxing429 阅读数 16
  • SCRUM敏捷开发视频教程

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

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

刚才在ibm上面看了一个关于敏捷开发中代码的高质量的文档,感觉总结的很好,在文档中也用到了很多工具来保证代码的质量,在这里mark下

首先上总体图:

 图 1. 敏捷开发中的 Java 代码质量保证步骤

步骤一:统一编码规范、代码样式

  • 一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。
  • 命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
  • 文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。
  • 编程规范。例如异常、并发、多线程等方面的处理方式。
  • 其他规范。例如日志格式、属性文件格式,返回值和消息格式。

一旦编码规范确定,就可以利用 Eclipse 自身提供的功能来控制代码样式和格式。具体做法是,点击 Eclipse 的 Windows -> Preference 菜单项,在打开的 Preferences 对话框的左侧栏中找到 Java 节点下的子项 Code Style(如图 2),该项和它的子项允许您对 Java 代码的样式进行控制。

 

步骤二:静态代码分析

现在的静态分析工具很多,有 FindBugs、PMD、IBM Rational Tool,等等

例如findbugs,检查完毕后,会出现 FindBugs 视图,把所有检查的结果根据错误分组展示。点击结果里面的每一个错误,会自动打开对应的代码。当根据规则改正了所有的错误,或者说潜在错误,这些代码也就 通过了静态代码检查。FindBugs 的检查结果可以是 XML 文件,也可以是文本文件,便于项目的集成管理和检查保存。

 

 

步骤三:单元测试

 

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要 具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测 试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹 配方法来衡量用例设计的完整性。

在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补 缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码 逻辑结构为前提,如果评审员来自相关模块,还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化, 或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟 对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面 向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试。

模拟技术有很多种,如 jMock,EasyMock,Mockito,PowerMock 等等。其中 Mockito 消除了对期望行为的需求,避免了这些代码的大量初始化

 

测试覆盖率分析

 EMMA 是一款比较流行的开源 Java 测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采用多种颜色来高亮显 示不同的覆盖率状态。EclEmma 是一款基于 EMMA 的 Eclipse 插件,方便在 Eclipse IDE 中进行测试覆盖率分析。如图 9,在测试用例写好后,可以在右键点击测试类,选择 Coverage As -> JUnit Test.

 

步骤四:持续集成

 

持续集成(Continuous Integration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时 都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的 反馈。

要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服 务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。IBM Rational Team Concert (RTC) 可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动 构建和代码的自动单元测试是持续集成的关键过程,RTC 在这些过程上提供了有力的支持。

 

步骤五:代码评审和重构

 

 

代码评审(Code Review)是 Java 项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是 否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速 学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(Peer Review)和小组评审(Group Review)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。

为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有 Jupiter 和 Code Striker。Jupiter 是一款开源的 Eclipse 插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以 XML 文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。

2011-03-29 19:33:00 cheny_com 阅读数 2547
  • SCRUM敏捷开发视频教程

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

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

软件“可运行”了就可以评审且通过了?这是个问题。

在多年前参加Scrum Master培训的时候,老师拿出一个很好的表格,每行是一个故事,每列大致如此:

编码完成

功能测试

单元测试

集成测试

压力测试

自动测试

……

这样在计划会的时候,PO就告知大家每个故事他的要求是什么,一方面大家会因此对于要估计的用户故事有一个更明确的理解,另一方面就是约定了评审会上这个故事的完成标准。

 

这个方法已经不错了,不过后来又发现一个更好的:EA(一家游戏公司)将其所有故事完成标准分为5级,分别是:

1. 可提供反馈的(就是马马虎虎做出来能玩就行)

2. 可运行的

3. 可提供玩家评价的

4. 可提供玩家体验的(在体验服务器上安装(在线游戏),或发行预览版(单机游戏))

5. 完美的(可上线和销售的)

这种方法更好地从客户价值理解了“完成准则”,看到准则等级,就知道该如何使用此功能。

当然两种方法并不矛盾,因为“可提供反馈的”这种基于客户价值的完成标准一定有对应的基于实现的完成标准,比如“可提供反馈的 = 编码完成+功能测试”。

 

另一个话题是有了这些标准,如果只在最后评审会才使用,一定会制造不少“惊喜”。所以在迭代中期如果有些功能已经完成,完全可以随时评审,并基于评审结果当时就做改进。有一家公司在长度为一个月的迭代中的10、20天分别进行两次评审;而游戏公司普遍采用的是在功能完成的同时就进行评审。评审中发现的问题属于要拥抱的变更(在《迭代期内无变更与……》的两篇博文中有描述)而非要拒绝的变更,以便使得迭代能交付更多客户价值,MoSCoW会防止变更损伤承诺。

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

敏捷开发工具链

阅读数 23

认识敏捷开发

阅读数 380

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