2018-05-24 11:20:45 runOnWay 阅读数 455
  • SCRUM敏捷开发视频教程

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

    10404 人正在学习 去看看 CSDN讲师
    一、敏捷开发是一种开发方式
    敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发,所以它主要的驱动核心是人,而不是像瀑布模型那样,以文档为核心。
    敏捷开发更注重的人与人之间的沟通、交流。它认为个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划。虽然右项也有价值,但是敏捷开发认为左项具有更大的价值。
   迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样一个周期就是一次迭代的过程,同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
   二、几个重要的名词
   Scrum:是一个橄榄球专业术语,意味并列争球。用了这样一个词在敏捷开发中,可以证明,在整个敏捷开发的过程中,团队中的每一个人都要像橄榄球运动员一样迅速、富有战斗激情,在这种氛围下才会达到敏捷开发快速迭代的要求。
   XP:极限编程,是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的开发方式。它强调在更短的周期内,更早地提供具体、持续的反馈信息;在迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它;依赖于自动测试程序来监控开发进度,并尽可能早地捕获缺陷;依赖于口头交流、测试和源程序进行沟通;倡导持续的演化式设计;依赖于开发团队内部的紧密协作;尽可能达到程序员短期利益和项目长期利益的平衡。

注:Scrum和XP是敏捷开发的两种方式,Scrum偏重过程,XP偏重实践。

    PO:Product Owner,产品负责人。主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
    SM:Scrum Master,流程管理员。主要负责整个Scrum流程在项目中的顺利实施和进行,以及扫清挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
    ST:Scrum Team,开发团队。主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5-10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力。成员可以采用任何工作方式,只要能够完成开发任务。
   PB:Product Backlog,产品需求列表。由PO负责,按优先顺序排列产品需求。
   Sprint:冲刺。指一次迭代,每次迭代的周期大约是一个月。
   INVEST原则:是缩写组成,Independent独立的、Negotiable可协商的、Valuable有价值的、 Estimable可估计的、Small小的、Testable可测试的
   三、Scrum开发
   1.首先由PO,制定PB。
   2.ST根据PB,进行工作量的预估和安排。在工作量预估中,可以使用计划筹码,每个筹码代表着完成一个故事的时间,是一个故事点的倍数,一般有1、2、3、5、8这几个数字。每个人对工作的预估在亮出筹码之后,如果有不同意见,不能折中选平均数,而是要各自说出理由,再重新进行预估。
   3.有了PB列表,就需要通过Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完成的目标,然后将这个Story进行细化,一个优秀的Story要遵循INVEST原则,形成Sprint Backlog,然后再继续细化,争取每个细化的任务能在2天内完成。
   4.在ST完成PM上选出的Sprint Backlog过程中,要进行Daily Scrum Meeting,每次会议要控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报昨天完成的工作和承诺今天要完成的任务,如果遇到问题也可以提出问题,表述结束后,要更新自己的燃尽图。
    5.要做到每日集成,每天都要有一个可成功编译、并且可以演示的版本,这就凸显出了持续集成的重要性。
    6.当一个Story完成,也就是Sprint Backlog被完成,就代表一次Sprint完成,要进行Sprint Review Meeting,PO和客户都要参加,每个ST成员都要展示自己完成的任务。
    7.最后就是Sprint Retrospective Meeting,所有成员轮流发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

   敏捷开发的快速迭代有很明显的优势,但是对团队的要求也更高,尤其是按时完成任务,对自己的承诺负责这点,如果要保重能够按时完成任务,就要在预估工作量上更加严谨,而不是取折中这种方式,每个人要更加坚持自己的立场,只能够因为合理的逻辑做出计划。
2017-03-30 09:46:00 weixin_33860553 阅读数 26
  • SCRUM敏捷开发视频教程

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

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

敏捷开发总结(1)软件研发过程

 

 

 

 

 

 

 

2015-02-02 16:19:08 sky19891212 阅读数 2161
  • SCRUM敏捷开发视频教程

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

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

Scrum实施【敏捷开发总结】

 

希望能给大家提供更简单清晰的总结,切记不应教条化敏捷开发过程!

 

敏捷开发模型主要有三个:XP,RUP,Scrum,分别侧重点也不同。这里就介绍我最近学习的Scrum。



Scrum是目前世界上最流行的敏捷开发方法之一,你可以将之理解为一个管理框架。它是一种以为人为核心,迭代和循序渐进的开发方法。在Scrum中发布产品的重要性高于一切,团队必须高度自治,成员熟悉开发中遇到的各种技术,一般在2至4周,必须出一个实际运行的版本。Scrum团队自我管理,坚信团队所有成员能够偶胜任工作,完成设计开发。其特点有:

1、倡导面对面沟通交流,胜过面面巨细的文档。

2、相信计划不能被精确估计。

3、明确团队的技术实力,相信没有不可为完成的任务。

 

开发模型:

 

简述:

Scrum团队一般由5-10人组成,横跨各个职能,负责设计、开发、测试、文档编写等工作。Scrum团队构成:产品负责人,ScrumMaster,Scrum团队。产品负责人主要负责产品功能和完成时间,对产品负责,确定产品优先级。ScrumMaster主要负责整个Scrum项目进度,调整项目计划,促进团队成员充分沟通,组织每日Scrum会议,Sprint计划会议,和Sprint评审会议。

 

在一个Scrum项目中,首先要将所有需要完成的工作列在一个ProductBacklog(根据初始需求分解出的任务列表,所有功能的总纲)中,每个Backlog项就是一个Story,项目开发过程中需求的改变也要写进去。

 

在每个Sprint开始之前,要召开Sprint计划会议,Sprint的任务选择决定权属于团队,需都是从Stakeholder那里拿来的,团队有权从SprintBacklog中选择适当的任务,作为SprintBacklog,那种由ProductOwner一个人完全主导任务是不对的,团队应该参与讨论需求和计划的活动中去。在会上,产品负责人ProductOwner为ProductBacklog中的任务确定优先级,团队按照优先级从Backlog中挑选他们认为能在这个Sprint中完成的任务,并把这些任务从ProductBacklog中挪到SprintBacklog中去。

 

一个Backlog包含多个Story,然后将Story分解成若干Task。

 

编号

标题

描述User Story

优先级

Story Point

XXXXX

新Ajax框架

用户通过Ajax框架实现所有Web应用,并达到桌面级用户体验

1

40

XXXXX

XXXXXXXX

作为某个角色,我可以做什么,以完成什么目的

2

20

 

在Sprint的进行中,团队每天都要举行简短的Scrum会议,以便成员了解开发进度,一个Sprint之后,召开Sprint评审会议和回顾会议,在会议上,团队展示这个Sprint开发成果。Scrum会议地点选在任务版前,时间控制在15min,站立面对面沟通,会议记录轮流进行。精髓是避免大家各自为战的状态。每人都介绍昨天做了什么,今天做什么,遇到哪些问题和挑战?然后leader开始移动任务卡片。对于不能解决的任务可以交给其他能够解决问题的人去做。



 

 

Sprint计划会议(主要是为了制定SprintGoal和Sprint计划),把Backlog分解成具体的Task,就是早上每日Scrum会议所采用的小卡片。每个Task以小时为计量单位,安排到人。例如:用户登录校验功能可分为调研校验功能所需技术3小时,设计校验功能4小时,开发校验功能3小时,编写校验功能单元测试用例3小时,执行单元测试用例1小时,CodeReview 1小时,更新设计文档2小时,代码重构2小时……

 

开发人员负责编写单元测试代码,CodeReview。一个Story结束必须经过单元测试,集成测试才算真正完成

 

评审会议以demo在测试环境一下展示,对产品感兴趣的各种人都可以参加。不必费时间精心准备。Sprint评审会议能尽早帮助团队发现问题。

 

Sprint回顾会议,讨论哪些好的建议和方法被采纳,有什么不可取,有哪些需要继续坚持。

任务估计和实施:

如何进行任务估计?

使用PlanningPoker这样一个工具,产品责任人为大家挑选一个Story并简单解释其功能,以大家讨论,每个游戏参加者按照自己的理解来估计完成这个Story所需时间,从自己手里选一个合适的数字,出牌,并解释自己出牌原因,接下来根据之前的解释,重新估计,大家新一轮出牌,直至估计值比较平均为止。软件下载(http://www.planningpoker.com/)

 

结对编程和代码复审机制:

确保至少两人对代码有相同了解程度,确保团队都对代码有一定熟悉。两个人一起讨论,相互交替编码,同时只有一个人编码,另一个人指导,重新审视已完成的代码的逻辑和算法,使得代码评审工作在编码阶段就能完成。(Eclipse的ECF插件,可以实现结对编程)

 

 

 

推荐的Scrum管理工具:

1、ScrumWorks

2、XPlanner

3、RationalTeam Concert

 

参考:

1. http://blog.sina.com.cn/s/blog_91ed2bca0100y02p.html

2. 轻松Scrum之旅——敏捷开发故事

3. http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html

4. http://www.mountaingoatsoftware.com/tools/planning-poker
2013-02-06 13:25:54 zhangyishuihan 阅读数 520
  • SCRUM敏捷开发视频教程

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

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

                           敏捷开发实践总结(简介开场篇)

                         ----------永恒软件开发之道的不断追求!

     伴随着各种派对,总结,大大小小的年会的来临,令人蛋疼的2012(大实话呀,无半点儿虚言呀)终于要过去了!

     2012年真应该算是我们这迄今为止不长不短的人生(20多年)中十分特殊的一年了,社会上各种乱象层出不穷,真是你方唱罢,我登场,好不热闹,群魔乱舞,弄的我这个小小的屌丝程序员都感觉不淡定了,整天在跟同事笑谈,是我不懂世界,还是世界变化太快呀!(呵呵)

调侃到此为止,似乎有点扯远了!呵呵。眼瞅着离年底没有几天了,在焦急的等待发工资和奖金(公司官方宣布这两天发,不过他们一向没谱呀)的档口,忽然觉得自己应该弄个总结而且还得是文字形式的(以前做过无数次思想上的总结,现在发现没记录下来的东西纯属YY)才对的起自己这个2012年!  

(赶紧入题)其实2012年就自己工作上经历的最多的还要算是亲身经历了公司的产品研发的流程改变了;其实公司很长一段时间以来实行的都是CMMI(不清楚的同学可以google一下,学会google还是很好滴!)的开发管理流程,流程本身而言其实已经是软件开发领域很成熟的一套东西规范了,而且在业界已经有很多十分成熟的实践以及十分成功的案例可以参考了,它的优势似乎十分的明显:分工明确,开发任务按部就班,质量性能可控制,可考量!我所在的公司也不例外,作为一家着眼于大型平台级软件开发的公司来说,运用这套研发管理流程,公司成功的完成了在市场上普遍受到认可的2008系列产品的研发,在整体功能和性能上都做到了与竞争对手看齐的程度!可以说能算是一个不大不小的成功!然而随着产品研发的进一步深入,新的问题出现在了整个研发管理团队以及公司管理团队面前:随着大规模开发的完成,产品的各大模块儿功能基本上已经基本成型,接下来需求更倾向于非功能性的产品需求,产品经历一定的市场应用之后的客户反馈的个性化的需求,以及紧跟当今IT技术潮流的新实践(如为了适应三维应用的需求提出的realspace(真空间)整体技术实现方案);这些新的变化都要求我们能够在极短的时间内做出反应,这也侧面的印证了如今软件开发网络化的倾向!但是对于我们的开发团队而言迫于产品既定开发任务的压力,对于这种需求和变更的进入的整体态度一般都是排斥的!

不能快速的响应用户的需要,整个研发团队似乎给人一种闭门造车的感觉,客户和领导都怨声载道,市场上面转瞬即逝的商业机会总是不能及时把握!另一方面,研发技术团队的人却感觉很委屈,因为本着产品开发的进度和项目交付的压力,似乎不可能做出客户所要求的那种反馈速度,鱼和熊掌不能兼得也!

如何解决这些棘手的问题呢!2011年开始,敏捷开,故事卡,燃尽图,站立会议,持续改进,持续集成等等新鲜的名词和概念都统统在研发落地了。这里可能有的朋友已经对于这些概念已经耳熟能详,烂熟于心了,有的朋友似乎可能还是一头雾水,我这里仅就自己的感受来简要的介绍一下:

其实谈到敏捷开发不外乎一下的三个方面:

首先敏捷开发的目标,理想境界是什么?

所谓目标和理想境界和我们经常听说的共产党的最高追求是实现共产主义,解放全人类是一样的!我们这里可以用沟通,简单,反馈,勇气,尊重这样几个词来概括敏捷开发中我们追求的一种完美状态;充分的沟通使我们解决一切问题的前提,追求极致的简单是我们不懈的目标,及时迅速的应变反馈,敢于挑战疑难问题的勇气,以及对于团队每一个成员的尊重是我们敏捷理想国所必不可少的组成要素!

其次敏捷开发的架构是由哪些人员角色组成的呢?

整体说来敏捷开发的团队主要包含三个重要的角色:产品经理(product officer),团队主管(tema master),团队成员;其中产品经理主要扮演的是一个客户的代理人的角色,他应该不断的收集来自客户的有价值的需求并且把这些需求整理成为按优先级排列的故事卡,此外产品经理还应负责的的一个重要任务就是思考用户需求的展现问题,如何与现有产品体系形成一个很好的融合,极力避免前后的不兼容,同类产品是如何实现类似功能的,在与同类产品的竞争中如何形成差异的优势等等内容! 团队主管实际上在组织中主要扮演着技术负责人的角色,他对于团队任务的实现思路要有一个整体的把握,主要触及一些技术思路的验证,预研以及基础原型的实现;协助团队成员攻克开发过程中的技术难点,按时按量的完成开发计划!团队成员是整个开发团队的主体,作为开发团队最基本也是最重要的一份子,各成员之间要积极配合,高效工作,按照敏捷的要求来提升自己并出色的完成团队的开发任务!

最后什么是敏捷开发具体展开流程呢?

敏捷开发流程具体到实施上面主要是:在每一个产品版本周期的开始都会召开产品的规划会议,参会的成员主要包括有(但不限于):产品总监,各产品模块儿的产品经理,产品真正客户的代表(如果可能争取到参加的话);会议根据各个产品经理收集到的需求以及各个需求的紧急程度按优先级排列组成一个特性列表!涉及到各个具体的开发团队会以1-2周的时间为单位开展迭代式的开发,产品应该在迭代结束的时候达到可发布和可部署的要求,当然这个目标的达到除了依赖于产品的开发人员的责任心和技术能力以外还要依赖于产品的持续集成基础设施的运转!

今天时间太晚了,关于敏捷开发的大概情况先介绍到这里;如果有不足的地方希望大家批评指正,也欢迎大家留言讨论,共同提高!以上的部分观点参考自《解析极限编程---拥抱变化 kent beck cynthia andres 著》;

提前做个预告:在接下来的总结中我会将主要的问题讨论放在实行敏捷开发流程之后整个研发过程的效果总结以及在这个过程中所暴露出来的不足!敬请关注第二篇    敏捷开发实践总结(收获与不足篇)

2018-04-11 23:27:05 zhangxiaofan666 阅读数 5179
  • SCRUM敏捷开发视频教程

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

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

瀑布模型

简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

弊端:

1.接力棒的协作模式带来信息差:瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

2.难以响应变化瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”


敏捷开发:

敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征


Scrum:

目的

  1. 适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。
  2. 快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
  3. 我们作出的决定中, 50% 都是错误的。早早失败,早早学习。因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。

    Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错

流程:

1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

3.有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

4.Sprint Backlog 是由 ST 去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)

5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员

7.当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)

8.最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中


极限编程:简称XP

思想:交流、简单、响应和勇气:加强交流;从简单做起;寻求反馈;勇于实事求是


敏捷开发的特点

1)敏捷开发中更加强调沟通,沟通频率可能比以前更高,沟通时间可能会比以前更长,占用更多的个人工作时间,反而可能因此导致实际开发时间起过原来开发出某个功能的时间; 

2)敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”,使开发人员反而感觉工作量增加了,短时间内会表现出开发效率的下降,而且要求所有开发人员对需求的理解能力也要求更高了,所以很多人会感觉敏捷开发对人员的要求更高,其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。 

3)快速的迭代使重构工作量增加,会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识,不仅会误以为影响了工作效率,而且会使程序员很受伤,因为他们认为是在不停地返工。 

4)信息的透明性要求较多的数据收集,敏捷成熟度越高,收集的信息就越多,收集这些数据会占用一定的精力,如果不能够正确的理解这些数据的价值,会让程序员感觉浪费了很多时间在做无用功,反而降低了开发效率。 


敏捷开发的流程:

需求评审:

(1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

(2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

(3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

(4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

(5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。


敏捷开发的思想

1)拥抱变化:各种因素都会影响计划的执行,所以计划要短,及时调整才能响应一切变化导致的计划的不可行性,避免走弯路。 

2)快速响应:市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划

3)快速将功能推向市场变现:迅速占领市场更显得尤其重要,这是在向时间要效益。比如做个用户系统,按照程序员的想法,一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完,而如果按功能逐版本开发而不是一次开发完成,而是放在不同的版本里,可能需要更多天数,因为里面会有重构、修改界面等,但是应用可以在第3天就上线。争取了15天上市时间,有哪个系统因为没有验证码在上线后第3天就就被恶意注册?有几个用户会在6天后就忘记密码?有几个人会在9天后就修改密码?有几个人会因为登录频繁因为没有记住密码功能而不在使用?,讲到这里,那位朋友想起他们在上一个版本中的一个功能,如果这个功能按照敏捷的方式开发,可以早3个月推向市场,每个月有上千万的收(上线后的效果统计数据),这才是敏捷真正的价值所在。 

4)做最值得做的事:什么事最值得做,什么事就优先级最高,也就是ROI最高,ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标,非常复杂的综合指标,它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关,需要全方位评估。


敏捷开发的误区

1)敏捷开发不是用来管理开发人员的,不是用来提高开发人员的工作效率的,而是企业全面提升团队绩效的方法

2)瀑布开发模型是以文档为驱动的,把需求文档写出来后,根据文档进行开发的,而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。 

3)在敏捷开发中每次迭代都被成为一个sprint,中文意为“冲刺”,可见其速度与效率

4)尽管对敏捷开发的变通运用,可以带来巨大的效益,但现实情况是,多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中,在经历阶跃变化前,交付能力可能还会下降,当经历这个转变后,才开始获得交付能力的提升。

5)当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时,存在一个显著的风险,即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情,却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展,同时执行业务最好的方式也在不断转变。因此,执行一个大爆炸式的“敏捷”转型后,想当然地认为进一步的改进不再必要,是一个错误认识。

6)没有MRD,如何管理好需求?使用story模式来管理需求,将庞大的MRD划分为一个个可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了可节省大量的需求评审时间。

7)项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。

8)敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”,  “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

客观因素\最适用方式敏捷 (Agile)计划驱动 (Plan-driven)形式化的开发方法 (Formal Method)
产品可靠性要求不高, 容忍经常出错必须有较高可靠性有极高的可靠性和质量要求
需求变化经常变化不经常变化固定的需求,需求可以建模
团队人员数量不多较多不多
人员经验有资深程序员带队以中层技术人员为主资深专家
公司文化鼓励变化, 行业充满变数崇尚秩序, 按时交付精益求精
实际的例子写一个微博网站;开发下一版本的办公软件; 给商业用户开发软件开发底层正则表达式解析模块; 
科学计算; 复杂系统的核心组件
用错方式的后果用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。用敏捷方法,  商业用户未必受得了两周一次更新的频率。敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

专有名词:

PB: Product Backlog , 即按优先顺序排列的一个产品需求列表,只能有一个产品backlog

poProduct Owner产品负责人

Sprint Backlog有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

sprint backlog和Product Backlog的关系


每个矩形都表示一个故事,按重要性排序。最
重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点
估算的时间长短)。

sprint每次迭代都被成为一个sprint,中文意为“冲刺”

story:翻译是故事,本意是产品的功能,backlog中包含了许多story,故事中包含了如下字段

1、id

2、name,也即功能名

3、重要性,越高越重要

4、初始估算,该故事所需工作量,单位是故事点,3个人需要4天时间,就是12故事点

5、如何做演示,测试规范

6、注解

例如:



注意点:

1、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品

2、Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

3、sprint计划会议:

内容:

(1)制定Sprint目标

(2)团队成员名单

(3)Sprint backlog(Sprint中包括的故事列表)

(4)确定sprint 演示日期

如何做:

创建索引卡,放到墙上,这种用户体验比计算机和投影仪好得多。


每个故事下面有多个任务,任务只会存在于故事下面,而不会存在于product sprint中


4、们已经完成了 sprint 计划会议,应该创建 sprint backlog 了。它应该在 sprint 计划会议之后,第一次每日例会之前完成,这样规划:没做的,正在做的,已经做的,和燃尽图


经过每日scrum后变成这样:


最后变成这样:


对于燃尽图:


5、每日例会,时间15分钟,每个人都会一边描述昨天已经做的事情和今天要做的事情,一边移动任务板上对应的即时贴,如果他讲的是一个未经计划的条目,那他就新写一张即时贴贴到板上。如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉。

如果有人不知道今天干什么,解决方法

(1)请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说,“我们已经过了一遍任务板,你们现在对今天要做的事情有想法了么?”。希望他们有点儿概念了。

(2)如果他们还不知道该干什么,我会考虑他们是不是可以去跟其他人结对编程。

(3)从任务板右下角的“Next”区域中拿出一两个故事,放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声,你已经把一些条目加进了 sprint

6、对于大部分的团队sprint长度为三周,一个sprint包含10个故事左右

7、对于故事的任务量估算需要每个成员都参与,每个故事的估算,需要每人给出一个故事点,如果两人故事点相差太大,要讨论为什么,直到把所有工作估算完

8、Sprint 演示(有人也叫它 sprint 回顾)是 Scrum 中很重要的一环,且所有的 sprint 都结束于演示

9、Scrum 注重的是管理和组织实践,而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题,可以互为补充,相得益彰

10、测试驱动开发(TDD):测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续

11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。

12、多项目一起进行,那么两个项目的sprint应该是同步的


同步进行的 sprint 有如下优点:
可以利用 sprint 之间的时间来重新组织团队!如果各个sprint 重叠的话,要想重新组织团队,就必须打断至少一个团队的 sprint 进程。
所有团队都可以在一个 sprint 中向同一个目标努力,他们可以有更好的协作。
更小的管理压力,即更少的 sprint 计划会议、sprint 演示和发布

13、团队构建:




参考资料:

1、https://blog.csdn.net/nocky/article/details/51236848

2、https://blog.csdn.net/xinxing__8185/article/details/46708439

3、https://blog.csdn.net/baynkbtg/article/details/52402727

4、https://blog.csdn.net/liyangbing315/article/details/5387129

5、https://blog.csdn.net/ostrichmyself/article/details/5375223

6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html

7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096

8、https://www.zhihu.com/question/19638322

9、scrum and xp chinese version.pdf


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