Scrum会将主动开发人员变成被动开发人员吗？

我是一个网络开发人员，由三个开发人员和一个设计师组成。现在，我们已经实施了五个月的敏捷Scrum软件开发方法。但是我有一种奇怪的感觉，我只想在这个网站上分享。

决策过程是人类生活中的重要因素。但是，您做出的决定有很大的不同。有些决定只是内部力量或外部力量的结果，而其他决定则完全基于您的自由意志，而某些决定只是介于两者之间。您做出决策的自由度越高，您的工作就会越自我驱动。这似乎是规则。因为我们倾向于自己塑造生活。

您决定做什么或被告知要做什么之间有很大的不同。

争球之前，我感觉自己就像做了哪些相关的发展，分析了决定，优先执行，等我有更多的感觉就像有更多的自由，我决定我在做什么。

但是，由于采用Scrum的方法论，现在许多决定只是来自产品所有者。他优先考虑PBI，他分析软件应如何工作，甚至有时应如何实现UI和功能。我知道这是Scrum方法论的一部分，我也知道这可能会导致将来更好的产品销售。但是，我现在感觉总是被告知要做某事，而不是决定做某事。现在，这种综合症使我对工作更加被动了。

1. 我倾向于减少搜索以找到更好的解决方案，方法或技术
2. 我不会在早上醒来，希望能得到愉快的工作。相反，我觉得自己被迫为了生存而工作
3. 下班后我更渴望从事自己的业余爱好项目
4. 我不会再推动团队达到更高的技术水平了
5. 我现在花更多时间在晚餐或下午茶时间上，而对恢复工作的热情却降低了
6. 我现在愿意为工作早日完成做好准备，以便我可以回家

最大的问题是，我也在同事中看到并诊断了这种行为。是混乱的结果吗？Scrum是否真的使开发团队感觉自己没有参与整个软件的开发，从而使项目变得被动了？我该如何克服这种感觉？

但是，我现在感觉总是被告知要做某事，而不是决定做某事。

这是一个严重的迹象，表明有些事情脱离了轨道。敏捷项目不应该是这样。“过程中的人员过多”的措辞应包括“我们不强迫我们的人员做令人讨厌的事情”。这里有一些想法：

你在做“ scrum but”吗？也就是说，一部分是混乱，一部分是其他事情。（即：“我们正在做Scrum，但是我们所有的故事都必须来自我们的PMO，而不是产品所有者。”）如今，许多疯狂的废话被称为Scrum。

您个人是否没有参与应做的过程？我知道许多人对故事的内容感到不满，事实证明，只有故事在sprint待办事项列表中，他们才会参与其中。在故事的开发过程中尽早与产品负责人交谈，并获得您的反馈。（作为采购员，他们拥有最终决定权，但这并不意味着他们必须独自做。）

在Scrum中，团队应该拥有流程，并且可以预期流程会随着时间的推移而变化，以适应团队的需求。在回顾中提出您的问题。如果您可以提出一个流程调整建议，这往往会使某些团队更容易销售。

您的问题不是Scrum（正如评论中的Jarrod Roberson所说，这不是Scrum所描述的）-这是产品负责人的微观管理以及您（和团队）缺乏自信的原因。

“但是，由于使用scrum方法，现在许多决定仅来自产品所有者。他将PBI划分优先级，他分析软件应该如何工作，甚至有时应如何实现UI和功能。我知道这是scrum方法的一部分。”

你误会了 从对Scrum的Wikipedia页面进行的简短浏览中，您可以看到：“团队，一个跨职能的小组，负责实际的分析，设计，实现，测试等。” 看到？产品负责人会告诉您该怎么做，但是由团队来决定如何做。

您是负责实施的人员，因此您应决定如何实施应用程序。听取产品负责人的意见，但最终决定权取决于您（或团队）。

BTW微管理确实将主动开发人员转变为被动开发人员。

您所描述的不是SCRUM

如果您的产品负责人告诉您如何在技术上完成您的工作，那么您的产品所有者将越过边界，这根本不是SCRUM的目的。

SCRUM旨在使开发人员有更多时间专注于开发问题，并授权他们确定所需的时间和方法。

SCRUM是关于协作的，即Sprint计划会议的目的是促进所有利益相关者之间的协作。产品负责人，开发人员和测试。

是的，产品负责人应该优先考虑功能，首先要根据客户需求交付哪些功能，但是开发人员应该进行工程设计，而不是产品负责人。

我不同意开发人员应该设计GUI和工作流程，除非他们经过专门授权并受过培训，可以与客户合作并直接与客户哈希功能。程序员在真空中完成GUI的创建很少能满足客户的需求。

SCRUM旨在对轻量级过程进行轻量化，该过程在整个敏捷宣言中是可预测和可重复的。

这让我伤心地听到，很好的东西被扭曲了这样的故事。

我想在Scrum之前，每个人都只是做了想要的事情：yippee ki-yay mf'er。用户是您的恩人，他们会推动故事发展并支付账单。产品负责人确保故事完成。您的小组以某种方式得出结论，产品负责人应告诉您如何编程。

您想编写代码或制作出您认为很棒的简洁小应用程序？“我想先做A而不是B，这样我才能保持选择的自由。” 寻找其他的恩人，而不是新的发展方法。

您陷入了“项目所有者”标题之类的问题。如果您有合理的理由不同意这个故事，请说些什么，然后提出自己的观点。您可能不会总是赢。返回用户并让他们知道他们的请求存在有效问题是他们的工作。让我们面对现实吧，如果故事要求您全天随机删除数据库，没有备份，没有数据丢失或停机时间，那么您就有问题并有责任将故事弄清楚。

听起来您的敏捷之旅已被Scrum破坏了。我发现，在所有敏捷方法中，Scrum的敏捷性最低。它更像是微型瀑布和其他项目管理。当然，这使它成为管理人员最喜欢的，他们认为他们正在从那些讨厌的开发人员手中夺回控制权，但是您当然可以看到实际情况。

敏捷并不是要遵循规定的路径，而是旨在提高您的生产力和动力。宣言说的不是人为处理，而是在您使用的系统中丢失了。

所以改变它。向管理层提出来，并说这是一个倒退的步骤，您的生产率比以前要低，并且您都对它的工作方式不满意。向您展示敏捷宣言（及其邪恶的孪生兄弟），并证明您不仅从该实验中学到了东西，而且还希望将其中的好点发展成一个更好的系统（就像您以前所拥有的那样，它似乎运作良好）为了你）。

我认为，只是你们已经习惯了拥有更多所有权，而我认为每个人都更喜欢它的人性。

不幸的是，我认为很多软件都不够用，因为很多部分通常是为开发人员而非客户编写的。您的新方法应减少这种情况，但要以牺牲主人翁感为代价。

我不知道如何建议您让事情变得更好或更有趣，但这是一个很好的问题，而且很有见识。

您是否以“作为角色–我想要-目标/愿望-这样–受益-”的形式获得用户故事？听起来您的产品负责人想要进行设计工作，但他/她可能不是这样做的最佳人选。使用用户故事模式可以帮助确保产品负责人坚持业务利益，并且软件开发由软件开发人员完成。

在Scrum中，开发人员有足够的空间来做出贡献，并就新功能，UI，可用性等方面提供建议。Scrum中需要业务人员与开发人员之间的协作和对话，并且允许。但是最终，产品所有者将拥有最终的决定权，因为他是负责使每个sprint所产生的软件增量（即ROI）最大化的商业价值的人。

从敏捷宣言：

我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。

但是，产品负责人告诉您如何实现UI和功能是不可接受的。在这种情况下，您应该拥有最终决定权，因为您应对所生产软件的内部质量负责。

也许您在一家由开发人员创建的公司中工作，程序员可以自由实现他们想要的任何功能。但是，大多数敏捷方法将业务领域的人员与负责生产软件的团队（开发人员，测试人员...）区分开来，这在大多数地方是最常见的工作部门。如果我的假设是正确的，我可以理解您的感觉，即您不再能够“对全局产生影响”，但是随着公司的发展，我想无论如何都会出现这种情况。

关于您提到的分析，设计和其他元开发活动（同样不应该由产品负责人完成），敏捷团队应具有跨职能且不受任何限制。没有人应该拥有围绕一项特定开发活动的所有知识，因此也许有机会让您多样化，而不仅仅是“代码伪装”。

相反，我发现让产品负责人对功能进行决策可以使我将更多的时间用于生成高质量的代码。另外，如果存在合理的顾虑，我总是可以质疑产品所有者的决定，这通常会导致富有成果的讨论。

我们在这里练习Scrum。我们每两周召开一次计划会议，提供当前业务优先级以及上一个冲刺的成功和失败，然后，我们作为一个团队，决定下一个冲刺需要解决的问题。

我们执行此操作的方法之一是按垂直方向上的复杂度和水平上的业务优先级对板上的积压进行排序。在那之后，产品负责人得到了他的意见，因此，由团队来选择我们想要做的事情。显然，挑起高复杂性，低优先级的任务是不受欢迎的，但是我们正在将其作为一个团队来决定。它使计划会议时间更长，但这是值得的，并且是敏捷过程的核心部分。

而且有时候我们确实有微观管理，但这是一个不同的问题。

当团队采用方法论时，您要描述的真正问题是一种常见的病态：他们会闭上大脑。对于新式敏捷系统，这与旧式重量级系统一样。

问：方法论规定了x，但是x效果不好。我们应该做什么？

答：完善x的实现。也许完全停止这样做。方法论不是您的老板！

在这种特定情况下，听起来产品负责人可能做得太多。您能和他谈谈吗？如果您不“做争吵”，您会感到很舒服吗？如果产品负责人对建设性反馈不敏感，那不是方法问题，而是产品负责人的问题。

我不太适应整个Scrum事情，因为已经有一段时间了。

但是，老实说，这听起来更像是管理人员问题而不是项目管理技术问题。在这种情况下，基于人的人数要多于基于技术的人数。

领导者在自组织团队中的角色将是一篇博客文章，内容似乎是您的文章中缺少的内容。团队在哪里决定在sprint中完成什么工作？团队在流程和工作中的主人翁在哪里？您是否有一个对Scrum足够了解的人，知道您正在做Scrum，而不是它的某些变态版本？

我在Scrum上也有过同样的经历，喜欢称其为“故事的暴政”。

从我的经验来看，与从事后端工作的人员相比，在创意/设计/前端方面的开发人员似乎遭受的痛苦更大。

到目前为止，我发现的唯一出路是放弃Scrum（通常是不可能和/或适当的，因为毕竟它有其优势），或者引入类似于Google的20％的时间来为开发人员提供创造性的渠道，而不仅仅是“您”可以自由选择如何实现“ 登录页面 ”，因为实际上您并不受现有代码和系统体系结构的限制，除非您考虑在“ for和while循环”之间自由选择自由。

您决定做什么或被告知要做什么之间有很大的不同。

根据我的经验，从被告知要做什么到决定要做什么只有很长的路要走。

在这种方式的最后，通常结果是我们被指示不是因为他们喜欢权力，也不是因为他们无事可做。相反，在这种方式结束时-当他们对我们的团队获得足够的信心时-他们似乎松了一口气，并高兴地将尽可能多的控制权交给了我们（如果他们的信任确实坚定，他们甚至会尝试通过比那更多的）

哦，以我的经验，这基本上与Scrum /敏捷无关。发生了Scrum，迭代，瀑布之类的事情。似乎信任问题与过程无关

在我们的团队中，产品负责人告诉我们该怎么做，然后我们决定如何做。进行这种分离非常重要，否则您最终将遇到上述情况。

根据我的经验，Scrum可以深入地观察您的工作。它只是坐在你的肩膀上，看着你在做什么。尽管它有自己的优势，但我讨厌使用scrum方法。它期望计数，而不是质量。Scrum方法论正在损害质量。