敏捷是新的微观管理吗？

这个问题一直困扰着我一段时间，所以我想问那些在开发环境中遵循敏捷/敏捷实践的人。

我的公司终于冒险融入敏捷实践，并从一个由4个开发人员组成的团队开始在一个敏捷团队中进行试用。到目前为止，已经进行了3个月的迭代，为期4个月，他们继续这样做，而对我们其他人来说却没有足够的敏捷性。这是由于以下事实：管理层信任高层提供的大量临时类型请求，可以满足业务需求。

最近，我与参与该计划的开发人员进行了交谈。他们告诉我这不好玩。他们的Scrum管理员不允许他们与其他开发人员交谈，也不允许他们在工作区域内拨打任何电话（可能在一定程度上可以）。例如，如果我想和敏捷团队中的朋友聊天，未经Scrum主管的允许，我是不允许的。坐在敏捷团队旁边的人。

所有这一切或敏捷的想法是为敏捷开发人员提供一个不受干扰的完整真空，并将其投入6个以上的生产小时。好吧，伙计们，我不是敏捷专家，但是我读过Yahoo敏捷发布文档以及其他组织的类似文档时，给我的感觉是敏捷并不便宜。团队需要敏捷的资源和预算来灌输敏捷性，并在他们到达时纠正问题，使他们重回正轨。

对于初学者来说，它需要为开发人员提供培训，并为经理等提供指导。等等。目前的Scrum主管是一位经理，他参加了为期两天的敏捷培训课程，该课程由管理层支付，现在领导这个敏捷团队。我在会议上还听说过，敏捷宣言并不表示敏捷不是一成不变的，而是为每个公司定制的。好吧，这听起来不错，也很合理。

总之，我一直认为敏捷应该在开发团队中带来和谐，从而使开发人员感到满意。但是，当与敏捷团队中的开发人员交谈时，我的感觉却截然相反。他们为自己除了工作以外什么都不会说话感到不高兴，他们整日坐在办公室里安静地工作，他们觉得这是管理层提高工作效率的另一种方式。

请告诉我，这是否是为了获得更多美元而自私自利的良好做法的例子之一？也许是像我们这样的开发人员才是我们，这个敏捷的团队认为他们不喜欢在只能呼吸工作的环境中工作。

这是一家医疗保健领域的公司，在美国设有办事处。绝对感觉像是牛仔风格的敏捷，这使我真的根本不想去敏捷，尤其是在我目前的公司中。

所有这些都与管理完全便宜有关。削减昂贵的咖啡以获得更便宜的版本，强调节约和生产，同时保持尽可能的瘦。

我的感觉是，门后的管理层中有人拒绝了这个想法，敏捷使您可以生产更多，因此我们可以向我们的老板展示我们正在以相同的人数生产更多产品。或者，如果是这样的话，它可能使我们减少人员。

他们每天开会5分钟。但不允许与团队以外的人聊天或交谈。所有重点都放在工作上。

您是在描述管理专政，而不是敏捷。敏捷是指在不断变化的需求领域中进行增量开发，而不是指示人们如何进行个人工作。

他们的Scrum管理员不允许他们与其他开发人员交谈，也不允许在工作区域拨打电话

这实际上不是敏捷实践的一部分，而是一个单独的问题。

敏捷方法的一个主要动机是增强开发人员之间的沟通。限制开发人员与开发人员的沟通是与敏捷实践不同的问题。我并不是说这没有发生-显然是这样，并且它被标记为组织中“敏捷”部署的一部分，但这实际上与敏捷是一个独立的问题（并且在一定程度上违背了敏捷开发的精神， IMO）。

这听起来像是敏捷的相当不正确的实现。敏捷（如果有的话）应该减少而不是增加微观管理。团队做出承诺，并且流程的一部分是管理层相信团队将完成承诺。日常混乱是开发人员彼此交流的一种方式，是一种通知他们所做的事情的方法，而不是告知他们如何度过的时间（这是我在几个地方看到的一个错误）。甚至估算过程也应该从估算中删除明确的时间保持，因为您应该估算相对复杂度，而不是故事要花多长时间（另一个常见错误）。控制开发人员所花费的时间是微管理的标志，从流程中节省时间是敏捷的核心原则之一。

您描述的环境听起来像是花园里的各种伪敏捷胡说。

在敏捷开发之前，我就参与其中。大约在2000年，我精疲力竭地编写代码，听说了极限编程，尝试了它，并喜欢它。作为开发人员，它为我提供了一个环境，在其中生成可靠的软件是最重要的事情，并且它为我提供了一些工具，可以最大程度地减少使我发疯的废话。我爱它。

我今天在其他地方详细解释过的问题是，当今大多数“采用敏捷”的人对使人感到不舒服的任何事情都不感兴趣。因此，对于他们来说，“敏捷”只是以相同的旧方式击败开发人员的新工具。相对而言，这是一种从根本上提高生产率的方式，同时消除所有使发展速度放慢的废话。

马上。我正在建立一家公司，并且将使用大量XP，以及在敏捷世界中积累的其他技巧。但是正是由于像您这样的故事，这些天我听到敏捷采用时都会畏缩。

因此，直接回答您的问题：敏捷不应该是新的微观管理。它应该是要授权进行实际工作的人来完成。但是就您而言，敏捷听起来像是他们在放纵自己的不良本能时告诉您的最新谎言。为此我深表歉意。

这不是敏捷的。

首先，Scrum不敏捷。坦率地说，Scrum是胡扯。我在一个极限编程的房子里长大（从字面上看-我让肯特·贝克坐在我父亲的沙发上，和我谈论测试），我可以直接告诉你Scrum不是。Scrum是项目管理工具-开发项目的定义节奏。但是它没有关于开发本身的任何内容，也没有关于需求，计划以及与客户之间的关系的任何内容。XP有很多话要说。任何其他自称为敏捷的方法都必须在对话中添加一些内容。支持Scrum的人将其描述为不是过程，而是过程的包装。曾经有位智者指出，包装是您为了得到好东西而将其删除并丢弃的东西。

好吧，乱七八糟！

其次，我认为XP的基本原则是以开发人员为中心，这是任何敏捷过程的基础。这是一种使开发人员有能力去完成他们知道需要做的工作的方法，而这种工作经常被停止进行。敏捷团队的结构可以是民主制或专制制，但领导者是开发商。项目经理有一些角色，等等-至关重要的角色-但这不是团队领导之一。有一个经理-对不起，“ scrum master”-坐在那里向周围的人做老板是一个确定的信号，表明团队没有在敏捷。

我觉得应该有三分之一。没有。

Scrum是敏捷的混蛋。它是所有敏捷方法中最瀑布式的，这就是为什么它在管理人员中最受欢迎的原因。

所有敏捷方法都是在不妨碍的情况下生成工作代码。再读一遍。然后再次。

不管“敏捷规则”如何，阻碍该目标的任何事情都是不好的。如果规则受阻，请更改f * *规则！这就是敏捷的方式，这才使它变得相关且有效。

的最好的例子的，这是通过阿利斯泰尔科伯恩（敏捷宣言创始人之一）给出：

“将4-6人放置在一个配有工作站和白板并可以与用户接触的房间中。让他们每隔一两个月向用户交付运行中经过测试的软件，否则就别管它们了。”

如果这对您拥有的人的素质有用，那么这就是您所需要的。您不需要Scrum Master或任何“敏捷”方法。如果每天坐下来为您工作，那么f * * *这样做。让你站起来只是对自己思考能力的可悲废止。

对您正在执行的敏捷有反应。它的。打印出来并将其固定在没有其他人在附近的地方，让他们自己发现它。

目前的Scrum主管是一位经理，他参加了为期两天的敏捷培训课程，该课程由管理层支付，现在领导这个敏捷团队。

那是你的问题。管理层想要一些敏捷，他们并不真正知道它是什么，而是将其强加给团队。当您想显着降低开发人员的工作效率时，这几乎就是要做的事；）

新的流程建议应来自开发人员。或者，如果这是管理层的想法，至少要经过他们的审查和批准。

无论如何，如果开发人员拒绝它，请不要执行它！否则将是您描述的灾难。

经常滥用“敏捷”和其他所有“管理方法”来对人们进行微观管理。OTOH有时也被滥用来捍卫做工差。

我听到的最常见借口是：缺乏规划，缺乏对设计，功能，质量和发布周期的思考。这通常来自开发人员和较低的管理层。这也是我从中层管理人员，建筑师，销售人员等那里听到的最经常使用的借口，用于微管理，不断变化的截止日期和功能列表，迫使人们进行大量的加班（不断变化的截止时间和功能列表当然可以确保这样做）等等。 。

当然，这两者通常是直接矛盾的，并且可以在同一项目中发生。

要回答您最初的问题，敏捷是新的微观管理吗，我会拒绝。

首先，请阅读此内容（敏捷宣言），您会发现未列出与您的共同开发者交谈的内容。

实际上，“个人与互动”与不与您的共同开发者交谈是完全相反的。

敏捷应该是新的自我管理。 如果正确地实践了敏捷，则许多决定都是由客户和开发人员通过合理范围内的用户故事来做出的，当确定任务时，该故事就会添加到积压中。

每天的讨论都是关于沟通，而不是管理。 将会有一些关于优先级和负载平衡的讨论，但是希望由Scrum管理的人是Scrum管理员。作为一名开发人员，我参加了会议，并说了我做了什么，我将要做什么以及需要什么帮助。然后，Scrum主管应采取行动清除阻碍我前进的障碍。

敏捷团队一定不能感觉到日常工作是分层管理的。 如果决策是由高层组织的高层远距离做出的，那么现在是分散决策权的时候了！对于某些人和某些组织来说，这可能是一座桥梁。如果您的组织不符合以下条件：

活出敏捷宣言

“我们正在探索通过开发和帮助其他人来开发软件的更好方法。”

避免“遇到新老板，和老老板一样”。 尽可能从团队内部发起敏捷。有时，这是通过选择愿意使用敏捷进行试验项目的联盟来实现的。如果您可以由拥有良好团队合作记录的志愿者或受邀成员组成敏捷团队，则他们可以解决问题。在小型项目中使用小型团队，可能是针对内部人员或易于访问的客户。

拥抱变化。也许您可以接受一些培训，但也许您的预算很紧张，而且钱不多。其他机会也可以提供改进。做一些阅读，让团队成员学习他们对敏捷的了解并互相教teach。您可能能够找到新手或现有人员，有资格进行建模并领导敏捷采用。

敏捷团队就像橄榄球队一样，为达成一个公认的目标而努力。我加入敏捷团队已有数年了，关键是在所有利益相关者之间进行有效而高效的沟通。经理/ Scrum管理员仅仅是团队的推动者，而传统的管理/微观管理将扼杀团队的精神。

在我工作过的团队中，我们鼓励下班后参加团队游戏，以提高成员之间的友情。我在这里收集了这些想法。

要回答您的问题：不。敏捷不是微观管理的一种形式。但是像其他任何工具一样，人们可能会错误地使用它。如果实施得当并且与人们保持一致，敏捷就是很棒的选择。

我对“开发人员除了和Scrum管理员没有对话以外的其他话题”的想法是：

我曾在以前那是常规的地方工作过。但是，该规则更多地与要求人们完成任务有关。例如，我不能随意去找开发人员测试人员并要求他们在接下来的几个小时内为我做一些测试。我需要与Scrum负责人交谈，以便他们可以与团队成员讨论在紧急情况下（或者如果需要将其推送到待办事项以进行将来的Sprint）该工作如何适合sprint。

在那种情况下，我理解“开发人员不互相交谈”的概念，因为它确实转换为通过一个检查点进行的任务分配，因此特定的开发人员不会过度劳累或忙于执行紧急任务，以致他们无法按计划进行完成工作。

否则，开发人员应该互相交谈。总是。它可以帮助您更快地解决问题，与团队保持紧密联系，并更快地交付。

只是为了提供另一种观点：我也曾在人们认为开发人员“交谈过多”的环境中使用。坐下来后，我们发现实际上翻译成“开发人员不够独立，无法完成自己的工作。由于一切都分散了，开发人员必须去找另外三个人来完成小任务。”

因此，当经理们决定采用敏捷方法时，他们希望这样做有助于将信息带到正确的位置，并阻止组织内部的许多分散性。有人对实施敏捷后感到失望，开发人员仍在彼此之间来回奔波。但是，他们没有意识到的是发生的事情越来越少了。虽然花了时间。因此，也许这就是组织中正在发生的事情，那可能是人们期望敏捷能够在一夜之间解决问题。那不是它的工作方式。

原始作者史密斯·简斯可能有经验。但是这些是我在敏捷项目中发现的典型问题。

1. 大多数组织（开发人员）都应该在敏捷/ scrum中的多个项目中工作。您的Scrum管理员认为您应该在sprint结束时完成故事。.您的Scrum管理员可能只致力于一个项目，而不是开发者。.这就是麻烦-不必只是打个电话或允许打个电话。
2. 我见过计划Sprint的敏捷项目，Sprint中包含的故事，而没有被缩..在Sprint的一半或中间..开发人员发现依赖关系未解决，需求或故事未完成叙述。.....是大多数敏捷项目中的滥用行为之一。
3. 测试：TTD ..是的，它非常好..但是我看到大多数敏捷项目完全依赖TTD ...在功能或人员测试上没有范围或时间。.另一个滥用...很多Scrum大师不了解或不了解功能测试的重要性。如果不满足业务需求，您的代码段可能会完美地工作..没有用。.当业务未如愿以偿地参与时..或参与其中...但未反映业务决策时，会发生这种情况..最后，开发人员被指责，您未交付功能..否则最终结果将在最后一刻发生变化...额外的时间，因为您的Scrum管理员不想为故事未完成负责。

这里的滥用...业务参与度低或参与者知识不足，或者业务人员在冲刺中退出。

1. 并非所有项目都适合敏捷...大多数管理人员或Scrum管理员都不知道这一点。花了4个小时后，发现这是Java /其他产品...（我最近在我们的项目中遇到了与Quartz Scheduler ..相关的处理缺陷），并且该缺陷可能导致产品/软件包的升级。资金，新版本或升级应由内部工程部门等批准。5.回顾：只有少数敏捷项目可以执行此步骤。如果完全完成了管理，Scrum Master绝不对失败的故事承担任何责任。
2. 结对..很多开发人员将结对视为虐待同事的场所。.批评其他设计，编码实践..将评分者视为团队工作。，互相学习...滥用敏捷/混乱的另一种方法。

敏捷绝对是一种好的方法。.除非您的组织没有完全遵循或没有接受培训。...被滥用了....副作用60+每周工作小时以上，责备游戏，道德低下。

敏捷是变相的微观管理。敏捷中没有主动权或创造力的地方，它消除了编程的乐趣，即使没有技术角度的帮助，无能的经理也可以保持控制。