对Scrum的五大反对意见(以及为什么这些反对意见是错误的)

我曾有机会与一些真正了不起的团队合作，他们取得了惊人的成果。每个团队都有一个共同点，那就是他们都曾是Scrum的新手。当我与团队讨论Scrum框架的实现时，他们经常提出采用Scrum的潜在障碍。以下是对Scrum最常见的五个反对意见，以及它们没有任何分量的原因。

会议太多了，我们没时间了!(Scrum活动实际上节省了时间。)

当我向一个新团队介绍Scrum框架时，我几乎总是听到有人大声疾呼:“开这么多会，我们怎么能完成任务?!”Scrum框架由五个部分组成事件(外行称之为会议)、三个工件和三个角色。Scrum中的五个事件如下:

我不想说谎;从外面往里看确实很复杂。但经验表明，每月至少聚在一起计划工作并不是不合理的。每月至少召开一次会议讨论开发人员完成的工作也是合理的。与Scrum团队进行快速讨论，讨论如何改进所有事情的工作方式——坦率地说，这是非常宝贵的。

至于Daily Scrum，这个事件被限定为每天15分钟。这个15分钟的会议，如果做得好，可以节省团队在解决问题的会议上花费的时间。

简而言之，经验表明，如果使用得当，Scrum事件实际上节省了时间。事实上，Scrum事件减少了开发人员花在会议上的时间。

我们无法在不到一个月的时间内交付可用的软件!(如果你送的是小块的就可以)

我听到的第二个最常见的反对意见是，开发人员将无法在不到一个月的时间内交付完成的增量。这是我最喜欢的反对意见，因为这是一个讨论敏捷的基本事实的机会。为了了解这些真相，我们需要了解一些背景知识。根据第15个敏捷报告状态，组织向敏捷过渡最常见的动机之一是加速软件交付。采用敏捷方法后，公司看到的影响之一是缩短了上市时间。

以上数据来自第15届年度敏捷状态报告，可在http://stateofagile.com．

但这些数字并不一定意味着开发人员的编码速度更快;这意味着敏捷团队以不同的方式工作。使用传统的开发方法，客户在使用任何东西之前都必须等待所有东西都完成。使用Scrum，开发人员专注于以较小的增量向客户交付最有价值的工作，而不是以一个大的可交付成果。增量交付允许客户和企业更快地开始接收价值。所以，是的，开发人员可以在不到一个月的时间内交付完成的增量。

我们有最后期限;我们不能使用Scrum!(Scrum提高了在最后期限前完成任务的可能性。)

许多软件开发团队都面临着快速交付工作的压力，因为其他团队有他们需要满足的最后期限。对敏捷的一个常见反对意见是，团队认为当他们有一个时间表要开会时，传统的瀑布方法是唯一的方法。事实远非如此。Scrum不仅可以在这些情况下工作，而且根据我的经验，它增加了完成具有挑战性的最后期限的可能性．Scrum很好地处理了最后期限，因为它是基于经验主义，精益思想，以及迭代方法到产品交付。

简而言之，经验主义就是在已知的基础上做决定。在实践中，这意味着敏捷计划通过更频繁地计划小批量的工作来实践即时决策，而不是预先对一个计划做出所有的关键决策。精益思想意味着减少浪费，只关注必需品，还有迭代交付包括频繁地交付可用的产品。

看我的文章Scrum能否应对严格的截止日期了解更多。

我们需要计划!Scrum中没有计划。(Scrum团队实际上计划得更多)

有一个常见的误解，认为Scrum团队不做计划。事实上，敏捷团队比瀑布团队计划得更多;只是发生的方式有点不同。在传统的瀑布式工作中，计划提前进行，而对于敏捷团队来说，计划更频繁地进行。Scrum团队在Sprint计划活动和每日Scrum期间为即将到来的Sprint计划工作，在每日Scrum中，开发人员计划未来24小时的工作。您也可以认为产品待办事项列表的细化是一种计划形式。Scrum团队在每个Sprint中花费多达10%的时间来完善产品待办事项列表，为未来的Sprint做好准备。此外，产品负责人在每次Sprint评审时都提出一个预测。预测可以采用多种形式，但通常显示Scrum团队可能即将交付的成果，这与使用瀑布方法的项目计划显示即将交付成果的方式大致相同。

我们的管理团队永远不会这么做(如果方法正确，他们可能会这么做)

许多团队担心他们没有权力改变他们的工作方式。这是真的;大多数团队需要一些帮助来过渡到敏捷。下面是一些与领导团队讨论敏捷转换的技巧:

专注于价值交付

当与领导团队合作以获得向敏捷转变的支持时，请关注敏捷最擅长的事情:以更小的增量更快地交付价值。

专注于角色清晰

许多领导者在向敏捷过渡时犹豫不决，仅仅是因为他们对敏捷不够了解。为领导团队提供培训，让他们了解敏捷的含义，以及如何最好地与敏捷团队合作。我推荐Rebel Scrum专业敏捷的领导类。看我的文章，资源管理器和Scrum，了解更多。

重点促进护栏内的自我管理

一旦领导层支持敏捷，就应该从一开始就专注于自我管理，允许人们在既定的框架内自我组织到Scrum团队中。护栏是团队自我组织的限制。

我过去用过的一些护栏如下:

• 每个团队可以处理任何产品待办事项列表项。
• 每个团队都必须能够交付具有端到端功能的工作。
• 每队不超过10名队员。
• 每个团队都有开发人员和测试人员。
• 每个团队在开发和测试方面都应该有不同的经验水平。
• 所有团队必须根据相同的产品待办事项列表工作。
• 所有团队将使用相同的完成定义。
• 所有团队将使用相同的积分系统和评估定义。
• 一旦团队自组织，我们将在回顾会议上评估任何变更的需求之前，至少在四个sprint中使用该结构。

其中一些护栏，比如要求所有团队按照相同的产品Backlog工作，只是对Scrum框架基本元素的重申。另一些则是管理层为鼓励更大的跨功能而做出的战略决策，例如要求任何团队都应该能够处理任何产品待办事项项，以交付产品的端到端功能。在不影响Scrum框架的情况下，每个组织都可能有额外的独特规范，团队可以在其中进行自组织。

关于玛丽伊克巴尔

Mary在敏捷、Scrum和看板方面培训了1000多人。她为拥有60多个团队的组织指导了敏捷转型，并领导了新产品的创建，从产品定义到自组织和发布。玛丽是……的创始人叛军Scrum这是一家帮助团队向敏捷转变的咨询公司，并根据实际经验提供培训和指导服务。Rebel Scrum拥有在各种环境(包括技术和业务转换)中进行大规模敏捷转换的经验。注册Rebel Scrum即将上市Scrum培训课程或联系我们讨论私人Scrum培训为您的组织提供咨询。