2018-08-10 11:26:13 fan2252228703 阅读数 278
  • SCRUM敏捷开发视频教程

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

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

第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

(关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。)

敏捷开发流程:

1.首先需求负责人理清需求。

2.团队内部要熟悉了解(可以做做游戏)。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审,接口文档评审,故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么,遇到了什么问题,今天要干什么(承诺)。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审,迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程:

1.一周主要有以下几个过程:

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会:

每日立会是用来回顾自己在昨天做了什么,还有什么任务没有完成,为什么没有完成,遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺,既然承诺了就需要去完成。

 

迭代评审:

迭代评审是对本次迭代的评审,需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理,看有哪些没有完成,为什么没有完成,是否有什么风险,并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收,看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾:

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价:

好,不好,待改进。必须是针对团队的,不能针对个人。之后将统计结果写在黑板上,由团队人员进行投票。每个人必须对每个栏目进行投票,可以投多票反对,一票赞同,赞同票必须投,反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会:

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务,由相应人员进行工时评估,录入系统。完成后将任务和故事打印出来,贴到看板上。

 

迭代本身:

这个暂时不知道是什么意思。

 

接口评审(迭代中旬):

对团队人员写的接口进行评审,看是否符合标准,解释是否明了,需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审(迭代中旬):

对测试人员编写的测试用例进行评审,主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西,反思自己思维上有哪些没有考虑到,尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准:

故事的验收标准需要由团队人员来进行编写,提交给负责人,负责人同意后,则迭代评审时按照该标准进行评审。

周报:

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容:

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享:

这个是附加的,因为咱们都缺乏一些经验性,常识性的东西,所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析:

分组:开分前需要分好团队,根据不同情况将一个团队分成几个组,可以不分。并取个名。

迭代:一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事:将所有的需求划分成一个个用户故事,如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例:作为xxx,我要通过xxx,进行xxx。

用户故事地图:用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务:每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分:每个用户故事可以拆分成很多任务,常规的有:前台页面开发,接口文档设计与开发,后台逻辑开发,测试用例编写,接口自动化测试,页面测试。  数据库设计一般在开发前就以完成,不过也可以在开发时添加数据库设计任务。

燃尽图:

所有的用户故事和任务被划分工时后会形成一个燃尽图,燃尽图以一个迭代为周期。随时间推移,团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新:

每日立会开完后,需要跟新电子看板,将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态,如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务,当一天结束时,如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板:

敏捷看板有物理看板和电子看板,物理看板只能每日立会的时候可以拖动,电子看板可以随时拖动,敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段:

用户故事,todo,doing,block,done.

 

 

工具:

敏捷开发的工具网上有很多,我们用的是自己的。

需要具备的功能:

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长,迭代完成情况统计,团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成:一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行,不合规范的将会报错。

接口管理:我们使用的是本地搭建的rap2。

敏捷宣言:

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素:

1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。

2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。

4、5个价值观:公开、专注、勇气、承诺、尊重。(这五个价值观尤其重要,贯穿整个敏捷开发。)

十二条准则:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则:

我们遵循以下准则:

1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、项目过程中,业务人员与开发人员必须在一起工作。

5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

 

 

 

 

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

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

    10428 人正在学习 去看看 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-06-24 11:11:39 u011790275 阅读数 643
  • SCRUM敏捷开发视频教程

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

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

2017.6.24, 深圳, Ken Fang

在这么多年的敏捷开发、软件工程的职场生涯中, 收获最多的是, 能与相当多不同产品型态的团队、相当多不同个性的人共同的合作与交流。

而这其中让我最感兴趣的一点就是:每个人对敏捷开发、软件工程的认知与将敏捷开发、软件工程应用在实际产品开发中的实际的情况。

@ A 类型的人:学习敏捷开发、软件工程的意愿很高, 并且悟性也很高;非常的清楚敏捷开发、软件工程背后的思路, 更可贵的是, 自身能深度的去思考, 如何能运用敏捷开发、软件工程去解决自身或团队在产品开发上的种种的问题。这类型的人在个性上共同的特征是:谦卑、务实、专注、热爱追求产品与团队的成功。

@ B 类型的人:不论学什么敏捷开发, 都还是要将自己所熟悉的那一套, 往敏捷开发里头套;每天早上都开站立会,但站立会却沦为冗长的工作进度汇报与工作上的交相指责。有敏捷看板, 但产品开发的模式, 却是大瀑布。审计各式各样的文档, 却没有协作。只有文档却没有设计。更别提每日风险管理⋯等等。这类型的人个性上的特征是:习惯在既有的城堡、框框里, 用自己所完全熟悉的方法, 做自己所完全熟悉的事物。
毫无疑问的, 这类型的人, 即使是站了一百年的站立会议, 依旧无法理解高效的产品开发与团队应变为何物? 也没法明白, 为何产品的代码越写越多时, 莫名其妙的缺陷也就越來越多? 版本交付的日期与质量也越来越不可控? 当然, 更无法区分做产品与做事之间的差别了。

@ C 类型的人:完全不认同、不相信这世上有敏捷开发、软件工程这回事。只认同开发软件就是写代码, 今天白天代码搞不定, 晚上通宵搞, 晚上通宵再搞不定, 明天再搞, 总有一天能搞定⋯什么迭代计划, 每日风险管理, 按时交付, 分层隔离设计, 单元测试⋯都是废话。这类型的人个性上的特征就是:有强烈的主观意识与自傲。所以, 世界在他们的眼中,永远是不会变的;世界永远是他们自己所认知的那个样子。
C 类型的人, 所面临的处境与 B 类型的人是类似的; 也是没法明白, 为何产品的代码越写越多时, 莫名其妙的缺陷也就越來越多? 版本交付的日期与质量也越来越不可控?
C 类型的人, 永远搞不明白的一件事是: 为何当年开发初期产品的那个神奇且牛逼的大牛, 已不复见了?!

我概略的经验值(不是精准的科学数据):B 型与C 型的人约占了 85%, 而 A 型的人约占了 15%。

所以, 我想, 在敏捷开发、软件工程的职场生涯中, 除了要时时的去学习新的程序语言、软件架构、测试技术以外, 学习与了解人类的 “认知” , 也是一项必要且有趣的课程。

因为, 当了解了人类的 “认知” , 我们就能从团队成员的人格特质, 去设计适合团队成员人格特质的敏捷开发、软件工程的实践, 而不仅仅只是从产品的角度, 去设计敏捷开发、软件工程的实践。

“ 当了解了人类的认知, 我们将更能使敏捷开发、软件工程、产品与人, 做更紧密的结合, 而使得人类的行为能以更有价值、更高效的形式, 体现在产品的开发上; 这就是我们一直在努力的方向⋯” 

2012-06-25 18:21:54 iteye_14109 阅读数 318
  • SCRUM敏捷开发视频教程

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

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

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2019-05-21 18:56:52 StringBuff 阅读数 233
  • SCRUM敏捷开发视频教程

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

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

一、敏捷开发

“敏捷”是一种思想,与”瀑布“式(即传统开发模式)相比,敏捷开发有如下宣言

  • 个体和互动高于流程和工具:意思是敏捷开发中每个人都可以提出自己的见解,而不必按照”流程“逐个向上级反应。目的是为了降低”沟通的成本
  • 工作的软件高于详尽的文档:指你正在开发的软件,即使没有文档,你也可以开发(传统式开发中文档是高于开发的,没有”需求文档”,是不可以随便进行开发的)。不能停滞不前。
  • 客户合作高于合同谈判:指和客户之间的即使沟通,对于客户临时提出的要求来说,即使和合同文件上描述的不一致,我们也是要按照客户的要求做下去的

  • 响应变化高于遵循计划:在”敏捷“中,变化是无处不在的。所以我们不能按部就班,要积极的响应变化,最终实现“可交付的增量”这一目标。

敏捷十二原则

  1. 工作的软件是首要进度度量标准

  2. 敏捷过程提倡持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

  3. 不断地关注优秀的技能和好的设计会增强敏捷能力

  4. 简单----尽最大可能减少不必要的工作----是根本的

  5. 最好的构架、需求和设计出自与自组织的团队

  6. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

二、Scrum

定义:Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

Scrum三个角色

  • 产品负责人(Product Owner

  • Scrum Master

  • 开发团队

Scrum三个工件

  • 产品BacklogProduct Backlog):迭代计划

  • SprintBacklog

  • 产品增量(Increment

Scrum的5个活动

  • 产品Backlog梳理会议( Product Backlog Refinement
  • Sprint计划会议(Sprint Planning Meeting
  • 每日站会(Daily Scrum Meeting
  • Sprint评审会议(Sprint Review Meeting
  • Sprint回顾会议(Sprint Retrospective Meeting

Scrum5个价值

  • 承诺 愿意对目标做出承诺
  • 专注把你的心思和能力都用到你承诺的工作上去
  • 开放– Scrum 把项目中的一切开放给每个人看
  • 尊重每个人都有他独特的背景和经验
  • 勇气有勇气做出承诺,履行承诺,接受别人的尊重

 

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