Scrum反模式

Posted 2021-04-25 ShineScrum捷行

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Scrum反模式相关的知识，希望对你有一定的参考价值。

因为Scrum很容易理解，所以初学者可能会使用其中一些实践并机械重复的去实施，但实际上他们并没有理解吃透Scrum原则。

软件领域中使用的反模式术语大多数最初都是吸引人的，易于实施的解决方案。但事实上，远远没有解决实际问题，最终反而导致更大的问题。

正如Scrum指南中所说的Scrum是一个框架，在这个框架内，人们可以处理复杂的适应性问题，同时高效地创造并交付最高价值的产品。Scrum是：

• 轻量级的

• 容易理解的

• 难以精通的

在不到一个小时的时间里，你可以向他人说出Scrum的所有要素。

因为很容易理解，初学者会轻松地使用甚至误用框架。他们可能从整体上使用一些实践，并以机械的方式重复它们，而不理解它们背后的原理。不做任何适应性改变，不挑战自我，这样，能期望提高工作效率吗？

我们需要劳记，Scrum不会一夜之间化腐朽为神奇。人们要适应于新的工作模式，尤其是需要时间适应文化转型。要有耐心，不要过早的急于表现，从敏捷教练的角度开始应用它，挑战自己，改变你的工作方式并理解原则。

现在我来谈谈最常见的“反模式”，希望能给你带来一些想法。这可以帮助你检视你自己和你的团队。在敏捷团队评估中，我观察到了一些这样的情况，这些公司正在努力找出为什么他们已经开始应用Scrum了却还是没有改进的原因。

• 团队等待分配任务或要求PO(产品负责人)分配任务，从而破坏其自组织性和决策能力的发展。

• ScrumMaster中的“Master”部分被视为技术或领域专业知识，因此，这个职位通常被团队中最有经验的软件开发人员担任。这对团队的发展产生负面影响。

• PO(产品负责人)和团队仅在 Sprint计划和回顾会议时见面。这通常意味着产品负责人在sprint期间没有花时间与团队和客户在一起，因此决策和学习过程很慢。

• 在Sprint计划会议上，所有任务都是个人认领，每个人对自己的任务负责，因此他们不作为团队合作，独立工作，在整个sprint过程中不能相互协作。

• 如果他们是按照上面描述的方式工作，那么，每日Scrum（允许协作和作为团队做出日常决策）放弃每日站会也并不奇怪。

• 团队和PO(产品负责人)专注于完成任务而不是交付价值。

• 他们不做回顾，他们实际上并没有挑战自己变得更好。

• 没有Sprint的审查，或者当团队展示了在Sprint中完成了什么，而不是检查交付的价值和sprint目标反馈。

• 会议不尊重“时间盒”原则。

• 随着Sprint的不断推进，Sprint待办事项的变化也越来越大。

• 团队将来自Sprint的用户故事传递给Sprint并针对同一个故事进行多个Sprint，表明存在切割问题或他们不了解迭代和增量工作方式。

• 在Sprint计划中，团队只讨论“什么”部分，而忘记讨论如何拉动项目的开发。

• 由于缺乏待办事项列表优化会议，所以Sprint计划会议时间很长（即超过时间盒）。

• 团队表现以“速度”作为衡量标准。

如果你发现你的团队存在这些反模式，有方法可以帮助他们恢复，比如结构化教练方法，并向经验丰富的敏捷教练寻求帮助。

本文由ShineScrum捷行翻译、审核

扫描二维码，阅读英文原文：