敏捷Scrum如何实施
Scrum实施全网最全教程！！！
Scrum 作为最流行的敏捷框架，这些年已经得到广泛的流行。但是很多团队在落地Scrum的时候并不总是一帆风顺。
首先Scrum 虽然是不错的方法，但也并不是放之四海皆准，Scrum也有其适用的范围；其次，就算团队非常适合用Scrum 来进行开发，团队在落地的过程中也可能因为遇到各种问题而对Scrum 丧失信心。
下面就我们近百人团队5年实施Scrum 的经验、敏捷转型过程中的一些常见问题和要点进行分享。 本文就以下几个问题展开讨论：
- 什么样的团队适合实施Scrum？
- Scrum 框架构成
- 实施Scrum 的全流程
- Scrum 实施是否需要管理工具？好的工具有哪些？
- Scrum 落地的13个常见的坑
1. 什么样的团队适合实施Scrum？
通常来说，国内最常见的开发管理模式有四种：
- 敏捷开发
- 瀑布开发
- 看板（指精益看板）
- 混合模式
其中，Kanban（看板）对于需求变化非常快的项目更有优势，比如连一周的迭代都没办法保证的特性开发，或者属于支持/维护类的项目团队。此外，看板对于不喜欢对现状改变太大的企业，更加容易被接受。
而相对来说，对于那些有着清晰roadmap的特性开发团队，以便于按照固定的节奏提交价值增量，Scrum更加有完整的套路。
瀑布模型一般适用于需求在规划和设计阶段就已确定，且项目开发周期内需求没有或极少变化，对需求变更进行严格控制，例如航空航天、金融核心系统等；以及稳定的低风险项目（对目标、环境非常熟悉），规模小实现简单易受控的项目等特点的项目；
2. Scrum 框架构成及实施全流程
Scrum 框架包括：3个角色、3个工件、5个活动和5个价值观。
2.1 3个角色
- Scrum Master
作为 Scrum 流程的捍卫者和布道者，ScrumMaster在Scrum团队中起到至关重要的作用，他们确保团队使用正确的流程，确保团队正确地召开各种会议，帮助每个人理解Scrum 理论、实践、规则和价值。
Scrum Master 对Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助Scrum 团队之外的人了解他/她如何与Scrum 团队交互是有益的，通过改变他/她们与Scrum 团队的互动方式来最大化Scrum 团队所创造的价值。
- Product Owner
产品负责人（Product Owner）是有授权的产品领导力核心，组成Scrum团队三个角色之一。PO担任的是产品经理的角色。
作为确保团队做出正确产品，以便帮公司得到最高投资回报的产品负责人，在Scrum团队中负责“做什么”的问题。但不同公司，不同部门，不同团队的产品负责人的具体职责不尽相同。从总体上来说，产品负责人要负责产品的愿景和边界。而具体来说，产品负责人的工作是提出正确的解决方案和确保解决方案被正确“制造”。
- Team（开发团队）
在Scrum开发团队，所有的人都被称为“工程师”，且人数不宜过多，5~7人比较理想，包含产品、设计、前端、后端、测试等多角色，是实际价值产出者；
在 Scrum 的每个冲刺当中，开发团队为了实现计划里的功能，他们必须完成所有的相关工作，包括产品设计，开发，集成和测试。为此，团队必须具备完成这些工作的所有技能。在工作中，Scrum 作为一个整体，对功能的实现负责。
区别于传统开发方法里的“只负责自己那一部分工作”的状态。所以在团队开始之前就要考虑：为了能够完成Scrum电子任务板项目的各种需求，团队需要具备哪些能力，哪些能力是已经具备的呢，哪些能力是我们可以从外部获得支持。”
Scrum开发团队的主要职责如下：
- 在冲刺执行期间，开发团队完成创造性的工作，包括设计，构建，集成，测试，最终提供潜在可发布的功能发布。
- 每日检视和调整（每日站会）——作为一个自组织的团队，团队通过每日站会来实现自我的检视和调整以实现冲刺目标。
- 梳理产品列表——帮助产品负责人梳理产品列表，细化产品列表条目，估算和排列优先级。
- 冲刺规划——在每个冲刺之初，开发团队参与冲刺计划会议。在会议上，根据产品经理提供的信息，对产品列表条目的工作量进行估算，并在ScrumMaster的指导下，与产品负责人共同制订冲刺目标。
- 检视和调整产品与过程——在每个冲刺结束的时候，开发团队都需要参加冲刺评审会议和冲刺回顾会议。在会议上，Scrum团队检视和调整自己的过程和技术以进一步改善团队使用Scrum来交付业务价值的能力。
注意，开发团队对工作量的估算有绝对话语权，作为一个自组织的团队，他们不受其他角色的影响，对工作量进行估算并且按照自己的承诺去履行冲刺目标。
2.2 3个工件
- Product Backlog（产品待办列表）
首先产品待办列表永远不会完成，它是产品所有已知需求的优先级排序表，为了确保产品是有用的、有竞争力的，列表会不断地变化和调整，例如当市场提供了一些反馈，需求可能会变得更详细，PO就需要根据业务需要、市场环境和技术的变化及时进行调整，所以我们说，产品待办列表是动态的，会随着产品和使用它的环境发展而发展。
- Sprint Backblog
Sprint列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作，例如，在回顾会议中所发现的团队改进任务，团队计划要在当前Sprint完成。Sprint列表在Sprint规划会议中产生，一旦Sprint规划会议结束，产品负责人就不能再修改Sprint列表的故事清单了。
这是Scrum中业务方和开发团队之间的基本协议，每次Sprint开始前，业务方都可以改变方向，然而Sprint开始以后，团队则会专注于他们所承诺完成的故事。改变这个已承诺的故事清单只有一个方式，就是由干这个活儿的团队成员提出变更请求。
- Increment（增量）
Increment是Sprint期间完成的所有Product Backlog项目的总和，以及所有先前Sprint的增量值。在Sprint结束时，新增量必须是“完成”，这意味着它必须处于可用状态并符合Scrum团队对“完成”的定义。增量是一个可检查的“完成”工作，支持经验主义在Sprint结束时。增量是迈向愿景或目标的一步。无论产品负责人是否决定释放，增量必须处于可用状态。 Scrum的全部意义在于提供“完成”增量。
- 扩展工件之燃尽图
冲刺燃尽图（或燃尽图）不是官方的 Scrum 工件，但许多团队在冲刺期间使用它来沟通和跟踪冲刺目标的进度。燃尽图是显示在冲刺期间完成的任务的图表。燃尽图在帮助衡量团队的积极执行速度方面非常有用，因此他们知道他们是否会完成计划或需要重新确定冲刺任务的优先级。
在 sprint 计划期间，团队可以查看之前的燃尽图，以了解他们可以在即将到来的 sprint 中实际完成多少任务。团队可以检查正在进行的燃尽图，以确定他们是否能够成功完成冲刺。
在 sprint 评审期间，团队可以重新查看燃尽图，看看他们在哪里达到或没有达到预期。随着时间的推移，燃尽图可以帮助团队在 Scrum 的计划阶段更好地改进他们的估计。
2.3 5个活动
- Sprint（冲刺）
冲刺（有的公司叫班车，从起点站发车，到一站后需求完成下车，新需求上车，迭代的过程以此往复），一个固定的时间周期（通常为2w~4w，新项目可以是1w）。
- Sprint planning meeting（冲刺计划会）
Sprint计划会议的主要目的是，为了完成产品待办列表的目标，需要设计一个有弹性的计划来引导开发过程，来规划我们做什么和如何做这些事，Scrum Master要确保会议顺利举行，保证每个参会者都理解会议的目的。
Sprint计划会议要求Scrum团队协同合作，共同制定，PO、SM、开发团队都要参与，不能由他人代替。在计划会议上，我们要讨论出这三个问题的答案：
第一个问题是我们这次Sprint的目标是什么？
第二个问题是这次Sprint开发什么功能？
最后是我们将如何去做？
- Daily standup meeting（每日站会）
每日站会的目的是通过对比前次每日站会后的工作，也就是过去24小时所完成的工作，检视Sprint目标的完成度，并规划未来24小时的工作，通过每天这样快速反馈的循环，优化团队协调合作和表现。那么，这15分钟的会我们怎么开呢？
会议需要聚焦在Sprint目标上，主要通过回答以下三个问题展开：
昨天我做了什么事情帮助开发团队达成Sprint目标？
今天我要做什么帮助开发团队达成Sprint目标？
是否有任何障碍在阻碍我或开发团队达成Sprint目标？
- Sprint review（评审会）
Sprint 评审会议在 Sprint 快结束时举行 ，这个事件是让开发团队展示他们在Sprint中取得的成就，根据DoD“完成的定义”和验收标准，验证增量，这些增量应该是：已经开发、测试完成、经过整合的和已经记录的。
Sprint 评审会议不是一个进度汇报会议，所以不推荐大家使用PPT，这是一个非正式会议，演示增量的目的是为了获取反馈，提出意见和促进合作，根据完成情况和Sprint期间产品待办列表的变化，团队和利益相关方一起讨论接下来可能要做的事情，未来有可能迎接哪些新的机会/挑战。
比如我们自己的一个Sprint评审会议过程：
- 首先，会议开始，PO欢迎利益相关者来参加评审，然后由PO介绍项目的目标，以及本次Sprint的目标，根据我们在计划会议定义好的DoD，说明产品待办列表里哪些已经“完成”和哪些没有“完成”；
- 展示产品增量，开发团队演示Sprint中已实现的产品新功能，最好在接近生产环境的设备上进行，例如，开发在手机APP端的功能程序应该在手机端演示，而不是电脑~
- 由来自各方代表的利益相关者提出问题或反馈。
- 开发团队解答交付增量的问题，并总结Sprint期间做得好和还可以改进的地方。
- 参会的所有人就下一步的工作进行探讨： 评审产品在未来的不同市场，评估潜在的使用场景，决定接下来我们要做的哪些最有价值的改变或优化；
- 更新产品待办事项列表，在大家讨论期待发布产品的时间、预算和市场潜力等等问题，达成共识后，会更新待办列表。也就是Sprint评审会议的输出，是这份修订后的产品待办列表，为接下来的Sprint 计划会议提供有价值的输入信息。
- Retrospective meeting
回顾会议发生在评审会议之后，下一个Sprint计划会议之前。回顾会议的时间盒，以一个月的Sprint来说，回顾会议不超过3小时，半个月的Sprint，回顾会议不超过1.5小时。
回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
Scrum Master作为Scrum团队成员需要来参加会议，因为TA对Scrum的流程负责。该会议主要围绕以下问题展开：
我们在上一个Sprint中哪里做得好？
接下来才是讨论我们哪里做得不够好？
第三个问题就是，我们的改进计划是什么？
我们上次计划的改进项目进度如何？
2.4 价值观
3. Scrum实施全流程
基于以上框架，团队实施Scrum的流程如下：
4.Scrum 实施是否需要管理工具？好的工具有哪些？
根据国外机构 Digital.ai 2021年发布的《第十五次敏捷状态报告》显示：自疫情发生以来，采用敏捷的软件开发团队有显著增长，从2020年的37%增加到了2021年的84%。
除此以外，从敏捷状态调查的早期开始，工具支持一直是决定敏捷成功的关键因素。在实行敏捷的团队中有各种各样的工具集被应用，覆盖从通用规划与管理工具(例如，Microsoft Office)到专门的商业产品（例如，PingCode、Jira）。
延伸阅读-《国内外使用最广泛的14个 Scrum 工具盘点》：
5.Scrum 落地的13个常见的坑
SCRUM 作为最流行的敏捷框架，这些年已经得到广泛的流行。但是很多团队在落地SCRUM的时候，通常会产生以下问题。
概念性问题
- SCRUM就是敏捷么？
- SCRUM就是开各种会么？
- SCRUM有什么好的，能对我的团队产生什么作用？
SCRUM执行过程问题
- 计划会和需求评审会有啥区别？计划会时候发现需求经常有问题，并且还会有很多问题在迭代中出现。
- 站会为什么要每天开，每天重复3个问题很乏味。
- 评审会，业务方没空参加，时间也很紧张了，会议干脆被省掉了。
- 回顾会，回顾了几次后，已经没有了热情，总是那几个问题，有什么好回顾的。
- 迭代周期如何定？版本发布怎么做？
- 为什么看起来SCRUM没什么内容，落地执行却问题多多？
SM的角色和发展问题
- SM一定是全职的么？
- SM对我的职业发展有什么帮助？
- SM的发展路径是什么？
针对以上三类问题，大家可以通过下文看到详细解答。延伸阅读-《Scrum 落地的13个常见的坑及解答》
以上就是Scrum实施全流程的介绍，希望对你有所帮助。
