敏捷真正让谁受益?

敏捷和相关方法一直因其改善沟通和提高效率而受到赞扬。 但它们真的让团队中的每个人都受益了吗?
251 位读者喜欢这篇文章。
A bunch of question marks

Opensource.com

每个人都希望改善他们在工作中的体验。

无论是提高效率、减少对需要做什么的困惑和焦虑、感觉自己的想法和反馈被听到和尊重,还是仅仅知道自己所做的项目正在产生影响,关于如何改善员工和雇主的工作性质,似乎有无穷无尽的想法。

在软件领域,敏捷实践一直是改进流程的最受关注的方式之一。但它们真的像宣传的那么好吗?

敏捷的支持者称赞其对个人的关注、在快速的时间表上构建可用软件的授权,以及快速轻松地响应变化的能力。看板和每日站立会议等流程本身受到了许多转向团队或组织敏捷实践的人的称赞和传播。

但敏捷并非没有批评者。 反对者认为,当花费太多精力来维护流程本身,仅仅为了流程而维护时,敏捷可能是一种浪费时间,并且它与某些人格类型、工作方式和某些类型的工作需求根本不相容。他们甚至可能因为频繁的签到而感到被微观管理。 虽然敏捷可能对管理有效,但对他们无效。

那么你觉得呢? 显然,敏捷在软件行业中继续被采用。 但它是否使每个人都受益? 如果没有,谁是真正的受益者?

标签
User profile image.
Jeff Mackanic 在 Red Hat 工作超过九年,目前负责 Red Hat 的创意服务团队。 在电子商务公司经历了多次不同程度的成功后,Jeff 成为 Akopia 的最初员工之一,该公司提供基于 Interchange 平台的电子商务解决方案。

10 条评论

实施“敏捷”和具有敏捷性是有区别的。 如果您发现精力浪费在维护流程上,我敢说您做错了。 返回基础知识,停止实施盒装解决方案。

我同意你的观点,并且从经验中发现,不知道如何有效地应用敏捷是失败的标志。

没有对可以在 2 到 4 周内完成的迭代进行适当的分析和适当的计划是敏捷失败的原因。

无论使用瀑布式还是敏捷方法,我们都长期以来一直在开发成功的软件。

只要我们在执行需求分析、计划、使用良好的编码技术和应用可靠的质量测试时遵循良好的软件工程原则,这两种方法中的任何一种都可以工作。

使用敏捷方法的大多数失败都是由于缺乏有效的需求分析会话。
在需求分析师过程中,至少,某人需要分析这 5 个主要领域,以构建软件解决方案,无论您的团队实践瀑布式还是敏捷式

1_ 定义预期的数据输出
2_ 定义所需的数据输入
3_ 定义生成输出的活动
4_ 定义执行活动的角色
5_ 定义活动业务规则

如果不在这几个主要领域进行良好的分析,您的团队正在尝试构建的软件将具有很高的失败风险......

回复 ,作者:jimmysjolund

首先不要将敏捷方法视为名词。我知道你一直听到这样的说法,但这是真的。作为一个名词,它被视为一套严格的规则。所以你必须遵循规则 a、b、c...如果你不这样做,那就停止一切,直到你这样做。人类交流(除非在军事术语中,在压力下也会崩溃)不是那样工作的。开发需要分享想法和辩论。现在,将敏捷方法视为指导方针,并将其调整为您的个人团队的沟通方式,可以有所帮助。为此,你需要一个清晰的领导结构,并且这些领导者要足够聪明和自信,能够引导,而不是手把手地带领他们的开发人员保持在正轨上。

我见过敏捷做得非常好和非常糟糕的情况。我的经验是,当它做得不好时,基本上只是采用冲刺,而没有做其他任何会被认为是敏捷的事情。整个产品仍然使用瀑布式管理。好的一面是,我看到它运作良好并产生了一些很棒的结果。KPI 是一个经过良好维护的待办事项列表,以及与 PO 的良好工作关系。在好的例子中,团队来自更传统的基于流程的组织,他们适应得很好,我们发现信息共享和跨团队协助和信息共享非常棒。真正敏捷的团队发现的唯一问题通常是与非敏捷团队打交道,并因等待他们的流程而变慢。

我不认为瀑布式实践有什么问题,只要它遵循了良好的软件工程原则,例如有效的分析和良好的质量计划和测试。

在敏捷存在之前,已经在全球范围内构建和部署了成功的软件项目...... 它们只有在缺乏良好的软件工程原则(如有效的分析或计划或质量测试)时才会失败。

如果敏捷不遵循良好的软件工程原则,也会失败。

回复 ,作者:Lhasadad

它证明了经理们的工作是合理的,而他们往往是资源的浪费。此外,敏捷总是领先一步,因为它的座右铭是“如果它对你不起作用,那么你做错了。” 行业中又一个荒谬的时尚,肯定不是最后一个。

嗨!
我曾作为 DBA 使用过敏捷,我只能说敏捷不太适合基础设施项目。然而,我被迫这样做。我在公司待了 6 个月,然后找了另一份工作。敏捷适用于需求快速变化的项目。不幸的是,代码质量经常受到影响。没有时间进行同行评审和项目设计评审,只有“冲刺”、“scrum”和“scrum 会议”。作为 DBA,我不得不说我对敏捷方法印象不深。受益最多的人是那些出售敏捷 PM 认证的人。

嗨,Mladen

我同意你的观点,即敏捷的唯一受益者是那些提供证书和出售书籍的人,这些书籍中包含使软件工程师感到困惑的新流行语。

我将坦诚地说,并敢于其他 IT 专业人士也坦诚。

我从事软件工程师工作超过 30 年,并获得了 Scrum Master 证书,以了解以下内容

1_ 需求被重命名为用户故事。
2_ 开发任务计划被重命名为 Sprint 计划。
3_ 改进会议被重命名为回顾。
4_ 团队负责人被重命名为 Scrum Master。
5_ 团队沟通被重命名为站立会议。
6_ 一个 2 到 4 周的计划被重命名为冲刺。
7_ 业务干系人被重命名为产品负责人。
8_ 干系人审查被重命名为 Sprint 演示。
9_ SDLC 阶段被极化为瀑布式,这完全是不真实的

以下关键角色从团队中移除
A_ 项目经理
B_ 业务系统分析师

老实说,敏捷给 IT 行业带来了混乱,迟早会被替换或调整,以帮助 IT 专业人员更有效地执行 SDLC 的所有阶段,包括计划、需求分析、设计、编码、测试和部署。

我不喜欢追逐流行语,我遵循良好高效的软件工程原则来构建可靠的软件解决方案。

遵循敏捷(AGILE)并不能保证构建可靠的解决方案。关键在于软件工程的工作量,需要根据项目规模和团队需求来处理软件开发生命周期(SDLC)的每个阶段,确定需要哪些工件,才能构建可靠的软件,并对项目交付进行良好的规划。

不要仅仅因为某个流程是趋势或热门词汇就盲目追随。无论采用何种框架,请确保您的团队遵循良好的软件工程实践。

非常感谢您对我的回复提出的意见。

回复 ,作者:Mladen Gogala (未验证)

良好的沟通始于尊重员工的管理者。如果你的管理者是混蛋,再多的流行语也没用。如果他们不是混蛋,流行语就无关紧要。

我遵循Edward Yourdon和Tom DeMarco的结构化分析与设计方法。

Creative Commons License本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.