2019-05-11 19:34:29 jnshu_it 阅读数 1602
  • SCRUM敏捷开发视频教程

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

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

这里是修真院后端小课堂,每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析后端知识/技能,本篇分享的是:

【什么是敏捷开发流程 】

这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
一. 先说一下官方的定义:

敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

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

  2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

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

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

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

二. 然后是我理解的敏捷

主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

Story划分(产品+UI+开发)
产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

人员划分(leader+开发)
主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

方案设计(数据库设计文档、接口设计文档、方案设计文档)
先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

方案评审(所有人员)
对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

禅道任务拆分(开发人员)
方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

开发(项目日报+工作日报+进度邮件)
每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

端对端(接口)测试(开发人员)
前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

压力测试+集成测试
系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

Demo
对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

 

 



 

【欢迎加IT交流群565763832与大家一起讨论交流】

2017-05-01 14:17:41 ogreworld1987 阅读数 2393
  • SCRUM敏捷开发视频教程

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

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

1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由ProductOwner 负责的;

2Scrum Team根据Product Backlog列表,做工作量的预估和安排;

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

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

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

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

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

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

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

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

    10426 人正在学习 去看看 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. 错误报告
2018-05-10 09:31:13 An1090239782 阅读数 3180
  • SCRUM敏捷开发视频教程

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

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



记录一些优秀的敏捷开发案例或经验:

敏捷开发:项目管理的一些思考
w_fsovereign:三个月(敏捷)项目收获
RobinsonZhang:敏捷开发入门



一、敏捷过程

敏捷开发是一种以人为核心,以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
在这一过程中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。
在2001年年初,一些业界专家成立了敏捷联盟,起草了敏捷软件开发宣言。该宣言针对一些企业的现状,提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则,其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

1.1 敏捷开发的价值观

  1. 个人和交互胜过过程和工具。
  2. 可以运行的软件胜过面面俱到的文档。
  3. 客户合作胜过合同谈判。
  4. 响应变化胜过遵循计划。

1.2 敏捷开发应遵循的12条原则

  1. 通过尽早的、不断地提交有价值的软件来使客户满意。
  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  3. 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。
  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  5. 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。
  6. 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。
  7. 测量项目进展的首要依据是可运行软件。
  8. 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
  9. 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。
  10. 简单是最根本的。
  11. 最好的构架、需求和设计出于自组织的团队。
  12. 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

敏捷组织提出的敏捷开发模型的整体框架主要有三个:
Scrum、XP(eXtreme Programming)、OpenUP 这3个敏捷实践。



二、敏捷开发的原则

  1. 凝聚人的力量,紧密协(合)作。包括业务负责人、开发团队、客户、管理者之间的关系,所有这些关系在以前都是造成项目危机的原因之一,那么,在敏捷时代,我们需要这些角色 紧密合作,最大限度的发挥各个角色的力量.
  2. 聚焦客户价值,消除浪费(如何聚焦用户价值,即频繁的交付用户可工作的软件,快速收到用户反馈)

2.1 敏捷团队运作机制

  1. 一个团队有自己的代办事项,对代办事项进行拆小。
  2. 按客户价值进行优先级排序,产品经理负责价值排序。
  3. 小而稳定,跨职能团队。
  4. 多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

2.2 关键的团队角色

  • 产品负责人
  • Scrum主管(流程主管)
  • 开发团队

2.3 产品负责人(Product Owner)

  • 负责管理产品backlog(代办事项)的唯一负责人
  • 代表客户/项目如责任人
  • 定义产品的所有特性
  • 负责产品的投入产出
  • 负责最大化产品和开发团队工作的价值

2.4 Scrum Master(流程主管)

  • 起到教练的职责,领导团队完成Scrum的实践以及体现其价值。
  • 排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。
  • 确保团队能胜任其工作,并保持高效的生产率。
  • 保护团队不受到外来无端影响

2.5 关键的团队活动

  • 每日例会:每日5分钟左右的一个简单例会,尽可能多的开发人员参与进来对紧要问题的讨论。
  • 评审会:需要在迭代周期的最后一天召开,1个小时左右就可以了,需要客户出席,如果客户不能出席,则需要产品经理出席
  • 迭代回顾会:迭代回顾会是在每个迭代结束时进行,总结工作中的经验和教训,时间维持在30-60分钟内,整个团队都需要参加(Scrum Master、Product Owner、开发团队以及客户)。迭代回顾会包括两部分,第一部分是定量分析,第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标,收集并评审迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。定性分析包含哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

敏捷开发
作者:木可大大

三、敏捷团队的五个约定

3.1 约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,
不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than
cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

3.2 约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

我和敏捷团队的五个约定

四、敏捷开发的前置条件

4.1 比较固定的流程,文档,需求

  1. 需求是控制稳定性的根本,对于需求一定是整体可控的,并且是可以由迭代内进行调整的,而不是定死的
  2. 流程是指什么时间什么人该做什么事是高效的,明确的
  3. 文档是指每个流程阶段具有可交付或者可查阅参考文档,不是口头或者个人评定。

4.2 可灵活调整,允许试错

  • 检查

检查是指在每天的站会中检查每个人的工作状态,是否能完成自己的任务,存在什么问题,完成效果如何。另外就是保证整体在每天的进度,是否有有整体效果,如果没有完成今天的整体效果,需要检查是否符合整体迭代。

  • 调整

调整是指检查发现迭代的进度或者外界环境发生变化时,及时调整当前迭代的开发任务,保证迭代最终产物的准确及时性变动。当然,这种变动是不允许太多的,一般情况下在需求没有做详细分析时,不接受;在当前有风险的情况下,撤销某些需求;其他情况不做描述。

  • 试错

正是由于检查以及调整的策略,保证了迭代的灵活性,我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点,如果实验成功则可以对外拓展;如果不行,可以快速切换方案。

4.3 问题场景&&错误认识

  • 一个团队闭关开发一个项目就是敏捷

正确理解:敏捷不等于闭关,只是可能坐一起效率更高,其倡导的是何时都可以发生沟通,并准备一白板可以随时讨论方案;敏捷团队质量以及效率高于一般团队;敏捷团队开发的是以迭代为单位,不是项目;

  • 有了任务细分,开发白板,站会就是敏捷

正确理解:任务细分、白板、站会都是其形式,关键还是其将迭代的内容进行细化,可执行化,用高频的沟通反馈提高开发、沟通、理解的效率。

  • 敏捷团队没有特殊前置条件

正确理解:前面有讲到敏捷对团队,需求,文档,流程,调整等都有比较完整的规定。

  • 敏捷团队做的事情没有差别性

正确理解:敏捷完成的任务具有明细化,分阶段性,可调整性。所以在开发相关任务时,也具有类似的特点。

  • 敏捷团队会完整完美的交付产物

正确理解:敏捷在迭代结束只交付该阶段的可交付产物,很可能不完整不完美,对于可交付也有不同的理解。

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

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

    10426 人正在学习 去看看 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的产品需求中。

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

敏捷开发流程总结

阅读数 179

敏捷开发思想

阅读数 558

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