2019-01-04 16:15:59 weixin_43918437 阅读数 290
  • SCRUM敏捷开发视频教程

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

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

一、什么是敏捷开发?

敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

二、敏捷开发的特点

敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能模块。正如敏捷宣言所提到的那样。

敏捷宣言强调的敏捷软件开发的四大宣言是: 
1.个体与交互高于流程和工具 
2·工作软件高于理解文档 
3·客户协作高于合同协商 
4·变化响应高于计划遵循 

结合软件研发实际,四大宣言可以这样理解:

个体与交互胜过过程与工具

       方法和工具是死的,人是活的,如何没有优秀个人和团队协作,再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好,一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷中每个成员都需要定时和团队的其他成员一起查看团队的整体进度,计划下一步工作,并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力,可以自发的通过各种途径解决开发过程中遇到的问题。

       虽然我们致力于个体和交互,但并不代表就不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程,每日构造等敏捷实践也需要工具的支持,需要哪些过程和工具由自组织团队制定,而不是由领导制定。

工作软件高于理解文档 

       在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档,支付多少金额等内容,而这些文档对用户来说是不是真的有价值呢?冗长文档对客户来说并不重要,其重要程度比不上一个可以工作的软件。冗长的文档对开发也不重要,没有人有时间去读,而且也不符合敏捷开发的特性,对研发团队来说最好的文档就是代码和团队,通过频繁的提供可以工作的软件,不断地搜集市场反馈,保证软件的市场时效性。

       虽然我们致力于提供可供做的软件,但并不是不要文档。我们在开发过程中仍然需要进行内部交流, 也需要和客户交流,我们仍旧可能需要制作原型,书写一些主要需求和算法,只要可以满足研发团队需求就行。

客户协作高于合同协商 

       寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件,而只有客户才更清楚怎么样才能满意,敏捷开发提倡客户和开发团队密切的在一起工作,经常性的根据市场需求对软件提供反馈。各种不同的敏捷方法都会利用短期迭代,通过尽早提供软件来达到与客户频繁沟通和反馈的,这也可以把问题及早暴露出来,以免隐藏的问题在后期造成更大的影响。

       虽然我们致力于客户协作,但为了双方利益和需要仍旧需要进行合同谈判。

变化响应高于计划遵循  

       敏捷项目承认开发过程中的不确定性,所以不会在开发中制定长时间的复杂计划,它们的成功都是建立在现实反馈的基础上的。每次迭代都是基于上一迭代的完善基础之上进行的,通过不断的响应变化来消除开发中的不确定性。

       在敏捷开发时,我们不应该为了让自己的项目看起来像是按照计划好的样子循序渐进,而花费大量的时间让研发团队去附和计划。相反,敏捷需要的不是计划,而是规划。

       敏捷开发方法是“规划-执行-调整”、“规划-执行-调整”。一个项目的不确定性越高,敏捷开发方法对取得成功就越是至关重要,不断学习和调整是敏捷开发的核心。

       像3355中5会那样,计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。阶段性的召开会议,提出当前阶段的问题,根据昨天完成的情况来做出新的调整,根据上一个迭代对新的迭代功能等进行规划。在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。

敏捷开发的12条原则包括: 
1.通过早期和连续型的高价值工作交付满足“客户”。 
2.大工作分成可以迅速完成的较小组成部门。 
3.识别最好的工作是从自我组织的团队中出现的, 
4.为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。 
5.创建可以改善可持续工作的流程。 
6.维持完整工作的不变的步调。 
7.欢迎改变的需求,即时是在项目后期。 
8.在项目期间每天与项目团队和业务所有者开会。 
9.在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。 
10.通过完成的工作量计量工作进度。 
11.不断地追求完善。 
12.利用调整获得竞争优势。

大致来讲,12宣言的核心内容就是将一个软件分成多个迭代去完成,在每个迭代开发时,坚持以人为本的原则,在研发过程中坚持人比工具更重要。在研发中坚持完善工作,拥抱市场拥抱变化,根据市场来调整软件的功能。快速变化,高效的做出响应。不断地调整软件,保持市场时效性。

       

       

 

2011-04-24 09:25:00 cheny_com 阅读数 2403
  • SCRUM敏捷开发视频教程

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

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

       作者:陈勇

       出处:blog.csdn.net/cheny_com

      

自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。

从大的方面看,敏捷开发具有重视客户价值,提倡持续交付等思想。但一般而言,Product Owner常常具备相当好的客户价值意识,而一线开发人员则比较关注技术本身,所以一旦仅仅停留在思想层面,在实际工作的时候就会发现有所背离。因此应该从自相似性的眼光看待敏捷开发的整体思想与局部实践,从而做到年年月月日日事事均符合敏捷开发的思想。

本文只从“持续交付”这一个敏捷开发思想来分析敏捷开发的自相似性。

“持续交付?是不是就是每个冲刺结束都要有一个可运行的版本?”是,也不是。

 

冲刺末尾的持续交付

敏捷最大的特色之一,就是阶段性地交付可运行的软件,而不是一堆暂时无法使用的文档。按照精益生产的思想,文档只是一种“中间产物”,不但不容易写好,还很难评审;即使在初期看到了完美的需求文档,也很难保证最后能看到完美的软件。因此敏捷开发决定只要可能(不是绝对的),就尽量绕开这个中间产物,而用可运行的软件来表明软件的进度和质量。

在冲刺的末尾,Product Owner和干系人们不是看着文档,而是看着一个可运行的软件进行评审,是这里持续交付的核心目的。为了方便评审,被交付的往往是一组相关的故事群,而不是“当前最重要的需求”。

 

冲刺内的持续交付

冲刺期内看平静,大家忙忙碌碌只待最后交付,其实不然。如果每个迭代都始自“需求分析”而终于“系统测试”,敏捷开发就变成迭代开发了。然而即使每个用户故事都独立开发,仍可能发生一堆故事都在“开发中”,但因为这些故事无法独立成章因而无法形成可运行软件的状态。为了防止这种情况,好故事一般都独立、可测试、完整地交付某个客户价值,因而每当完成一个故事,都能形成一个临时的可运行软件。

若能遵循MoSCoW方法(另有博文详述),则可以保证即使冲刺结束时无法完成所有Sprint Backlog项,仍能向Product Owner交付一个可用的软件。

 

“日创建”的持续交付

“日创建(Daily Build)”因能在每天结束时都能交付软件而闻名(这是微软在开发Windows时的创举),但对于小型软件开发,已经能做到每人每次提交代码在10分钟后就能看到结果的能力。1000人在开发了1000天的软件里边定位1000000个缺陷是不可思议的(平均111个缺陷),但每人在自己每天的代码中定位一个缺陷却是很现实的,前提是你能找到它,日创建就是这个逻辑。

一般常常提到的持续集成+自动化测试指的就是这个层面的持续交付活动,其目标是在提交代码后最短的时间内形成可运行软件,并确认是否存在问题。

 

版本间的持续交付

很多软件看似越来越强大,但市场反响却并不好(比如很多人安装的“免费”Office都是2003的,也就是7年间完全没有和MS做生意的打算),原因就在于这些软件并没有解决好一个问题:“下个版本到底面向哪个市场的哪类客户?他们为什么购买它?”这时软件很容易跟随公司领导的思绪梦游,或者被一两个大客户牵着鼻子走,或盲目地试图覆盖竞争对手的所有功能而迷失本性。

还是之前那句话:按照商业步调计划版本内容,也就是每个版本出来后,都要满足某些需求、获取某些客户、打败某些对手、取代某些产品……如果能持续找到这些“某些”是谁,那么下一个版本就能成功,如果找不到,兴许产品已经到达退出市场的阶段。如果不能持续找到市场和客户,怎样持续交付可运行的软件都是一件没有意义的事情。

 

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

 

2019-09-29 15:34:43 heibuliuqiu_gk 阅读数 27
  • SCRUM敏捷开发视频教程

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

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

敏捷开发,在百度上这样介绍的:

敏捷软件开发(英语:Agile software development),又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法,是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

敏捷开发宣言如下:

  • 个人和他们之间的交流胜过了开发过程和工具。
  • 可运行的软件胜过了宽泛的文档。
  • 客户合作胜过了合作谈判。
  • 对变更的良好响应胜过了按部就班地遵循计划。

敏捷原则如下:

  • 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
  • 即使是开发的后期,也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
  • 经常交付可运行的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  • 围绕有积极性的个人构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最富有效果和效率的信息传递方法是面对面交谈。
  • 可运行软件是进度的首要度量标准。
  • 敏捷过程提倡可持续的开发速度。负责人、开发者和用户应该能够长期保持稳定的开发速度。
  • 不断地关注优秀的技能和好的设计会增强敏捷能力。
  • 简单——使不必做的工作最大化的艺术——是必要的。
  • 最好的架构、需求和设计出自于自组织团队。
  • 每隔一定时间,团队会反省如何才能更有效地工作,并相应调整自己的行为。

首先需要明确,敏捷开发不是一个具体的框架或者过程,也不是软件开发的具体方法,而是一种价值观和原则,因此敏捷开发是不可模仿的。每个不同的团队都会在开发软件的工程中根据敏捷开发的价值观和原则去做适合自己团队的决策。

敏捷开发是一个不断迭代的过程,需要具有极强的适应性,简洁性和完整性。敏捷团队也需要是一个高度自主的团队,团队中不会存在“打酱油”这种人,团队中每个人都有极强的个人能力,同时,他们每个人还必须具备良好的沟通合作能力。在做决策时,每个团队都要遵循敏捷开发的价值观和原则,而不是去模仿其他的团队,即:“他们怎么做不重要,重要的是明白他们为什么这么做”。

2015-03-10 17:31:48 MeAmI 阅读数 354
  • SCRUM敏捷开发视频教程

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

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

敏捷开发

简介:敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。

组成方法:敏捷开发由几种轻量级的软件开发方法组成,它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等。

敏捷开发介绍—极限编程XP:

(1)主要目的是降低需求变化的成本

(2)定义了一套简单的开发流程

(3)核心做法:
小规模,频繁的版本发布,短迭代周期。
测试驱动开发(Test-driven development)
结对编程(Pair programming)
持续集成(Continuous integration)
每日站立会议(Daily stand-up meeting)

敏捷开发原则和方法:

(1)迭代式开发:即整个开发过程被分成几个迭代周期,每个迭代周期是一个定长或不定长的时间块,每个迭代周期持续的时间一般较短,通常为一到六周。
(2)增量交付:产品是在每个迭代中欧其结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。
(3)开发团队和用户反馈推动产品开发:敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
(4)持续集成:新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

(5)开发团队自我管理:拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。


2019-10-22 11:54:24 tianxintiandisheng 阅读数 24
  • SCRUM敏捷开发视频教程

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

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

敏捷软件开发,又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

一、story讲解

  1. 制作竞品分析PPT,UE全组参与。(用时:根据产品复杂度,0.5-2小时之内)
  2. 制作产品原型,交由客户看,客户没有异议之后禅道录入story
  3. 产品在禅道拆分好story,并且定义出优先级,关联需求,后续开发根据优先级进行开发
  4. 由产品讲解story,前端和后端都参与。(用时:根据产品的复杂度,1-3小时之内)

二、人员划分

  1. 新建wiki项目主页,把PPT和产品原型(HTML文件)上传到wiki
  2. 根据产品原型,按照模块划分相关负责人,前端和后端都是,并放到wiki。(由项目负责人新建)

三、定义接口文档(2-3天)

  1. 前端后端相关人员一起,对照原型,根据模块及页面大概定义出接口
    • 一个页面中有几个接口,每个接口入参与出参是什么
  2. 后端每个模块的负责人,根据开会讨论的结果,在wiki上生成标准的接口文档
  3. 将后端做好的接口文档发给前端模块负责人过目,有问题继续修改;没问题开始后续的步骤 。

四、方案设计(1小时-1天左右,根据模块大小定义时间)

  1. 后端开发人员,根据原型以及定义的接口,做好方案设计
  2. 对有难度或者有疑点的接口,做出方案,尽量给出多个合理方案
  3. 每个方案写清楚优点缺点

五、方案评审(2-3小时)

  1. 对做出的方案设计,做方案评审,建议全体人员参与(无论做不做该项目)

六、禅道拆分(1-2小时)

  1. 相关负责人按照优先级顺序,在禅道拆分自己的任务,单个任务最多不要超过4小时,即拆分要详细

    • 拆分一个task时,以具体写的代码为一个task,并在任务名称中写出该类/方法的名称在任务描述中写出该task的代码块具体有的功能
    • 当拆完task后,这几个task所完成功能的代码已经过了一遍
    • 如果有不了解的功能,在方案评审前先写出一个demo,以方便拆分task的估时
    • 一个task用时应在0.5-2之间,最大最大4个小时
  2. 以文件上传功能为例,分成3个task

    • task1.任务名称:公共模块-文件上传-上传文件controller的方法fileUpload
      任务描述:通过网页获取文件,文件判空,判断文件的归属类型(用户/教材/课时/步骤/咨询)
      工时:1
    • task2.任务名称:公共模块-文件上传-添加文件FileUtil 和FileUtilOssImpl
      任务描述:util处理上传的文件,判断文件类型,大小,设置文件上传的路径,返回的url
      工时:1.5
    • task3.任务名称:公共模块-文件上传-文件接口spring-fileOss.xml 配置文件
      任务描述:oss的文件上传, 调用的spring.xml配置文件(密匙,ID,bucket等)
      工时:1.5

七、开发

  1. 搭建开发服务器
  2. 开发人员根据禅道上的任务,按时完成自己的开发工作,具体体现到日报上
  3. 每天上午开10分钟左右进度会议,如果有延迟现象出现,拿出解决方案,保证项目按照禅道上的时间点完成
  4. 数据库索引(两种索引):
    1. 经常查询的,数据散列度比较高的,做一般索引,不需要建联合索引。
    2. 数据必须保持唯一的,建唯一索引。(要有文档,文档表明哪些字段要建索引。发邮件。)

八、阶段测试

  1. 每天至少发布一次代码到开发环境,并且保证发布完之后程序没问题(与开发并行)

九、性能测试和coderevivew(1天)

  1. 对每个接口做好性能测试
    • 每个接口的响应时间不超过200ms,如果有超过的,做优化,尽量缩小到200ms内
  2. 完成codereview,根据codereview结论完成修改

十、压力测试

  1. 做好压测报告

十一、 Demo

demo

  1. 发demo申请邮件,收件人包括产品、测试同学、前后端相关开发人员
    1. 主题:XX项目demo通知
    2. 内容:时间 地点 参会人员
  2. 开demo会议:主讲人:某个开发人员
    • 会议途中产品和测试提出问题
  3. 发demo结果通知邮件(由产品同学发)
    1. demo结果
    2. 如果不通过,有哪些问题
  4. 如果不通过,召集第二次Demo会议,知道通过为止。第二次会议只需演示之前不通过的部分

测试

  1. demo通过之后
  2. 开发人员对代码打tag(参考文档: 如何打tag 。)
  3. 开发人员部署测试环境,部署完成之后发邮件,写明域名;
  4. 交给测试人员进行测试,测试人员发送全体测试周期邮件
  5. 测试期间,如果有测试发现bug,会在禅道上面提出bug,禅道会发送邮件到各自开发人员的邮箱,开发人员要关注BUG邮件 ,及时确认BUG,及时修改
  6. 修改BUG之后,开发环境前端代码由前端同学自己部署,后端代码由后端同学自己部署
  7. 测试完成之后,测试或产品发送上线通知
    具体参看: 测试Bug划分及处理流程
    测试和线上环境发布流程: 测试及线上环境发布流程

十二、 发布测试环境、集成测试(2-3天)

  1. 禅道上建立bug,测试出bug,指派给相关人员修改

十三、发布线上环境,同时停止开发环境和测试环境

十四、线上监控

  1. 错误报告

敏捷开发简介

阅读数 217

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