it-swarm.cn

敏捷是新的微观管理吗?

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

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

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

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

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

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

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


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

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

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

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

81
Smith James

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

89
Sami Lehtinen

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

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

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

46
Reed Copsey

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

31
jjb

您所描述的环境听起来像是花园的变种伪敏捷的胡说八道

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

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

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

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

24
William Pietri

这不是敏捷的。

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

好吧,乱七八糟!

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

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

23
Tom Anderson

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

所有敏捷方法都是关于生成有效代码而不会造成麻烦的。再读一遍。然后再次。

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

最佳示例 由Alistair Cockburn(敏捷宣言的发起者之一)给出:

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

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

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

16
gbjbaanb

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

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

新的流程建议应来自开发人员。或至少是由开发人员审查并批准(如果这是管理层的想法)。

无论如何,如果开发人员拒绝它,不要实现!否则将是您描述的灾难。

11
user2567

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

我听说“我们很敏捷”是缺乏计划,缺乏对设计,功能,质量,发布周期的思考。这通常来自开发人员和较低的管理层。这也是我从中层管理人员,建筑师,销售人员等那里听到的最经常使用的借口,用于微管理,不断变化的截止日期和功能列表,迫使人们进行大量的加班(不断变化的截止时间和功能列表确保了这一点)等等。 。

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

9
jwenting

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

首先,请阅读 this (敏捷宣言),您会发现未列出与您的共同开发者交谈的内容。

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

7
Ian

敏捷应该是新的自我管理。如果正确地实践了敏捷,那么许多决定都是由客户和开发人员在合理范围内的用户故事中做出的。确定任务后将添加到待办事项列表中。

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

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

活出 敏捷宣言

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

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

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

2
DeveloperDon

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

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

1
Vinod R

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

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

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

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

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

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

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

0
JustBlossom