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