2011-09-22 18:57:30 zzcfrog 阅读数 466
  • SCRUM敏捷开发视频教程

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

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

2015-03-15 14:49:07 simon_wzing 阅读数 1265
  • SCRUM敏捷开发视频教程

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

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

UML的使用方式
草稿
蓝本
开发语言

在敏捷开发中我们常以草稿的方式来使用UML。

敏捷开发中我们常用到的图是类图跟序列图。我们用这两种图来分析识别领域模型。这些图形识别出来的概念将形成我们对相关领域描述的一套语言。

1.类图(Class Diagram)

用来描述对象的类型,是对静态信息的描述。这些静态的信息包括类的特性(Features)跟类之间的关系及限制。

- 相关概念

类的特性包括性质(Property)跟操作(Operation)。

 Property包括类的属性(Attribute)跟关联(Association)。

 注意操作(Operation)跟方法(Method)的区别。

Operation是过程的声明。Method是过程的具体实现。这个区别在存在多态的时候比较容易解释。比如,我们父类里有doAction(),在不同的子类中有不同的实现。在这种情况下,我们可以说我们有一个operation,并有多个Method的实现。

Generalization, 从软件开发的角度来看,用继承(inheritance)可以很好地阐述这个问题。判断继承的一个重要原则是李氏替换原则(Liskov Substitution Principle - LSP)。

依赖(Dependency),如果一个单元的相关定义的变换会引起其他单元的变化,我们就可认定着两者间存在依赖。在软件设计时。
通过辨识依赖我们可以分析设计在依赖方面的问题。通常我们要做到单向的依赖,环状依赖的形成是需要我们特别注意避免的。另外,我们尽量要依赖于稳定的单元。接口相对于具体实现要稳定。
根据依赖的定义,其实association,generalization都确立了类之间的依赖关系。但在图形表达时我们要根据想要表达的核心意图来选择是用依赖来表示还是association或generalization。
依赖的传递性上是根据具体依赖的种类不同决定的。一般的依赖不具传递性。有的也有传递性,比如继承。

-注意点
在我们识别generalization关系时,注意区分分类(classification)这个概念。原因是generalization是可传递的,classification是不传递的,它是描述对象跟类型之间的关系。比如,猴子是灵长目,灵长目是动物。灵长目是动物按目的一种分类。我们尝试应用传递关系来组织一下。我们可以说猴子是动物,但我们不能说猴子是动物按目的一种分类。注意这里“灵长目是动物按目的一种分类”是classification。所以注意这里“是”的关系不都是generalization。

2.序列图(Sequence Diagram)
序列图是交互图(Interaction Diagram)的一种。交互图描述某些行为上对象之间(注意是对象之间,不是类。另外有可能不仅仅是类的对象之间,可能还有其他参与者)的相互协作的关系。序列图用来帮助我们捕获一个场景下的行为。画序列图时,我们常针对一个use case进行,找出实例对象以及他们之间交互的信息来进行图示。

-作用
此图不能清楚地描述算法,但它能清楚地描述出调用关系。这很符合我们敏捷开发的需求。作为草图我们无需关注太多算法细节。
此图能清楚地辨析出各个对象的职责。作为OO开发的入门或初级用户,往往容易写出集中控制(centralized control)的代码,因为这样更加贴合过程式的思维习惯。而我们提倡分布的逻辑控制(distributed control),就是把数据跟行为紧密结合到单一职责的对象上。

2008-11-11 13:06:00 ddviplinux 阅读数 419
  • SCRUM敏捷开发视频教程

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

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

小型项目需要敏捷--迭代开发模型的应用

   

    现在的项目模型越来越严谨,问题风险越来越少。这对一个大公司是很有用的流程。我们确实也需要通过不断的根据需求完善这套流程。

但现在的业务流程有它自身的局限性。它使得项目越来越笨重,会议、文档、时间等沟通等成本增加,流水线过长将增加大量的固定成本。我们有必要考虑新的思路--迭代开发模型的应用。

    长流程优势:

n  安全:通过各个环节不断迭代,分散风险。

n  责任:各环节层次清晰,明确责任,避免后期分歧。

n  一致:保证产品是跟需求一致的。

n  成本:由于前期长流水线的审核的准备,后期基本上一次塑造成型,避免全面重构。

    长流程劣势:

n  效率:固定的评审环节,增加沉没成本。

n  僵化:当各方面达成一致,新需求再出现的情况下,有惯性壁垒,很难做出大的调整。

n  时效:由于固定的前期环节,客户看到最初的产品模型,将经历较长时间。

短流程迭代模型:减少评审环节,迅速出demo,后期通过需求的一致性不断迭代。

    短流程优势:

n  敏捷:迅速出demo,第一眼看到结果的时间缩短。

n  灵活:通过不断迭代,不断逼近最终需求。

    短流程劣势:

n  沟通:需要团队成员较多的沟通做为支持。

n  责任:由于没有明确的环节,责任不明确。

n  重构:多次迭代对于重构的成本非常高。若大项目做基础性改版,将成为噩梦。

案例:平台接入DEMO制作。

    项目需求紧急,时间短,需求少。

    UC,无评审。

    2天开发出原型。4天时间迭代。

综上:在大型项目中,可以不断优化流程,增加安全边际。在小项目中,可以减短流水线,用敏捷迭代的形式开发项目。

 

2017-12-03 20:21:19 wk843620202 阅读数 2025
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
敏捷开发实践总结

前言
敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

什么叫敏捷开发?
敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

对概念的理解:
以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的4句宣言
1,个体与交互 胜过 过程与工具
2,可以工作的软件 胜过 面面俱到的文挡
3,客户协作 胜过 合同谈判
4,响应变化 胜过 遵循计划

我对这4句宣言的理解:
产品结果大于形式,先把产品做出来,然后再整理出完善的文档
在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

为什么要使用敏捷开发模式?
敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

scrum流程图:


scrum 开发中的三种角色:
1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
2,scrum master:scrum的推动者,掌握大节奏的人。
3,team:一般由多个developer组成,开发的主力。

scrum 开发中的三大神器
1,production backlog(产品待办事项列表)
2,print backblog(详细任务列表)
3,sprint burn down(计划走向和实际走向组成燃尽图)

scrum 开发中的四个会议:
1,sprint计划会(理解需要做什么,然后讨论怎么做)
2,每日站会(昨天做了什么,今天打算做什么)
3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
4, sprint回顾会(讨论哪里完成好,哪里需要改进)

SCRUM敏捷开发流程是什么?

1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

下面是crum开发流程中的一些场景图:
上图是一个 Product Backlog 的示例,产品需求列表

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

上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
2,及时是敏捷开发,也要尽可能的有详细的需求
3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
5,坚决杜绝以下问题的出现:
需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
代码质量低劣不停出更新版本,叫快速迭代中;
不写正规设计文档,叫降低沟通成本和最好的文档是代码;
领导站身后指挥码农写代码,叫结对编程;
产品质量不靠设计靠测试的,叫测试驱动研发;


参考:


2010-07-20 15:36:00 alvanchen 阅读数 113228
  • SCRUM敏捷开发视频教程

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

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

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哪一种开发模式跟是否加班都没有必然联系。

敏捷开发总结

阅读数 460

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