Scrum 团队的3个常见投诉

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，加?关注?，你的?支持?是我?最大?的?动力?。

多年来，我在 Scrum 团队中听到的讨论中，经常会出现三个常见的问题:

1. “我们需要更长的冲刺。”
2. “我们总是有溢出效应，似乎无法修复它们。”
3. “临时任务总是会把 sprint 计划搞砸。”

我认为这通常源于人们在问题出现时的普遍不适; 但对我来说，处理这样的事情正是敏捷的全部。所以，这是另一种思考方式
关于这三个问题:
1. Sprint持续时间:

众所周知，随着Sprint持续时间的改变，团队会受到影响，项目也会发生变化。 所以，当团队抱怨需要更长的冲刺来完成工作，很明显是因为缺乏计划(而且没有时间去掩盖缺乏计划的事实)。 而不是在计划过程中提出需要准备的东西，团队通常会承担所有的工作

因为有人让他们这么做。 这个问题本来可以由团队简单地解决

依据它的工作量快速识别，采取和交付。

但是因为计划的问题，造成各种个样的问题。

2. 溢出效应:这不是罪魁祸首。

最重要的是发现为什么溢出效应正在发生。 有时当临时的工作来了，而不是去

权衡(因为能力是有限的)，团队只能承担所有，通常情况下，等待与其他团队或外部合作伙伴的依赖会造成混乱的事情。 即使团队看到了风险，他们也会克制自己，因为每个人都在等待换个人来决策。 这就预示着团队授权和决策的地方应该被改进。

3. 计划外的工作:Sprint的回顾是谈论计划外的工作渗透的一个很好的平台。

提出这个问题的最好方法是看看团队能力范围内的计划外工作的百分比。 追踪这种情况的一个简单方法是创建一个用户故事，并不断增加它的计划外工作，以及所花费的时间。 因此，在sprint回顾中，溢出因素或权衡是很容易谈论的——而且“责备”(如果有的话)并不总是落在团队身上。 每个人都得到了所需的清晰。

敏捷与只是站会的一部分是非常不同的。主要问题在于，领导层往往不赞成敏捷团队，而且在这个过程中会出现更多的混乱。团队被迫遵循敏捷条例，无法遵循敏捷中最重要的拥抱变化的特性，直到最后整个团队没有看到任何好处，因为他们一直被迫从事敏捷计划之外的工作。

以及提出目前的工作上的障碍(以及在这些障碍上花费了多少时间)或成本将允许做出一个简单的决定:您想继续保持敏捷吗? 如果“是”，团队有权做多少决定?而不是仍被领导层控制。

您在 Scrum 团队中遇到过哪些常见问题，以及您是如何处理它们的？