为什么我恨Scrum?

旧城等待， 2023-02-27 08:10 74阅读 0赞

> 这是一篇翻译的文章（有删减），作者Gerhard Beck对Scrum疯狂吐槽，我虽然不能完全认同，但是有些吐槽还是挺对的，比如忽视文档。翻译出来想让大家看看，在实施Scrum的时候有没有同感？有没有觉得敏捷已经变味了？

我现在的团队最近采用了Scrum这种敏捷方法，并且开始了一个两周的Sprint，但是Scrum出现的问题让我开始憎恨它。

以鄙人之见，Scrum并不敏捷，也不灵活，因为有些坚定的追随者（狂热分子）坚持按照Scrum字面的意思去做，这些信徒已经接管了一切。

让我们从Scrum的两个基本术语开始：Sprint和Daily Scrum

## Sprint ##

![format_png][]

![format_png 1][]Sprint是英式橄榄球的“冲刺”，这是一种隐喻，意味着经理们可以告诉每一个人，我们的开发需要“冲刺”得更快一些，把需求放到两周的时间框中，定期加大开发的压力。

这真是一种伟大的管理技术，可以最大程度地提高员工的加班时间，虽然加班已经让我们精疲力尽了。

> 码农翻身：不认同，这说明公司和管理层并没有真正地学会什么是敏捷和Scrum，但悲哀的是有不少公司就是打着敏捷的旗号这么做，压榨程序员。

## Daily scrum ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psMXpsMnpsMw_size_16_color_FFFFFF_t_70][]

Scrum是浑身“脏兮兮”的橄榄球运动员“互相推搡”着争球， 这是另外一种隐喻，表示你得完成日常工作，确保项目进展没有障碍。

相比而言，我更喜欢一个不那么激烈和侵略性的东西：每日站会。可以说说你昨天做了什么，今天计划做什么，有没有阻碍你的东西。

> 码农翻身：实际上，在国内我们使用的词就是“每日站会”，而不是“每日争球”。

## Done ##

“Done”（完成）是Scrum中一个关键的术语，它要求那些干活的人和检查的人对于“Done”必须得达成一致，实际上，"Done"指的是被最终用户接受， 有些人真把它玩坏了。

“Done”和两周的Sprint经常以一种特别讨厌的方式结合在一起：“在每个Sprint Review会议中，我们必须看到一个完成的、可以交付的软件增量”， 于是我们就看到了这样的谈话：

“生孩子需要花9个月。”

“你必须把这个过程分解到以两周为单位的Sprint当中，这样我们每个Sprint Review都能看到进展。”

“起草这个文件需要花费3个月时间，因为我们需要把一些设计加上去。"

“好啊，你把整个文件分解一下，确保每个Sprint我们都有可以发布的东西，每个Spring我们都要‘Done’。”

“但是只有全部完成才能发布，你为什么要假装每个Sprint都能发布呢？”

> 码农翻身：作者举的例子比较极端，一般来说任务完成是指开发完成，测试完成，代码提交，构建完成，随时可以部署

## Time Box （时间框） ##

时间框的目的是把所有的事情放到一起，在一个Sprint中全部完成，一个Sprint时间框通常是两周时间，可能更长或者更短。

但是有些事情会快一些，有些会慢一些，当那些比较快的任务已经完成，为什么不立刻发布它们呢？为什么要等到Sprint的结束，等到Sprint review 会议后才发布呢？

再说一次，以我的浅见，Scrum不是敏捷，它是一个为期两周的瀑布模型。

## Scrum Master ##

OK，现在正处于“黑人的命也是命”的抗议时期。"Master"经常被认为是一个种族主义的词汇，正好可以停止使用它了。

什么是“Scrum Master”?  Scrum Master是团队的一个“仆人”式领导，他实际上是被剥夺了管理项目能力的PM，我可不想参与其中。

很多时候，我们需要完成一些紧急的，意料之外的事情，项目经理有权力做出改变，把这些事情搞定。

对于Scrum Master，他只能“温柔”地向管理层解释，这个Sprint的工作已经确定了，不能改了，拯救这条船的机会将会出现在一周半后的Sprint Review会议上，在此之前，你的双脚必须得忍受这些不舒服的海水。

## 会议 ##

Scrum定义了四个正式的会议：

Sprint 规划会议

Daily Scrum

Spring Review

Sprint 回顾和反省

Spring 规划会议提供了各种方法来估算任务需要花费多长时间（码农翻身注：难道作者指的是扑克牌估算？），这可以使得Sprint的任务清晰明了。我觉得这完全是浪费时间！现在仅仅是猜测，就试图把任务放到两周的Sprint中是荒谬的。

> 码农翻身：不认同，任务的时间估算还是必不可少的。

我甚至听说过有些团队为了使得Sprint更“满”，**特意增加一些不重要的任务**。 我认为任务应该按照优先级来进行开发，而不是仅仅为了放入到Sprint当中！

每日站会的确是个好主意，但是最好不要把它称为“每日争球”。看看在既定时间表上正在发生的事情是一个好主意，但是在每次会议上都要求“Done”就不是这样了。

Spring回顾和反省会议不一定每个Sprint都做，只有你注意到了一些事情可以改善时，开回顾会议才有必要。

## 团队 ##

Scrum对于团队有个说法：一切归团队所有，团队要同甘共苦。

我相信团队成员需要互相帮助，团队应该作为整体而成功，但是我并不喜欢绩效好成员也要为绩效差的成员背锅， **吃大锅饭必然导致优秀成员的离职**。所以个体的努力应该被认可，Scrum在很大程度上践踏了这一理念。

Scrum还有一个说法： 团队成员的每个人都可以做其他人的工作，我不认同，这只会让团队的技术专家降级到泥瓦匠的层次。

> 码农翻身：不认同，开发帮着做点儿测试的工作，测试帮着写一点自动化单元测试，我认为是可能的。

我也**反对每个成员对任何事情都有平等的投票权**， 假设我雇佣了一个有30年经验的专家和5个刚走出校门的大学生，我肯定期待专家发言权更大，而不是被新手们通过投票击败。

对于一个团队，我认为需要培训更好的领导者，而不是完全放弃这个概念，军队是完全建立在领导者和领导力基础上的，在需要的时候军队非常敏捷，尤其是被给予现场做决定的自由时。我们应该更多地研究一个好的领导者是什么样子，而不是发明一个方法论，故意地去除领导者和领导力。

## 可以工作的软件 ##

Scrum致力于每两周都发布可以工作的软件，对于有些项目（如Web前端），这样一个短的、相同的节奏工作良好，对另外一些项目（如航空电子设备）它就没法工作了。

我工作过的大部分项目都无法适应这个模型。你通常可以每周展示进度，但是很难保证每两周都有一个潜在的，可以发布的产品。

我也很喜欢在早期就拥有可以工作的子系统，然后让他们逐渐成熟，并增加更多子系统，但是“可以工作的软件”模型真正的问题是它忽略了计划和文档。

在最好的情况下，你可能有一个planning sprint,用两周的时间专门做计划，然后你就忘记了这个苦差事，这两周过后，再也不做计划和文档了，只是code, code ,code !

虽然我坚信编码才是最终的设计步骤，但是我不相信编码是唯一的设计步骤。对于绝大多数任务，我希望在编码之前看到一些设计。

> 码农翻身：说得好！忽视设计和文档后果严重，敏捷不是不要设计文档，而是要去除那些繁琐的、容易过时的设计文档

最后，作者列举了他认为有用的几个实践

1. 每日站会

对我们来说，我们的Product Owner通常会出席，他在开始的时候能在总体方向上给出指导，后来他总能帮我们移除一些障碍。

2. Kanban

拥有一个事情优先级的列表是非常有用的，我们没有用固定时间长度的Sprint，每当开发人员完成了之前的任务，就会从列表中取下一个优先级更高的来做

3. 每周展示

虽然没用固定时间长度的Sprint，但是我们的每周展示相当于Sprint Review，只要成员完成了一些重要的事情，即使没有符合Scrum "Done"的标准，我们就会展示出来，这会树立我们项目正在前进的自豪感和信心。团队成员也通过这种方式获得了认可。

怎么样？有没有同感？更多吐槽，可以到原文看看：

https://dzone.com/articles/why-i-hate-scrum

[format_png]: /images/20230209/173cc1ee15e14e0b9425c198e72a52a3.png
[format_png 1]: /images/20230209/daa2a2b038354f88b50f1f8bfa7f7824.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psMXpsMnpsMw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200716194146299.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psMXpsMnpsMw==,size_16,color_FFFFFF,t_70