如何正确实施Scrum

发布网友 发布时间：2022-04-23 23:31

我来回答

共1个回答

热心网友 时间：2023-10-13 18:06

如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。

经验一：整个团队必须理解 Scrum 的目的和*。
如果管理团队把 Scrum 当作一种新的管理流程，那么这个理解绝对是错误的，而且有害。要正确理解 Scrum 的实施原则，需要从理解其设计目的开始。

我所理解的 Scrum 的目的在于两点：

适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Proct Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。

快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。

相应地，我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻，仍是两点：


因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；

快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。

Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性，或者功能不合需求而返工，或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪，请出门左转找 CMM 认证：它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度，什么都可以在掌控之中。但问题是，我们必须用更长的发布周期来换。

理解了上面的内容，我们实施时就不会对某些形式性的东西过于纠结，比如 Burn down chart，比如 Scrum 扑克。需知形式服务于目的，而形式未必适用于每一个团队，正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，比如每天的 15 分钟 stand-up，如果我们明白它对交流方面的重要作用，就绝对不会认为它可以被省略。

举个实际的例子，在我们的团队里，我们强迫一周一个 Sprint。就我所知，即使在很多实施很成功的项目中，这种做法也是相当激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，因为一周的发布周期让我们没有机会把任务往后推，从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要，但对别的团队来说，就不一定了。


经验二：正确定位队伍中的 Scrum Master。
为什么单独提 Scrum Master？如果只是看书本和参加培训，我相信多数人都会同意我的观点，即 Scrum Master 或许是整个开发过程中作用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。但是，当我真正当起这个 Scrum Master 之后，才发现这个角色承担的职责非常具体。比如：


确保流程执行正确。进入 Scrum 之后，很多团队仍然会以各种方式走老路，比如有意无意地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。——顺便说一句，相信我，不要以为两个星期的瀑布周期是个可行的开发计划，我们不可能完成测试任务的。

制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又比如非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来说这两者区别极大，可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我现在做得很差，还需要改进。


构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，比如测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力，确保不会让某个任务陷入「只有一个人知道细节」的情况。——这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍，需要时间改善。


但正因为上面的理解，我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，因为没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 需要关注团队的每一个人，不然队伍可能由于所谓「自组织」的原则而隐藏一些问题，比如某个人过于专精某一项而忽略了和其它成员的交流。当然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法，而且我也可以很自信地说，这种 Scrum Master 在我们公司是生存不下去的。

Scrum Master，你是肩负着人类使命的人啊！


最后，贴两句最近刚学到的话：


50% percent of our decisions are wrong. Fail fast, learn fast. （我们作出的决定中， 50% 都是错误的。早早失败，早早学习。）

No matter what you want to do, choose what is good for your team.（无论你选择做什么，选择对你的团队有利的事）

先声明，说上面两句话的哥们本人在我们队伍里不算很受欢迎，但这两句我很喜欢。在我眼里，这两句话指出了 Scrum 的所有实质。

共勉之。

Scrum 是众多敏捷开发方法中的一种，它既是方*，也包括了一系列预定义的角色、一系列的流程，以及一系列的实践经验。那么践行Scrum 到底是应该坚持以理论为准绳，还是从实际角度出发，有所舍弃和调整？一个可运行的 Scrum 流程的主要步骤是怎样的？

首先聊聊敏捷开发的价值观
对于敏捷开发来讲，有人说是流程、是方*是工具，但对于我来讲它更是一种精神，它并没有局限在流程、方法、工具上。敏捷软件开发的目的就是解决需求中的变化和中的不可控因素。
当时提出敏捷开发的这个人或者这个群体，提出来的是敏捷开发的四个价值观：第一，个体的互动要高于流程和工具；第二，可工作的软件要高于详尽的文档；第三，客户的合作高于合同谈判；第四，响应变化高于遵循计划。这四点价值观是最能体现敏捷开发的核心的东西，其精髓就是拥抱变化，而不是控制变化。

了解Scrum 是什么很重要
Scrum 是什么？它既是方*，也包括了一系列预定义的角色、一系列的流程，以及一系列的实践经验，包括需要的文档。我提出的一个观点是，对于我有用的就做，对于产品、项目没有用的就不做，但是Scrum 实际上不是这样的。你想做到Scrum 有些东西是必须要做的。所以我也希望大家能够自己批判性、灵活用它，而不是死板用它。

Scrum的主要角色
Scrum 主要定义了三个角色：Scrum Master，Proct Owner，Development Team 。
Scrum Master 不是Project Manager， 他的主要的工作是要保证这个团队执行 Scrum 的顺畅。Proct Owner 是真正对产品负责的人。如果我们是做产品研发的话，产品经理就是Proct Owner。如果我们是做项目开发，客户就是Proct Owner，这也体现了我们刚刚提到，我们并不是和客户去谈判，而是真正把客户放在我们的这种流程中，真正与他合作。第三种 Development Team 就是干活儿的。
所以 在Scrum 里面没有管理者的概念。另外，Scrum 里面实际上所有的真正为最终产出的软件付出的，都叫Development Team。这个地方也体现了一个Scrum 的观点，就是它希望能够打造Cross-Functional Team，即在这个团队中的所有人可以做所有的事情，每个人都是Development Team。


Scrum的开发流程

Step1. 需要一个 Vision
真正Scrum 的流程是什么样子的？首先，我们需要有一个Vision ，就是我们所做的产品或者所做项目的愿景。这个需要所有Team Members，包括Proct Owner 一起确定，然后大家朝着同样的目标前进。

Step2. 维护Backlog
Vision 出现后，Proct Owner 会维护一个Scrum 中我们提到的第一个文档，即 Backlog。它可以理解成我们从产品当中，从各个角度收集的需求， Proct Owner 要做的事情就是维护Proct Backlog，并且将Backlog 一条一条的按照优先级排好顺序。Proct Owner 是唯一有权利维护这个列表的人。
这个时候合理利用工具，就能免去写文档的的这一步，可以直接将需求通过任务的方式收集，每个需求就是一条任务，Proct Owner 可以给任务打标签来标示优先级。

Step3. 拆分Sprint
随后我们会针对这个Scrum 把它拆分成一个个的Sprint ，就是开发周期。然后将 Backlog 里面的项目添加到Sprint 中去，成为Sprint Backlog。每一个Sprint 开始的时候，需要进行一个Sprint Plan。

Step4. 运行Sprint Plan
Sprint Plan 就是整个团队一起，通过Backlog 从优先级最高的这个item 开始挑，挑出Proct
Owner 对Backlog 进行介绍。紧接着的是，大家将Backlog 拆分成单个的Task，每一个成员在每一天的工作当中领Task，完成Task。

由此可见，在完美的Scrum 里面，是没有任务指派一说的。每个成员会根据任务、完成度，去及时更新任务的状态。为了让大家了解整个项目的进度，Scrum会引入白板（在墙上或者在板子上钉好多的小纸条，让大家明确项目进度和任务完成情况）。
说到这个，我可以向大家推荐一个工具：Worktile。这个工作可以在Worktile 的看板视图上做，看板视图非常像真正的白板。通常情况下，在 Scrum 里的白板列表只有三列：TO DO、IN PROGRESS，以及 DOWN。这个在Worktile 里面就十分简单，你可以打标签、分配人、设置截止时间、在任务上进行评论，并且任务可以直接在列表间拖拽，从而推进流程的进展。并且这一切都是实时的，所有人都能看到。

Step5. Daily Scrum
在Scrum run 起来之后，还有一件事情是Daily Scrum 。在 Daily Scrum 中，每个成员只需三件事情：我今天做了什么，明天要做什么，有什么是我搞不定的。Daily Scrum 一般来说会控制在15分钟之内，而且所有的成员必须要站着开会。

Step6. Sprint Rview
当Scrum 结束后，我们会产出一个产出物。这个产出物在Scrum 里面，可以是一个可以运行的软件，也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段，我们需要通过Demo 在Proct Owner 以及其他的Stake Holders 面前，现场演示你做好的东西（而不是给大家讲你做了什么）。

Step7. Retrospective 
在Sprint Review 结束之后就是Retrospective。我们整个团队的人都要坐下来聊一聊，我们的Sprint 做得好不好，有哪些地方需要修改。

敏捷实际上就是一种理念，然后基于这个理念提供了一些方法和实践，在我眼里它意味着持续改进。所谓持续改进就是在产品设计上的持续改进，包括那我们尽量快速的迭代。我们每一个 Scrum 的Sprint 都不会太长，保证我们的每一个Scrum 都能提供给客户一个可运行的版本，能够快速得到客户的反馈。同时在产品区改进中，架构设计也会持续的改进。我们的设计并不是上了之后就把所有的东西都想好，而是基于我们产品的不断改进，在架构上持续的改进。敏捷本来就是持续改进，改进敏捷的流程，并用敏捷开发的精神改变我们自己的开发流程。