Scrum是用来发现问题的

机械的Scrum对比真正的Scrum，差别在哪里？

最近，我和一个朋友聊到了他们公司实施Scrum的情况。他们有些迷茫！在实施Scrum之前，他们经常为了访问一台测试机而不得不等上一个小时（甚至更多时间）。实施了Scrum几年之后，这个问题依然存在。同一家公司，却把测试服务器放在另一个国家，于是经常碰到网络问题，导致处于运行状态的测试中途失败。这是他们开始采用Scrum之前就存在的问题，一直以来，没有采取任何措施去解决它。

只有当问题存在于我们的环境之中时，用Scrum去解决才会有效，而且我们必须为之付出努力。

想一想这个基本原则：在每一个Sprint结束的时候，Scrum团队被要求产出高质量的可用的软件（或硬件）。质量要达到可发布的标准。

在每一个Sprint周期内，任何阻止团队完成可发布质量的软件的事情都算是一个障碍，必须要去解决！

而障碍没有被解决时，通常的原因如下：

• “完成”的定义不存在，不被重视，或者没有在一个真正公开的地方发布出来（通常是团队所在房间的墙上）。  【注】“完成”的定义（Definition of Done）是一个检查清单，是Scrum团队用来检验一个产品积压工作项是否真正被完成的标准。
• “完成”的定义直到每个Sprint快要结束、至少能发布的时候才被频繁更新和改进；最好可以持续发布。
• 缺少组件支持，或者不是  全功能团队。Scrum对全功能团队没有做明确要求，但要求团队具备足够的技能，以便在每个Sprint结束的时候都能将软件的一小块功能（不只是一个组件）从头到尾真正地完成。在Scrum框架下允许成立组件团队，但这样做会增加协调的成本。 【注】全功能团队（Feature Team）是一个长期存在、跨功能、跨组件的团队，它能完整地实现客户提出的很多功能需求，但每次只做一个功能。
• 有压力，因为每个Sprint都被要求交付更多的成果。很多团队都有一种持续的压迫感，他们被要求交付远远超出他们能力的成果。这种压力如此之大，以至于他们常常为了满足需求而走捷径。Scrum的设计初衷，就是给做事的人在决定他们能完成多少工作以及如何去完成方面更多的自由。这需要由团队来表明立场，说清楚他们的能力。只有当团队张弛有度，有时间暂停、反思和改进，真正的改进才可能发生。
• 组织上的障碍没有被消除。举个例子，多个办公室之间的网络问题，多个团队之间的协调问题，或者在团队层面无法解决的其他任何问题。

请记住，Scrum是一种发现问题的工具，而不是解决问题的工具。

为了让Scrum发挥效力，你的组织必须解决在Scrum实施过程中突显出来的问题。既然Scrum并不会为你的组织解决问题，如果你对它暴露的问题不跟进解决，你就不是在真正地践行Scrum。事实上，你只是在机械地搬弄Scrum。