2019-09-19 21:57:41 qq_39188747 阅读数 681
  • SCRUM敏捷开发视频教程

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

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

敏捷开发:

      就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态

优点:

1、敏捷开发的高适应性,以人为本的特性。

2、更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

缺点:

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

传统瀑布开发优缺点:

优点:

1. 为项目提供了按阶段划分的检查点。

2. 当前一阶段完成后,您只需要去关注后续阶段.

3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导

缺点:

1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。

2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险

3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4. 瀑布模型的突出缺点是不适应用户需求的变化

 

Scrum开发流程中的三大角色 

产品负责人(Product Owner)

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

流程管理员(Scrum Master)

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

开发团队(Scrum Team)

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

过程:

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的产品需求中

2011-02-18 14:49:00 iamdll 阅读数 483
  • SCRUM敏捷开发视频教程

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

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

现实生活中,软件的需求往往不是在设计阶段就非常明确,而是处在不断的演化中,贯穿于软件的整个生命周期。由于需求的不明确及其变化,导致软件开发 的各个阶段都要随之变化,包括分析建模、概要设计、详细设计、代码设计、软件测试等等,因而对软件开发的成本、工作量、开发进度、软件质量都形成了严峻的 考验。

  在研发过程中,由于需求的变更而引起的分析、设计、编码、测试等阶段的变更数不胜数。同时在研发中的不同阶段,由于需求的变更而带来的修改难度也存在很大的差别,而利用良好的管理工具和处理手段可以较好的应对这些变更。

1、敏捷软件的开发方法
     敏捷方法是来源于实践的方法,可在非常短的迭代周期内应对需求的不断变化,并且提供了轻量级的软件项目管理和开发、维护的思路。所谓轻量级就是能根据需求 变化快速地做出反应。敏捷方法是“适应性”而非“预测性”,目的是成为适应变化的技术过程。而传统重量级的软件开发方法是试图对一个软件开发项目在很长的 时间跨度内做出详细的计划,然后依照计划进行技术开发,在项目计划制定完成后拒绝变化,这显然是不可行的。敏捷软件开发方法是“面向人”的而非“面向过 程”的,强调软件的开发应当是一项愉快的工作,应使软件开发工作能够利用人的特点,充分发挥技术人员的创造能力。

  敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的 特征。也就是把1个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

2、敏捷开发平台的实现
     2. 1敏捷开发流程

  敏捷开发平台主要用于开发基于J2EE架构MVC模式的Web项目,其架构主要由开发环境(Eclipse及其插件、Struts、Hibernate等)、源代码仓库(Subversion)、构建服务器(Cruise Control、JUnit、Ant及代码检验模块Check Style)、Web服务器(Tomcat、HttpUnit、JMeter)等几部分组成。图1给出了敏捷开发系统流程。

  首先需要从源代码仓库中获取全部最新的源代码,然后编写程序的代码和相应的单元测试代码,以保证程序能够通过编译并且所有的单元测试全部通过,再提交代 码,将代码检入到源代码仓库中。持续集成工具Cruise Control的源代码监视及管理模块监测到源代码仓库中的代码发生变化后,由Ant执行任务,首先初始化目标目录,将目标目录清空后,创建源程序目录、 测试程序目录和class目录,接着从源代码仓库中检出源代码到源程序目录,检出测试代码到测试程序目录,然后调用代码检验工具Check Style检验源代码是否符合事先配置好的代码规范,再编译源程序生成目标类,并调用JUnit测试框架进行测试,如果测试全部通过,即可将整个Web应 用打成1个WAR包,并将这个WAR包发布到Web服务器。

  2. 2敏捷开发平台的搭建

  在敏捷开发过程中,通过配置管理软件对源代码进行管理和控制,就可以实现任何开发人员都能够很容易地获取到全部最新的源代码。关键的环节是自动化,能够自 动根据配置的时间间隔读取配置文件并进行循环构建。构建过程中所做的工作主要是访问源代码仓库,检测源代码仓库中代码是否发生变化。如果发生变化,应获取 源代码的最新版本,并根据配置信息首先对代码进行检验,再对代码进行一次构建,创建一个日志文件,最后向项目组所有人员通知代码的检验结果和构建结果。如 图2所示敏捷开发平台框架。

  敏捷开发框架是基于SOA的软件开发模式设计并运用J2EE技术实现的应用程序开发框架。该系统综合利用了ESB技术、EIP设计模式、IOC模式、构件 设计、管理、组装技术以及数据集成和数据交换等关键技术,具有良好的与其他软件开发管理系统接口的能力。该系统并非直接为最终用户服务,而是为开发最终用 户的应用系统提供一套工具和运行平台。它可以使开发人员专注于应用系统核心业务逻辑的分析、设计和开发,极大地增强了软件应用的伸缩性和灵活性。基于敏捷 开发平台开发的应用程序符合松散耦合、可重构的系统需求。

3、敏捷开发方法
    VISIONONE公司在2008年6月至7月进行了关于敏捷开发的问卷调查,根据得到的来自80多个国家的超过2300份问卷反馈得知,95%的公司在 软件开发中使用了敏捷方法,其中超过60%的公司使用超过了一年时间。

  Scrum和XP作为最重要的两种敏捷方法,超过70%的公司在使用,下文简要介绍这两种常用的敏捷开发方法。

  敏捷方法是数十种“方法集”的统称(“方法集”就是为了开发软件而定期做的每一件事情),包括比较有代表性的Scrum、Extremeprogramming (后文简称XP),Unified Process和Crystal Clear等。这些“方法集”共同的特点就是轻量级,迭代增量式的开发和交付,以及适应需求变化。

  3.1 敏捷方法之一:Scrum

  SCrum的创始人是Jeff Sutherland和Ken Schwaber,他们在1995年提出了Scrum方法。近年来Scrum已经变成了敏捷开发中最流行的方法之一。Scrum使用“产品 backlog”、“Sprint backlog”和每日例会(Daily Scrum Meeting)分别对整个项目、每个迭代周期和每个工作日进行计划完成情况追踪,并根据每日例会、Sprint计划会议和Sprint评审会议得到的反 馈,不断对项目开发计划和过程进行调整

  3.2 敏捷方法之二:XP

  XP是一个非常著名的敏捷方法,最早是由Kent Beck在1996年提出的。XP注重使用更短的迭代周期(1至2周)和大量的工程实践,包括用户故事、结对编程、持续集成、测试驱动开发,重构和自动化测试等

4、敏捷方法的应?
    在欧美外包项目中,需求分析工作贯穿于产品开发的始终,而且需求变更会经常发生。敏捷方法作为“拥抱”需求变化的方法,是最适合这类项目的。

  另一方面,敏捷方法采用短周期迭代和增量交付的方式,可以最大程度的避免需求理解的偏差,并且帮助客户明确和完善需求。特别是Scrum在每次迭代结束的 时候,开发团队通过产品演示阐明了对需求的理解,同时根据在演示中双方的沟通,明确一些有歧义的需求,并且引导客户对需求进行进一步的完善。

  除此之外,敏捷方法也能满足欧美客户对开发过程的其他方面要求。比如,客户希望开发团队采用本公司熟悉或者与本公司软件开发类似的开发方法。

  事实上,敏捷方法被世界上越来越多的公司和团队使用,并且项目成功率和质量很高,欧美很多公司也有敏捷方法的实践,所以一般来说欧美客户很容易接受团队使 用敏捷方法。再比如,客户希望可以经常得到可以运行的版本,帮助他们通过给潜在终端客户的演示,了解市场和最终客户的需求,这无疑也是敏捷方法的强项。

5、结束语
    敏捷方法作为近年流行的一种软件开发方法,由于适应欧美软件项目需求频繁变化的特点,同时满足客户对于短周期增量交付的要求,在欧美软件外包行业中得到了 越来越广泛的应用。经过多年的时间证明,敏捷方法能够提高开发团队的生产率,产品的质量和客户的满意度。对于软件外包服务商而言,在公司组织级需要采取相 应的措施,以对敏捷团队进行支持和监控,并满足客户不断提高的要求

2009-03-13 10:34:37 congmu1588 阅读数 1
  • SCRUM敏捷开发视频教程

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

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

    Kent Beck做了许多与敏捷软件开发相关的幕后工作,其中包括JUnit测试框架和极限编程。Kent还是在面向对象编程中应用设计模式的先驱。InfoQ的Kurt Christensen最近采访了Kent,并询问了一些关于敏捷软件开发现状和未来定位的问题。

    InfoQ: 您目前的工作是什么?

    Kent Beck (KB): 前不久我刚完成《Implementation Patterns》一书,该书介绍了如何通过代码进行沟通。它将在2007年第一季度上市。现在我正在开发JUnit的新版本。与此同时,在我现在参与的许多项目中,我将很多时间花在利用付费客户端进行远程结对编程上。

    InfoQ: 当一个敏捷团队工作时,有时透明化的流程会暴露出机构中的问题,而这些问题随后又被归咎于敏捷开发流程。在整个行业中,我们开始遇到这种情况了吗?敏捷开发会使行业的缺点逐步暴露,从而在各方面招致一些与敏捷开发对抗的反对意见吗?

    KB: 我所见过的大多数反对意见来自于程序员个人而非机构或整个行业,这些程序员通常不愿向机构中的其他成员负责。我想,这些针对行业的反对意见,反对的不过是敏捷开发这个词的含糊使用,而不是任何特定的流程。

    客户看起来并不在意更少的缺陷和更可预测的时间表,以及程序员们是否愿意沟通和贯彻他们的承诺。当客户开始期望这些,而程序员们却不打算这么做时,问题就产生了。用敏捷开发标榜自己,却不去遵循敏捷开发的价值观和原则,最终将导致程序员与客户间糟糕的关系。

    InfoQ: 作为一个社区,我非常担忧这种情况,当敏捷开发起作用时,我们夸耀自己,而敏捷开发行不通时,我们彼此踢着皮球并且说这样做不“正确”。如果敏捷开发更像是价值观而非规范或特定的习惯,那么一个机构如何才能知道何时他们真的在进行敏捷开发呢?如何才算正确地进行敏捷开发呢?

    KB: 你描述了人们对结果不满意时的反应,但你忽略了人们从中学习到经验的机会。我想,因为我们怕难为情,我们已经错过了许多分享和学习的机会。

    有时我们会想,“假如我是一个完美的程序员,这个项目应该就会非常成功了。如果项目不是轻松完成,那我就算失败了。”这种心态或多或少地影响了我们的行为。

    而且确实,当你承认失败时,敏捷开发社区中的人们会斥责你的失败。在避免这种令人胆战心惊的结果的同时,我们与那些有用的心得失之交臂。

    成功的项目需要许多因素以及彼此的同心协力,一个人无论多聪明或者多么卓越,项目的成败都不可能由他一个人的技术能力和意志力决定。无论如何,沟通、团队建设、时间安排、与公司其它部门协作、甚至编码窍门等,这些东西都是我们可以从失败的项目中学到并应用于未来项目中的。如果我们愿意分享心得(而不是我们的失败感),那么作为一个社区,我们还可以做得更多。

    敏捷开发一词的含糊性会成为一个障碍。问“我们做得正确吗?”(或更可能的情况——告诉别人“你做得不正确!”),这个问题并没有什么价值。“我们在学习所有我们能学到的吗?”和“我们需要改变自己来最大限度地迎合公司的目标吗?”这两个问题更有意义。如果敏捷开发成为一种意识,那么我们并不真的需要衡量正确与否的尺度了。你工作时有敏捷开发的意识吗?你尝试过从多个角度看问题吗?你会突破桎梏去思考吗?你会参与到团队交流中,共同向一个有价值的目标去努力吗?你会以坦荡诚实的胸怀和负责任的态度向你们共同的目标努力吗?你参与的流程如何在组织中起作用,其意义远比一个敏捷开发专家对流程的思考要重要。

    InfoQ: 在您帮助机构向敏捷化方向成长的经验中,这些问题有一些明显的规律吗?为什么机构通常总是无法正确地开展敏捷开发呢?

    KB: 通常的情况包括我们缺少沟通,团队和成员彼此孤立,办公室里没有交流,某个人有团队所需的特长却没人愿意与之合作,或者无法表达清楚他们最近的工作对公司的价值等。

    机构层面的失败往往是由在流程定制和融会贯通方面的无能为力导致的。尝试直接将别人的模式照搬到你的组织并不会起到太好的作用。这样做将遗漏上一个成功案例中的太多重要细节,同时也会忽略你公司的特殊情况。生搬硬套的敏捷开发流程并不敏捷。基于敏捷开发原理的流程其价值在于,你能够将原理应用在针对你的情况的特定流程上,而且一个额外的好处就是你能够以此心得来改变你的组织。这才是“定制”。

    从个人角度来看,我认为最大的问题是——程序员压力太大。我曾经做过一次“放松工作(Ease at Work)”的讨论,你可以在Google Video搜索中找到视频。除非程序员能够保持一个清晰的自我认识,否则关于后续技术改进的探索将在很长的时间里一无所获。我确信这里同样存在一些属于机构的大问题,但问题的根源在这里。

    InfoQ: 在向机构介绍敏捷开发时,您会首先展示实例,然后借此来说明它的价值,或者恰恰相反?又或者在一开始就同时举例和说明价值?当您打算尝试去改变一个机构的价值体系时,您会选择哪种方式呢?

    KB: 我首先从人们已有的正面经验切入(这种方式被称为肯定式探询),并了解这些经验如何应用于现有情况。这将引发三个层面的讨论——价值观、原则和习惯。

    改变一个机构的价值体系需要强有力的支持,这种支持往往来源于机构中希望变革的高层。我倾向于尝试去引导这些机构发生改变,但这一般不起作用。相反地,我先与他们共事并按照他们的方式做好工作,当我通过这种方式首先表达了我对他们的尊重之后,效果才是最好的。这样做,我仍旧保留了我的价值观,原则和习惯。随着时间的推移,我们彼此取长补短。

    InfoQ: Scrum社区借其认证过程(译者注:Scrum社区是澳大利亚的一个关于敏捷开发的技术社区,它要求用户展示自己后,才向用户提供帐号。)在创立一个品牌。您认为这种方式有助于使敏捷开发在大机构中如鱼得水吗?通过这种方式推行敏捷开发是好是坏呢?

    KB: 我认为这种方式使得专家们要对自己的技术和成果负责。传统的认证过程不过是做个测试,提供一篇论文,我不认为这样的认证过程能有什么用。另一方面,其它的专业领域也存在有意义的认证过程。如果你是持证的内科医生,这意味着你通过了相应的认证。尽管这个与计算机中的认证相差甚远。认证的主考官都是专家,它的过程耗费很多时间和金钱,需要大量的研究和一次在实践中的示范来展示对知识的精确掌握。

    尤其在大机构里,认清名字能够帮助你找对办公室的门,但它仍旧有着照本宣科的问题。如果这被认为是可接受的方式,它就会开始被使用。而一旦办公室发生了一些必需的重大调整,那么这种方式将失去可信度,名字的价值也就不存在了。

    InfoQ: Martin Fowler前不久写了一篇名为“语义传播(Semantic Diffusion)”的文章,在文中他描述了“敏捷”这个术语的变化。当“敏捷”成为另一个口号时,敏捷开发会有什么改变吗?有没有办法来避免这种情况,从而保持理念和语言的生命力呢?

    KB: 当敏捷变成口号以后,人们会寻找最简单的办法来判断何谓敏捷开发。这个语义传播的隐喻的问题在于,意义会随时间弱化的观点忽略了那些明确并且成功的使用术语的情况,这些例子不断出现并保持着术语的原有含义。我一直都在关注这样一种情况,“敏捷”属于一个吸引眼球的词,那些一点都不理解它内涵的人也可能会使用它。谁不愿意被认为是在做敏捷开发呢?敏捷开发这几个字说起来轻松;有价值的思想往往附带着诸多的责任。这就是我们探讨“负责任开发”的原因。在英语中,责任有附带着负担、要求或者义务的含义。有价值的思想意味着许多东西,但同时它并不是那么轻松自由的。

    当你将思想公之于众时,别人如何利用它是你无法控制的。我能做的仅仅是尽全力去保留思想的火种,诚实地报道社区中发生的一切。

    InfoQ: 自您完成《Extreme Programming Explained》(中文版《解析极限编程:拥抱变化》)第二版至今,您有没有发现可以被加入到第三版中的新的价值观,原则或习惯呢?

    KB: 关于XP,我并没有什么新的体会。但我在工作中发现一些对做决策有帮助的原则。

    我已经开始参考一些并没有列入第二版的原则了,这其中包括问责性和透明度。我探讨了这两大出自于测试驱动开发的原则,对它们加以明确并随即验证。最终,我发现这些能够降低流程损耗的原则非常有用。

    随着实践的逐步深入,我不久前使用的最重要的东西就是追踪和分析软件的真实使用状况。目前在我参与的一个项目中,我们实现了对用途的追踪,这好比在黑暗的房间中点亮所有的灯光,那些用户切实使用的功能将一目了然。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14639675/viewspace-567136/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-567136/

2015-04-23 17:21:41 lqh4188 阅读数 1809
  • SCRUM敏捷开发视频教程

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

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

1.  极限编程在项目中的应用

最早接触极限编程的概念是在2010年看的一本书《解析极限编程--拥抱变化》,当时并没有一下子看完,之后断断续续的读着。但在是实际项目中并没有真正的应用。

在2011年3月份进入一个3500多万的项目中,在调研和开发的过程中,遇到了很多问题,在这个过程中,开始逐步的把极限编程的部分思想来应用于项目。

1.1.  沟通很重要

  无论是在工作还是在日常生活中,沟通对我们来说,都是非常重要的交流与获取反馈的有效途径,在项目管理中,尤为重要。若沟通不良,对项目造成的影响是具大的,比如没有向客户询问该问的问题,而导致程序在关键性设计中出现失误。管理人员不向开发人员问该问的问题,而导致项目进度误报。

  在项目管理中,沟通是获取客户需求的关键,是程序设计的依据,是制定项目计划的参考。所以我们要促进良性沟通,避免不良沟通。

1.2.  简单设计

有三条准备可以避免软件项目中常见的戏剧性效果和机能障碍。

1.在项目初期不可能收集到所有需求。

2.不管你收集到什么需求,最终它们肯定会发生变化。

3.总会有任务超时、超支。

所以在设计的时候要尽量的简单,避免过度设计

1.3.  每周交付一些有价值的东西

大部分情况下,客户不能确切的告诉你他们需要什么,一旦客户见到第一个版本,他们就知道了在第二个版本中他们需要的东西……或者说他们在第一个版本中实际想要什么。所以我们有必要每周都交付一些可用的东西。

这样做的好处是:

1.及时反馈:可以及时获取用户反馈,通过频繁的与用户沟通、反馈,形成良性沟通,明确用户真实需求。

2.保障项目进度:短周期的交付,便于项目的调整,减少用户意途与开发之间的理解误差。便于项目进度的掌控。

3.给用户和开发人员信心:由于每周都能看到可用或可演示的东西,让用户对项目有信心,也可以了解项目进度,这要比一个月交付的一次更有说服力。同时对于开发人员,每周的功能都能得到用户的确认,若需要调整,也是小幅度调整,若不需要调整,则是对工作内容的肯定与激励,可以提高工作激情。

1.4.  控制范围

极限编程中的四个变量是:成本、时间、质量和范围,其中范围的控制最有价值。

一般在项目合同中,均会对时间、范围进行约束,质量就不用说了,如果质量不合格,用户是不会验收的。对于成本和时间基本是不可能有大的改变的,对于范围,合同中不可能对边界定义的十分明确,这就需要我们在整个项目进展中进行有效控制。

客户在开发的过程中,会将范围无限的扩大,如果项目经理不对范围进行控制,这个项目会不断的扩展,造成成本增加,开发周期变长,无法在合同规定内完成项目的验收。

所以说范围的控制最为有价值,他是我们项目管理人员唯一有主动权的要素。

关于质量和时间,牺牲质量以换取时间的做法是不可取的,这种短暂的收益在项目后期将导致致命的伤害。所以要平衡这两者的关系,使得开发人员可以在有限的时间内开发出高效的产品。

1.5.  结对编程

对于极限编程中的结对编程思想,在现实中似乎是不可能应用的,不过在2015年2月份,很有幸的体验了一下。

在一个需求开发即将结束的时候,正好另外有一个需求过来,而且其中有一部分有重叠,于是我和另一个负责人商量了一下,决定把重叠部分进行重构优化,合并抽象为一个模块。由于对于这部分我们两人都了解,所以开发过程中,我们尝试了一下结对编程,他写代码的时候,我在旁边看着,并提示注意事项(当然还可以喝喝茶、吃点东西),然后我再接着写,他在旁边看着,并提示我注意或忽略的地方。3个小时,模块功能完成,测试通过,OK。

这次尝试感觉还是很成功的,两个人的效率还是很高的,而且目标明确,思虑清晰,轻松高效。

但是这种编程方式是不适合推广的:

   a.要求高:要两个人有一定的默契,不然反而事倍功半。

   b.国情:目前没有适合的土壤。

2.   关于极限编程部分关键词

参选书目:《敏捷武士:看敏捷高手交付卓绝软件》析级限编程》

2.1.  概述

极限编程是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

 

2.2.  核心价值

极限编程中有四个核心价值是我们在开发中必须注意的:沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇 气(Courage)、此外还扩展了第五个价值观:谦逊(Modesty)。  XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

2.3.  四个变量

成本、时间、质量和范围,其中范围的控制最有价值。

2.4.  四个准则

沟通、简单、反馈、勇气

2.5.  基本原则

快速反馈、假设简单、递增更改、提倡更改、优质工作。

2.6.  开发软件的四项基本工作

编码、测试、倾听、设计

2019-05-09 16:01:10 yangrendong 阅读数 57
  • SCRUM敏捷开发视频教程

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

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

   我们继续讨论大厂的敏捷方法应用。

    我们上节提过,如果每周一个Sprint,怎么保证每周都有交付,同时还能保证产品质量?

    一个应用敏捷开发的小组日常

这个小组是做网站开发,基于微服务负责网站的某一个小模块,标准配置7人、4个程序员(要起码有一个资深程序员有架构能力)、1个产品经理(Scrum里叫Product Owner),1个测试、1个项目经理(Scrum里叫Scrum Master),主要负责网站某模块的维护和协调工作。

    分工上:

  1. 产品经理:写需求设计文档,将需求整理成Ticket,随时和项目成员沟通确认需求;
  2. 开发人员:每天从看板上按照优先级高低提取Ticket,完成日常开发任务;
  3. 测试人员:测试已经部署到测试环境的程序,如果发现Bug,提交Ticket;
  4. 项目经理:保障日常工作流程正常执行,协调团队成员的沟通工作,提供必要帮助和解决问题

如何完成需求和修复Bug

这个小组的日常工作,也是围绕Ticket来开展的,所有的需求、Bug、任务都作为Ticket提交到项目Backlog,每个Sprint的任务都以看板的形式展现出来。

    每个人忙完自己的“To Do”后把对应的Ticket移动到“Done”,再按优先级选取新的Ticket,然后移动到“In Process”栏。

  1. 每周一部署生产环境

    一般部署放在周一,如果是周五的话,万一部署发现问题,周末就需要加班无法好好休息了,所以除非紧急,部署都是放在上半周,这样遇到的问题后续有足够的时间去应对。

    部署很简单,按照流程执行几个命令就可以完成生产环境部署,然后需要对线上监控图标进行观察,有问题及时甄别,必要的话对部署进行回滚操作,但要记得不要轻易打补丁重新上线,仓促之间的修复会导致更大的问题。

    敏捷开发一周一个Sprint的好处在于即使这周的部署回滚了,下周再一起部署不会有太大影响。

  1. 每周二开迭代回顾会议,总结上周Sprint

    每周二,小组会预留一个小时的时间,作为迭代回顾会议(Sprint Retrospective)会议,目的是总结迭代中,团队做的好的地方和不好的地方。

    对于后续需要改进的,需要创建Ticket,加入到Backlog中,后续迭代中改进完善。

    例如测试人员反馈说,上一个Sprint,开发人员上线前几个小时还往预部署的分支里更新代码,导致测试需要重新弄做回归测试,但因为时间不够了,来不及测试完整,导致上线后不稳定,对于这样的问题,可以反映出流程出了问题,需要商定不是紧急的修复,不能在预部署分支上更新,确实需要加,要和测试确认。

    会议中涉及项目的决策,最好通过集体表决的方式决策,尽可能避免独裁式决策,因为敏捷的原则之一就是要善于激励项目人员,给他们需要的环境和支持,并给予充分的信任。

  1. 每周四迭代规划会,计划下周工作

每周四也需要一个小时的组织会议来迭代规划(Sprint Planning Meeting),大家一起讨论下一个Sprint的内容。

    开会前,产品经理和项目经理商量好Ticket优先级,大家按照优先级从Backlog中选出下个Sprint的内容。团队每个成员对下个Sprint Backlog中的Ticket进行同时打分,决定Ticket的工作量。

  1. 评估每条Ticket工作量的大概流程如下:
  1. 会议组织者阅读一条Ticket,可能是用户故事,可能是Bug,可能是优化任务,询问大家是否有疑问
  2. 大家一起讨论这个Ticket,确保充分理解Ticket
  3. 大家对Ticket进行工作量估算
  4. 估分存在分歧,出分最高和最低说明理由,最有达成一致

这种估算方法叫估算扑克,也就是poker,此方法的评估好处:

  1. 大家积极参与,详细了解需求,
  2. 工作量是由实际参与开发的成员做出评估,往往更准确易接受
  3. 促进成员的交流和经验分享

所以,经过N个Sprint的磨合后,一般一个团队的每个Sprint产出是比较稳定的,比如上面那个团队组成,一个Sprint预计完成20-30分的Ticket。

  1. 每周五分支切割

周五标志着一周的工作结束,所以下班之前,做branch out,把Master主干分支代码克隆到分支上,因为一周的开发,master已经合并了不少新的PR,如果我们直接把master部署到生产环境,是有风险的,毕竟自动化测试无法完全代替专业测试人员,所以需要再人工测试出来的Bug进行修复,直到稳定下来。此预部署的分支测试验收通过后,预部署分支的代码会部署到生产环境中。

https://static001.geekbang.org/resource/image/a1/67/a1ff4dc93ffa7d68ab5d757317623167.png

  1. 每周轮值

日常开发还有很多琐碎的事情,比如每周部署生产环境,每天部署测试环境,每周的branch out,回答其他小组的问题,主持每日会议,这些琐碎的事情在敏捷开发中,通过轮值让每个人去体验一下,大家会更有集体荣誉感和责任感。

问题就出来了,

  1. 基于这种敏捷开发的方式加班多吗?

加不加班跟是不是敏捷开发关系不大,要看项目组情况,基于敏捷开发一个Sprint,一个Sprint迭代,节奏稳固,这个Sprint做不完可以顺延到下个Sprint,不影响发布,而瀑布模型会前松后紧,后期加班可能性很大。

  1. 一周一个迭代怎么保证质量
  1. 足够比例的自动化测试代码,可以很好的保证质量,用户的主要功能通过自动化测试覆盖时,基本可以保证主要功能流程不会出问题
  2. 一个Sprint开发完毕后,并不立马部署到生产环境,而是先部署到测试环境,会有一周时间测试。
  3. 有专业的测试人员进行测试,并非完全依赖自动化测试,甚至有时打的功能更新,会组织全组成员一起测试。

https://static001.geekbang.org/resource/image/30/c5/30f2a81130d5adc74921c88a0f7464c5.png

  1. 基于敏捷开发如何做计划

大厂通常会在上一年底确定第二年的大的开发计划,并确定上线的时间范围,每个季度再根据实际情况进行调整,大的计划会变成具体的开发任务,大的开发任务会分拆到各个部门,各部门再将任务分拆到各个项目组,基于敏捷开发的话,要看开发任务放到哪几个Sprint去做,并且确保在规定的时间范围内完成。攻击估算上,会对每个Ticket进行打分,根据分数评估工作量。

  1. 如何沟通协作?

组和组之间的沟通协作,主要通过邮件、会议、内部沟通工具,最终任务会以Ticket的形式体现,团队内部的话,每天站立会议都是很好的沟通方式。敏捷开发中的一种实践结对编程,两个程序员一台电脑工作,这个争议一直比较大,不过我觉得如果两个人一起排查Bug,或者资深程序员带新手程序员,我觉得到时非常好的协作方式。

  1. 上面介绍的实践案例和标准Scrum有什么不同?

角色称呼不一样,Scrum里是Product Owner、Scrum Master和Team,而本案例是产品经理、项目经理和开发测试人员,而且传统项目经理是偏控制型,而Scrum Master是服务型,主要职责就是保障敏捷流程的执行,以及提供必要的帮助,集体决策是很好的团队决策法。

Scrum有四种会议,每日站会(Daily Scrum)、Sprint计划会(Sprint Planning)、Sprint回顾会议(Sprint Retrospective)和Sprint评审会(Sprint Review)。

敏捷开发核心其实并不是应用了哪个方法,而是应用的时候,是否遵循了敏捷开发的价值观和原则。

总结起来,大厂的敏捷实践,关键是分而治之,很注重流程和工具使用,通过Ticket方式来管理和跟踪开发任务,通过自动化方式来部署生产环境测试。一般基于Scrum、极限编程和看板。

敏捷开发详谈

阅读数 52

敏捷开发实践总结

阅读数 2019

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