此为翻译文章（有删减）。作者GerhardBeck抱怨过Scrum。虽然我不完全认同，但有些抱怨还是挺对的，比如忽略文档。我希望每个人都能看到翻译。在实施Scrum时，您是否也有同样的感受？你觉得敏捷已经改变了吗？我现在的团队最近采用了Scrum这种敏捷方法，开始了为期两周的Sprint，但是Scrum出现的问题让我很讨厌。在我看来，Scrum并不敏捷，也不灵活，因为有一些坚定的追随者（狂热者）坚持按照Scrum的字面意思去做，而这些弟子已经接管了一切。先从两个基本的Scrum术语说起：Sprint和DailyScrumSprintSprint是橄榄球的“冲刺”，比喻管理者告诉大家我们的开发需要“冲刺”得更快一些，把需求放到两周的时间范围内，周期性加大开发压力。这真的是一个很好的管理技巧，可以最大限度地增加员工的加班时间，即使我们已经被加班弄得筋疲力尽了。码农翻身：我不同意，这说明公司和管理层还没有真正学会什么是敏捷和Scrum，但可悲的是很多公司打着敏捷的旗号这样做，压榨程序员。DailyscrumScrum是“肮脏”的足球运动员为了球“互相推搡”，这是另一个比喻，意味着你必须完成日常工作，确保项目顺利进行。相反，我更喜欢不那么激烈和激进的活动：每日站会。你可以谈谈你昨天做了什么，今天打算做什么，有没有什么阻碍你的事情。Coders转身：其实我们国内用的词是“dailystand-upmeeting”，而不是“dailyscrum”。完成“完成”（完成）是Scrum中的一个关键术语。它要求做工作的人和检查的人必须就“完成”达成一致。实际上，“完成”是指被最终用户接受。人们真的搞砸了。“完成”和为期两周的Sprint通常以一种特别令人讨厌的方式结合在一起：“在每个Sprint评审会议上，我们必须看到一个完成的、可交付的软件增量”，所以我们看到这样的对话：“需要九个月的时间才能完成婴儿。”“你必须将这个过程分解为两周的冲刺，这样我们才能在每次冲刺回顾中看到进展。”“起草这份文件要花钱。3个月，因为我们需要添加一些设计。”“好吧，你把整个文件分解一下，确保每个Sprint我们都有东西可以发布，每个Spring我们都要'Done'。”“但是只有全部完成才能发布，你为什么假装每个Sprint都可以发布？”码农翻车：作者举的例子比较极端。一般来说，任务完成是指开发完成、测试完成、代码提交、构建完成。可以随时部署TimeBox（时间盒）时间盒的目的是把所有东西放在一起，在一个Sprint中完成。一个Sprint时间盒通常是两周，可能更长也可能更短。但是有些事情会更快，有些事情会更慢，当那些更快的任务完成后，为什么不立即释放它们呢？为什么要等到Sprint结束，Sprint回顾会议之后？同样，在我看来，简而言之，Scrum不是敏捷，它是一个为期两周的瀑布模型。ScrumMaster好的，现在是BlackLivesMatter抗议的时候了。“大师”经常被认为是一个种族歧视的词，是时候停止使用它了。什么是“ScrumMaster”？ScrumMaster是团队的“仆人”领导者，实际上是被剥夺了项目管理能力的PM，我不想成为其中的一员。很多时候，我们需要完成一些紧急的、意想不到的事情，而项目经理有权力做出改变，把这些事情搞定。对于ScrumMaster，他只能“温柔地”向管理层说明，本次Sprint的工作已经确定，无法更改。救船的机会将在一周半后的SprintReview会议上出现，你的脚必须忍受不舒服的海水。MeetingsScrum定义了四种正式会议：SprintPlanningMeetingDailyScrumSpringReviewSprintReviewandReflectionSpringPlanningmeeting提供了多种方式来估算任务需要多长时间（Estimate？），可以使Sprint的任务明确。我觉得这完全是浪费时间！仅仅通过现在的猜测就试图将任务安排到两周的冲刺中是荒谬的。码农翻身：我不同意，任务的时间预估还是必不可少的。我什至听说过有些团队为了让Sprint更“饱满”，故意加入一些不重要的任务。我认为任务应该按优先级开发，而不仅仅是为了适应冲刺！每日站会是个好主意，但最好不要将其称为“每日站会”。按照设定的时间表查看发生的事情是个好主意，但在每次会议上都要求“完成”就不是了。springretrospective和introspectionmeeting不一定每个Sprint都做，只有当你发现可以改进的地方，才有必要开retrospectmeeting。TeamScrum对团队有一句话：一切都是团队的，团队要荣辱与共。我相信团队成员需要互相帮助，团队整体应该是成功的，但我不喜欢表现好的人必须为表现不佳的人背锅。吃大锅，难免会有好会员的离开。所以个人的努力应该得到认可，而Scrum在很大程度上践踏了这个想法。Scrum还有一句话：团队中的每个人都可以做其他人的工作。我不同意。这只会让团队的技术专家沦为泥瓦匠级别。码农转身：我不同意。开发帮助做一些测试工作，测试帮助编写一些自动化的单元测试。我认为这是可能的。我也反对每个成员对所有事情都有平等的投票权，假设我聘请了一个有30年经验的专家和5个大学刚毕业的大学生，我肯定希望专家比菜鸟有更大的发言权。表决。对于一个团队，我认为需要培养更好的领导者，而不是完全放弃这个概念，军队完全建立在领导者和领导之上，军队在需要的时候非常敏捷，特别是在空闲时间给予现场决策。与其发明一种故意去除领导者和领导力的方法论，不如多研究一个好的领导者是什么样子的。工作软件Scrum致力于每两周发布一次工作软件。对于某些项目（例如Web前端），这种简短、统一的节奏效果很好。对于其他人（例如航空电子设备）则没有。法律有效。我从事的大多数项目都不适合这种模式。您通常每周都可以展示进度，但很难保证每两周就有一个潜在的、可发布的产品。我也喜欢尽早拥有工作子系统并让它们成熟并添加更多子系统，但“工作软件”模型的真正问题在于它忽略了计划和文档。在最好的情况下，你可能有一个计划冲刺，花两周的时间来计划，然后你就忘记了苦差事，在那两周之后，没有更多的计划和文档，只有代码，代码，代码！虽然我坚信编码是最后的设计步骤，但我不认为编码是唯一的设计步骤。对于绝大多数任务，我希望在编码之前看到一些设计。码农翻了个身：说得好！忽视设计和文档会产生严重的后果。敏捷不是不要设计文档，而是去掉那些繁琐、容易过时的设计文档。最后，作者列出了几个他认为有用的做法1.我们的日常站会通常由我们的ProductOwner参加，他可以在开始时为我们指明方向，之后他总能帮助我们排除一些障碍。2.看板有一个事物的优先级列表是非常有用的。我们没有使用固定长度的Sprint。每当开发人员完成前一个任务时，他将从列表中选择更高优先级的任务3。虽然weeklypresentation没有使用固定长度的Sprint，但是我们的weeklypresentation相当于一个SprintReview。只要成员完成了一些重要的事情，即使他们没有达到Scrum的“完成”标准，我们也会展示出来。将为我们的项目向前发展建立自豪感和信心。团队成员也以这种方式得到认可。如何？你有同样的感觉吗？更多抱怨可以阅读原文：https://dzone.com/articles/why-i-hate-scrum
