2013-07-23 16:48:00 dingbenji5337 阅读数 1
  • SCRUM敏捷开发视频教程

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

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

1.  请简述一下什么是敏捷开发(Agile Development),以及什么是持续集成。 

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

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚软件

2.  你所知道的敏捷方法有哪些?请至少列举出3

Scrum、极限编程(Extreme Programming,XP)、Crystal、动态系统开发方法、功能驱动的开发方法和Lean软件开发

3.  Scrum开发流程中的3种角色分别是什么?这3种角色分别承担什么职责? 

产品负责人(Product Owner)

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

流程管理员(Scrum Master)

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

开发团队(Scrum Team)

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

4. Scrum中如何实现一个Sprint *

1、Scrum计划会议
    在每个Sprint开始之前,需要召开Sprint计划会议,会议时间一般为4~8小时,参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人,比如管理人员和客户代表。
    Product Owner从产品Backlog中挑选高优先级的任务,并与Scrum团队一起决定在这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何能按需求完成这些功能模块,并估计完成每个功能模块所需的大概时间。
2、每日Scrum会议
    每日Scrum会议(Daily Scrum),即团队每日例会,条件允许的话,每天都应该在同样的时间和地点,组织所有成员站立举行。由于是以站立的状态开会,因此时间比较短,一般为 15分钟左右。这个会议最好是在每天的清晨开,有利于团队成员安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言,其他人员如果对项目进度有兴趣也可以参加,但只能旁听而不能发言。
3、Scrum评审会议
    Sprint评审会议在Sprint结束时召开,由开发团队展示这个Sprint中完成的功能,长度为两个小时左右,不需要PPT,一般是已经完成功能的Demo,而客户、管理层、ProductOwner以及其他开发人员等都可以参加。
    在Sprint评审会议上,Scrum团队用Demo的形式展示产品的功能之后,与会人员依据在Sprint计划会议上确定的这个Sprint的目标来评审具备了这些新功能的产品。
4、Scrum回顾会议
    Sprint回顾会议由产品责任人、Scrum团队和Scrum Master参见,会议中需要讨论:有哪些好的建议或方法应该被采纳;在Sprint中有什么做法不可取;有哪些做法效果很好,应该继续下去。
    Sprint结束后,Scrum团队回顾刚结束的Sprint,对其进行总结和反思,使整个团队能持续成长。总之,Sprint回顾会议的宗旨就是:Scrum团队如何在下一个Sprint中做得更好!

 

 

参考:

http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

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

http://www.cnblogs.com/zgqys1980/archive/2011/01/04/1925776.html

转载于:https://www.cnblogs.com/saysmy/p/5594878.html

2017-05-03 15:25:00 weixin_30488085 阅读数 3
  • SCRUM敏捷开发视频教程

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

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

什么是敏捷开发?

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

 

为什么说是以人为核心?

我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

 

什么是迭代?

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

【Scrum开发流程中的三大角色】

产品负责人(Product Owner)

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

 

流程管理员(Scrum Master)

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

 

开发团队(Scrum Team)

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

 

什么是Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

 

如何进行Scrum开发?

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

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

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

4、Sprint Backlog是由Scrum Team去完成的,每个成员根据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的产品需求中;

 

 

 

下面是运用Scrum开发流程中的一些场景图:

转载于:https://www.cnblogs.com/yangyl-justdoit/p/6802111.html

2019-01-07 22:16:56 SystemEngineeringLab 阅读数 67
  • SCRUM敏捷开发视频教程

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

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

更多请关注微信公众号 SystemEngineeringLab
SystemEngineeringLab

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Scrum是一种敏捷过程框架,不同于其他敏捷开发方法,Scrum不仅仅适用于软件开发领域。

1. Srum 的目标

Deliver the highest business value in the shorttest time

Scrum的目标是“交付最高的商业价值,通过尽量短的时间”。用英文表达可能更准确一些,中文的语义比较容易混淆。Scrum的目标并不是“在最短的时间内交付最高的商业价值”,它强调的不是最短的时间,而是价值。我们关注的是如何在交付最高价值的前提下花费更少的时间。

2. Scrum 框架的组成(3-3-5-5 模型)

3 个工件

Product Backlog
Sprint Backlog
Product Increment

3 个角色

Product Owner
Scrum Master
Development Team

5 个价值观

勇气 专注 承诺 尊重 开放

5 个事件

Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective

2.1 价值观

勇气:面对难题团队成员都有勇气做正确的事情和工作
专注: 团队成员要专注于冲刺要完成的工作以及团队目标
承诺: 团队成员对完成Sprint目标做出承诺
尊重:团队成员之间都尊重对方是有能力的、独立的人
开放:Scrum团队以及利益相关者对所有的工作以及完成工作所面临的挑战的开放性一致认同。

2.2 角色


Scrum核心框架包含三个角色,即PO、SM、DevTeam。与传统的开发方法不同,Scrum的研发团队不再有细分的例如系统架构师、后端工程师、前端工程师、UI工程师等角色,而是将整个开发团队统一在了“Development Team”这一Scrum角色下。以上三个角色构成了 “Scrum Team”。

Product Owner

关键职责

  1. 为Product Backlog负责
  2. 为投资回报率负责
    关键属性:
  3. 是利益相关者和客户的代表
  4. 只能由一个人担任
  5. 有绝对的决策权
  6. 随时能够被团队找到
  7. 决定产品发布日期和内容
  8. 不能兼任Scrum Master
  9. 根据业务价值和重要性为PBI排序
  10. 能够决定Sprint是否取消

Scrum Master

职责

  1. 促进Scrum的进行,为开发团队移除障碍
    特征:
  2. 没有权利
  3. 服务型领导

Development Team

职责
DevTeam的职责就是实现Sprint目标,在每个Sprint结束交付可潜在发布的产品增量。
特征:

  1. 自组织
  2. 跨职能:团队是跨职能的,具备交付产品所需要的所有能力
  3. 同地协作
  4. T型人才,成员具备“一专多通”的特点
  5. 没有头衔,大家都是平等的团队成员
  6. 开发团队的成员必须是全职参与
  7. 人数范围3-9人:人数不宜过多或过少。过少的团队无法具备跨职能的要求,过多的团队降低沟通效率
  8. 没有子团队:团队是平级团队,子团队增加了沟通的成本

2.3 工件

产品清单 - Product Backlog

Product Backlog是已排序的产品需求列表,它定义了最终要交付什么(What)。

Product Owner 对Product Backlog负责,其有权决定产品清单的内容,例如哪些需要纳入产品清单、哪些需要修改、哪些需要删除、哪些PBI(Product Backlog Item)优先级需要调整。大多数的PBI对客户有实际的业务价值,有些可能针对客户来说没有直接的业务价值。原则上PO认为PBI对整个产品的交付是有价值的,那么它也可以放入PBL.
PBI最常见的表述形式是用户故事,但这不是绝对的。用户故事本身不是Scrum框架的一部分,Scrum并没有要求PBI的表现形式,用户可以使用用户故事、用例或其他有意义的格式均可。
好的Product Backlog遵循 DEEP 原则

Detailed appropriately - 详略得当

  1. PBI的表述要详略得当,近期要做的PBI要足够详细,以便团队能够清晰的认识需求。同时,PBI的粒度要足够小,能够放到一个冲刺中执行。
  2. 越靠近PBL顶端的PBI要越详细且粒度越小,越靠近底部的PBI粒度越大。

Emergent - 涌现式的
产品清单是动态的,随着对产品认识的深入,以及产品内外部环境的变化,已有的PBI可能会被修改、废弃,新的PBI会被加入到产品清单,因此,PBL是一个会被持续更新动态需求池。

Estimated - 已估算的

Prioritized - 已排序的

Sprint Backlog

SBL是在当前冲刺中开发团队需要完成的工作任务列表,有点像传统开发方法中的WBS,这是DevTeam对实现PBI所做出的承诺。在冲刺计划会议中,DevTeam要对当前迭代所选择的PBI进行任务拆解,细化为具体的工作任务,足以支撑实现这些PBIs。
Spring Backlog的形式有多样,可以采用看板、电子表格或专门的在线系统进行记录和追踪。同时,拆分后的任务和PBI的对应关系也要一同记录

产品增量 - Product Increment

Potentially Shippable Increment,PSI
冲刺中所完成的所有的PBI的总和,在冲刺结束时作为产品增量交付。增量是稳定的、可工作的产品组成部分。冲刺中没有完成的部分不纳入增量。

2.4 事件

冲刺 - Sprint

Spring的目标是完成可潜在可交付的产品增量

  1. Scrum的核心,也是Scrum开发方法中的基本单元
  2. 固定的时间盒
  3. Sprint是一个容器,以冲刺计划开始,以冲刺评审和冲刺回顾结束

冲刺计划 - Sprint Planning

  1. 确定当前冲刺所要完成的工作范围
  2. 从Product Backlog中选择当前冲刺需要完成的PBI
  3. 确定Sprint Backlog,以支撑所选的PBIs
  4. 以两周的冲刺为例,建议会议时间为4小时

每日站会 - Daily Scrum

  1. 开发团队成员必须到场,PO 和SM可选参加
  2. 欢迎其他人参加每日站会,但只允许开发团队成员发言
    • 每天同一时间、同一地点
    • 准时开始,即使有开发团队成员缺席
    • 控制在15分钟以内
  3. 会议模式基于三个问题:
    • 昨天完成了什么
    • 今天准备完成什么
    • 遇到了什么障碍阻碍了自己或团队达成冲刺目标

冲刺评审 - Sprint Review

评审的目的并不在于评价已完成产品增量的好坏,更不是在没有达到既定要求时的批判和追责。评审的本质在于通过现场的交流和演示,获得利益相关者对产品增量的反馈!反馈!反馈!
主要内容:

  1. 审视已经完成的工作以及已经计划但是没有完成的工作
  2. 向利益相关者展示已经完成的工作(Demo)
  3. 与利益相关者协作,进一步明确后续要做的工作

冲刺回顾 - Sprint Retrospective

回顾会议的精髓在于检视和调整,以期持续改进:

  1. 回顾已经过去的冲刺
  2. 识别持续改进的行动项并达成一致
    典型的会议内容:
  3. 三个主要问题:
    • 在当前冲刺中,哪些做的好?
    • 在当前冲刺中,哪些做的不好?
    • 为了提高生产力,在下一个冲刺中哪些需要改进?
  4. 以两周的冲刺为例,建议时间为一个半小时
  5. 回顾会议由SM负责推进

Scrum工作流

Scrum的工作流以Sprint为核心,通过迭代和增量的方式逐步完成最终产品的交付。

  1. 产品需求被汇总到Product Backlog,PO依据业务价值、重要性等对PBI进行排序。
  2. 冲刺会议标志着Sprint的正式开始,团队对输入的PBL进行选择,确定本次冲刺所需要完成的PBI。DevTeam基于所确定的PBI进行任务拆分,形成Sprint Backlog。
  3. DevTeam执行开发过程,交付潜在可发布的产品增量。

讨论

Scrum不是具体的敏捷方法,它通过价值观、角色、工件和事件等要为我们搭建了一个骨架,但骨架内填充的内容就需要具体情况具体分析了。

同其他敏捷开发方法不同的是Scrum更具有普适性,它不仅仅适用于软件开发领域。
本文主要是对Scrum框架的核心元素进行了总结和记录,理论看戏去简单,但落地Scrum却不容易,尤其是结合不同行业的工程实践更加导致Scrum落地的复杂性,而这也恰恰是Scrum实践者所需要攻坚的问题。

写在最后

这已经是关于敏捷的第二篇博文了,基本上对敏捷和Scrum做了基本的介绍,后续的博文我们更关注如何在汽车行业中实施敏捷。

2018-11-01 13:43:19 yuezisonghao 阅读数 88
  • SCRUM敏捷开发视频教程

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

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

scrum是一个开发和维护复杂产品的管理框架,是一个增量的,迭代的开发过程。整个开发过程分为若干个迭代周期,每个迭代周期称为一个sprint,一个sprint周期一般是1到4周,相对于传统的瀑布式开发(需求-设计-开发-测试),项目失败的概率更低,可控性更高。

基本概念

三个角色(Role):

产品经理:Product Owner

项目经理:Scrum Master

项目团队:Scrum Team

scrum的基本流程如上图所示:

  • 产品经理负责整理user story,形成product backlog。
  • 发布(冲刺)计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。
  • 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,终每个任务都有明确的负责人,并完成工时的初估计。
  • 每日例会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
  • 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
  • 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。

参考:https://www.zentao.net/book/zentaopmshelp/65.html

2019-05-16 19:19:00 weixin_44818729 阅读数 47
  • SCRUM敏捷开发视频教程

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

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

git的分支管理策略
git-flow - 运维比较复杂(两个长线分支+三个短线分支)
github-flow - 无冲突合并

  1. 克隆代码到本地(git pull更新代码)
  2. 创建自己的分支(绝对不能动master分支)
  3. 在自己的分支上实施本地版本控制
  4. 将自己的分支push到服务器
  5. 在线发起合并代码请求(pull request)

敏捷开发 - Scrum

过程模型
传统/经典过程模型 - 不能够拥抱需求变化
可行性分析 - 做还是不做 - 可行性分析报告
需求分析 - 做什么
~ 需求规格说明书
~ 产品原型(产品经理)- Axure RP / Sketch / Briefs
~ 设计稿(标注 - UI/UE)- Markman
概要设计/详细设计
~ 数据库设计 - ER图(概念模型图)- 物理模型图
~ OOAD(面向对象分析和设计)- 用例图/类图/时序图 - UML
PowerDesigner / StarUML / Enterprise Architect
编码/测试/调试
验收/交付/维护

16627003-ae6a2c2a19cff1fe.png
image.png

用例图(Use Case Diagram)

16627003-2de67bca4aa41dc2.png
image.png

类图(Class diagram)

16627003-49646744775c72b6.png
image.png

时序图(Sequence Diagram)

资料领取方式见评论。

博文 来自: qq_32423845
没有更多推荐了,返回首页