Scrum
2015.04.28
wangsong
Outline
• 基本概念
• Scrum开发模型、角色、流程
• 背后的原则
• 总结
敏捷开发
• 一种以人为核心、迭代、循序渐进的开发方式
• 主要驱动核心是人
• 它采用的是迭代式开发
• 它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,
它会指导我们用规定的环节去一步一步完成项目的开发
• Scrum和XP是敏捷开发的具体方式
迭代
• 迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周
期可完成的任务,这样的一个周期就是一次迭代的过程;
• 同时每一次迭代都可以生产或开发出一个可以交付的软件产品
Scrum
• 橄榄球运动的一个专业术语 – 并列争球
• 是一个经验性的开发流程,运用该流程,你就能看到团队高效工作。
• 与传统开发过程相比,Scrum引入了一个根本性变化 —— 在每个
固定长度的迭代周期(spirnt)产出潜在可交付的产品增量
角色
• 开发团队(Scrum Team)
• 产品负责人(Product Owner)
• 流程管理员(Scrum Master)
Team – 团队
• 团队负责产品交付,规模一般为 5~9人;
• Scrum强调团队的多功能(cross functional)和自组织。
• 成员可以采用任何工作方式,只要能达到Sprint的目标。
Product Owner – 产品负责人
• PO 负责把握产品的方向,包括需求的收集、定义,优先级设定等。
PO通过这些活动以及和团队的合作,最终确保产品的交付。
Scrum Master – 流程管理员
• ScrumMaster并不直接负责产品交付,它向团队负责,确保团队按
照Scrum的框架工作,具备良好的外部和内部工作环境,顺畅地交
付产品,并不断的改进,提升交付的效率和质量。
• 与传统意义上的管理者不同,ScrumMaster更多是起服务、协调和
引领的作用。
开发流程
1、确定一个Product Backlog(按优先顺序排列),PO负责
2、根据Product Backlog列表,做工作量的预估和安排, Scrum Team 负责;
3、通过 Sprint计划会议从中挑选出一个Story作为本次迭代完成的目标(1~4星期),
然后把这个Story进行细化,形成一个Sprint Backlog;
4、每个成员根据Sprint Backlog再细化成更小的任务(2天内能完成);
5、Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,SM召集
6、Srpint Review Meeting(评审会议),产品负责人和客户都要参加(最好老板也
参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品
7、Sprint Retrospective Meeting(回顾会议),以轮流发言方式进行,每个人都要
发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
Why
• 如此简单的框架如何能提升组织的能力?
• 做到什么才能保障Scrum实施的成功,并从中受益?
理解和贯彻Scrum背后的原则是关键
• 产品开发过程相关的原则
– 高度透明
– 不断反馈调整
• 团队组织相关的原则
– 多功能
– 自组织
• 持续改进相关的原则
– 将改进嵌入开发过程
– 不断暴露和解决问题
产品开发过程相关的原则
• Scrum的产品开发过程是高度透明和不断反馈调整的自适应过程;
• 透明(transparent)、检验(inspect)和调整(adapt)是它的三个支柱。
• 共同的迭代和增量开发框架为开发过程的透明提供了统一的基准:
– Product backlog反映了用户需求,以及它们的开发工作量、优先级和当前状态;
– Sprint backlog反映了sprint的目标、工作任务和当前状态;
– 发布燃尽图反映了项目的整体工作进展状态;
– Sprint燃尽图反映了当前sprint的进展状态
– Scrum的四个标准活动(event) —— sprint 计划会议、每日Scrum 会议、sprint评审和
sprint回顾进一步促进了透明。
– 良好的沟通促进透明。团队面对面的交流是最高效的沟通方式;有效的会议组织能改善计
划、评审以及回顾活动的效果;
– 一个良好的可视化工作空间(如白板)促进信息的发布和交流
Scrum开发过程中应该不断反馈调整
周期性的检验和调整
• Scrum框架中包含多个检验和调整的反馈循环:
1. 每日Scrum会议上团队检验工作进展,和sprint目标进行比较,调整接下来的
工作以更好地达成目标;
2. Sprint评审会议上,团队演示软件,获取业务人员和客户的反馈,及时调整产
品的方向以及开发计划。
计划 构建软件 演示,交付增量
用户/干系人反馈
回顾改进计划 反思
产品的检验与调整
开发过程的检验与调整
需求和计划调整
Sprint 循环
团队应该是多功能的
• 多功能是指团队具备为客户提供端到端服务的全部技能,对于Scrum团队这意
味着有能力完成从需求分析到交付产品的所有工作。
• Scrum 团队尽可能长期存在,一个团队从成立到高效运作需要一个过程,能
力的拓展、团队的磨合、技术实践的优化、基础设施的完善都需要时间。
团队应该自组织的
• 自组织团队是指,由团队而不是管理者决定“怎么做”。Scrum团队被赋予并
承诺组织目标,计划、执行和监控的职责则属于团队。
• 团队的自组织需要特定的边界,团队在边界之内充分自主。没有边界约束的自
组织,很难确保其在执行上与组织目标的一致。
• 良好的组织环境支持
– 面向团队而非个人的奖励和认可机制、
– 面向结果而非过程的绩效体系、
– 简单扁平的组织结构、以及充分的授权机制
持续改进相关的原则
• Scrum实施中暴露并解决问题
– Scrum象丈母娘,她希望自己的女儿好,总是对女婿不满意,不断挑他的
毛病,却从来不提供改正方案
– Scrum暴露问题,却不提供解决方案,因为那是团队的责任。
– Scrum是一个有意为之的半成品。
改进的原则
• 持续改进是Scrum框架的有机组成部分,Scrum 实施能更好地暴露组织中存在的问题,解决
这些问题是Scrum成功实施的保障,也是组织能力提升的关键
• 检验和调整针对的不仅是产品,团队还应经常对开发过程本身进行检验和调整
• 让团队成员,积极参与改进的过程. 每次聚焦有限的改进项目
• 找到深层次的原因
• 检验改进效果
• 永远不要放弃改进的努力
总结
• 通过Scrum实施暴露问题,然后解决它们,这是Scrum引领团队成
功的不二法门,这需要团队的勇气和智慧
最后
• 掌握自己的命运。
– 作为一个强调经验性过程的框架,在Scrum框架的基础上,组织需要探索适合自身的实施
过程,掌握自己的命运!
• Scrum实施策略需要考虑所处阶段: 日本剑道- 守、破、离
– 守是模仿,遵循,是无我的过程;
– 破是变,是自我意识逐渐增强,心智逐渐收缩的过程 ;
– 离是返朴归真, 是忘我的过程。
• 改变,但非常值得
– Scrum 框架非常简单,但简单不等于容易。
– 观念的转变,权力的重新分配,技术实践的配套,基础设施的优化等。
– 改变是困难的,过程是痛苦的,但非常值得。
Scrum Agile Development

Scrum Agile Development

Editor's Notes

  • #4 敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,
  • #9 多功能指的是,团队应该整体具备各个职能所需的技能,如系统,开发和测试技能,同时也具备各个组件的技能如数据库设计、协议开发和UI设计等。团队的多功能是短迭代开发的基础,只有做到这一点,独立的团队才可能在一个sprint 中交付对用户有意义的产品增量。目前的团队缺少专门的QA 自组织指,在目标清晰的前提下由团队自主决定完成目标的具体方法。
  • #12 4. 任务是自己去认领的 5. 每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什4么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的Sprint燃尽图; 6. (这个会议非常重要,一定不能取消); 重点是 拆—迭代—反馈 可视化 任务看板
  • #13 参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。
  • #15 项目都会延期? 理解和贯彻Scrum框架背后的原则是关键。 通过Scrum实施暴露问题,然后解决它们,这是Scrum引领团队成功的不二法门,这需要团队的勇气和智慧
  • #16 拆 – 利于迭代、调整、暴露问题
  • #18 在传统开发过程中,团队根据目标制定计划,而后严格按照计划执行以达成目标,这是所谓定义性的开发过程。然而计划可能不合理,执行过程可能出现偏差,这都会使结果偏离预设的目标。即使计划被完美的执行,目标本身也会发生迁移,实际的业务目标和最初的设想总会有差距。
  • #22 如果团队为了完成一个工作要严重依赖其它部门,就无法实现真正的短迭代交付;为了做到团队的多功能,组织需要跨职能指团队具备承担系统分析、架构、设计、开发和测试等工作的全过程能力;跨组件指团队具备完成开发工作所需各个组件的知识,如UI,中间件,底层驱动等 Scrum 团队尽可能长期存在,而不特定项目或开发版本成立和解散,长期存在的团队才有长期的承诺,形成对目标的认同和坚持,并激发不断改进的动力。 是随着
  • #23 2. Sprint周期是时间边界;Product Backlog是范围的边界;完成标准定义是质量的边界.有了边界的约束,可以建立外面的人对团队的信心和安全感;
  • #24 这恰恰是Scrum的生命力所在,维持了Scrum的简洁和包容性;这也是Scrum的陷阱所在,它可能误导使用者低估Scrum实施的难度,而事实上它却对组织和团队提出了很高的要求。
  • #25 回顾是为了改进开发过程,而不是针对任何个人。一个被少数人主导的回顾会议,很难达到期望的效果,创造一个安全开放的氛围,让每一个人都积极参与改进过程,是确保其有效的前提
  • #27 初始实施时,严格遵照Scrum框架进行 在实施过程中加深对Scrum原则的理解,在此基础上考虑创新突破 当对这些原则把握自如时, Scrum的形式就不再重要了 各种需求变更、线上问题等 其实由于大环境所迫,国内绝大多数公司里是无法实施原生态的Scrum,只有真正理解了敏捷背后的意义,才能不拘泥于形式,达到怎么做都是敏捷的境界