这是一篇翻译的文章(有删减)，作者Gerhard Beck对Scrum疯狂吐槽，我虽然不能完全认同，但是有些吐槽还是挺对的，比如忽视文档。翻译出来想让大家看看，在实施Scrum的时候有没有同感?有没有觉得敏捷已经变味了?
我现在的团队最近采用了Scrum这种敏捷方法，并且开始了一个两周的Sprint，但是Scrum出现的问题让我开始憎恨它。
以鄙人之见，Scrum并不敏捷，也不灵活，因为有些坚定的追随者(狂热分子)坚持按照Scrum字面的意思去做，这些信徒已经接管了一切。
让我们从Scrum的两个基本术语开始：Sprint和Daily Scrum
Sprint
[[334057]]
Sprint是英式橄榄球的“冲刺”，这是一种隐喻，意味着经理们可以告诉每一个人，我们的开发需要“冲刺”得更快一些，把需求放到两周的时间框中，定期加大开发的压力。
这真是一种伟大的管理技术，可以最大程度地提高员工的加班时间，虽然加班已经让我们精疲力尽了。
码农翻身：不认同，这说明公司和管理层并没有真正地学会什么是敏捷和Scrum，但悲哀的是有不少公司就是打着敏捷的旗号这么做，压榨程序员。
Daily scrum
[[334057]]
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
如需转载，请通过作者微信公众号coderising获取授权。
