Scrum：处理动力不足

根据此，“Scrum的高度依赖于积极主动，密切协作，跨职能和自组织的团队。” 那么，您如何处理可能不太愿意获得代码所有权的同事呢？您如何获得对拥有所有权感兴趣的人？

我不知道这是否是您团队的问题，但是当我们第一次引入Scrum时，这绝对是我们的问题。有一天，我们的管理层来找我们，说，从现在开始，您将不再需要单独工作。相反，您将作为一个scrum。这是您必须遵循并遵循的一系列新流程。

关键是他们从来没有来找我们开发人员，而是问他们你们想如何工作？什么会使您更快乐？更高效？。因此，我听到的是，“您不再拥有任何代码。您编写的任何内容都将受到践踏（您知道，团队所有权）。您不会动弹或动弹，因为我们现在将按小时管理您的时间。” 哦，现在您每天无聊地站立15分钟，在那里人们会讨论您不关心的事情，通常需要30分钟，然后每两周就会有4个无聊的4小时计划会议，这肯定会吸引您一生都没有。

实际上，这不是敏捷或Scrum，它只是从一种管理风格转变为另一种风格，那里的一切仍由中央控制，这不仅使我丧生，也给了我很多自由是时候更新我的简历了。

在过去的十二个月中，在我游说过很多次让团队经理尝试不同的方法之后，他实际上接受了我的建议，我认为我们度过了非常成功的一年。

我相信对我们来说，关键的变化是让开发人员在选择我们的工作方式时有更多的发言权和自由。我们做了几件事：

1. 将大型“敏捷”开发团队分成3个小团队，以便每个只有3-4个开发人员。这使每个人都参与其中，个人不会被淹死。
2. 确保同一团队中的每个人都在相同的职能范围内工作，以便人们关心其他人在站立和迭代计划中正在谈论的内容。
3. 与其让管理层简单地选择谁来从事什么工作并分配故事/任务，我们还提出了积压工作，团队本身在如何划分工作上有很多发言权。
4. 因为我们有许多新成员，所以我们从某种程度的筒仓系统开始，其中每个人都承担主要责任。这使新人们可以专注于未知产品的较小区域，还可以更快地感觉到他们不在别人的沙盒中玩游戏。但是进入计划6-8个月后，随着边界变得越来越灰暗，这些区域开始变质。现在，在我所在的团队中，这些家伙相当乐于踏入他人的代码或让其他开发人员参与其中。
5. 所有提交的代码审查都是关键（这是我们初次执行Scrum时跳过的第一件事）：
   • 关于编程技术/方法的知识转移
   • 非常适合其他人学习他们否则不会看到的代码
   • 您的团队有机会进行交流和社交，从而改善了团队动力
   • 而且我想，代码审查将捕获一两个错误，但我认为它们的价值主要体现在上述方面。
6. 管理层必须听取团队的意见。如果团队说某事不起作用或需要更改，而他们只是忽略了这一点，那么团队成员将简单地签出并让管理层处理该项目。如果您希望员工有动力，那么他们就必须被赋予归属感，只有在他们做自己认为正确的事情时才被赋予归属感，而不是被告知他们自上而上要做的事情。

缺乏动力的原因有很多，但最常见的可能不是您有发言权。当我们的团队开始做Scrum时，我注意到那些对Scrum缺乏动力的人在看到回顾中的建议得到落实后就转过身来。

一堆小问题加起来会令人沮丧。例如，上周出现的一件事是不喜欢4:00会议的团队成员。这很容易解决。

换句话说，找出导致团队动力不足的最佳方法是询问他们。

通过授予他们对代码的个人所有权。

许多商店都采用“团队所有权”模型。这对于跨部门合作和降低风险非常有用，但对于激励个人承担个人责任却不是那么重要。团队所有权可以使代码平均，因为没有个人所有权激励。

解决方案：将个人分配给代码的每个部分，使其成为该部分代码的管理员，但允许整个团队完全访问整个代码库。

另请参阅：https : //softwareengineering.stackexchange.com/a/33464/1204