敏捷真正使谁受益?

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

Opensource.com

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

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

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

敏捷的支持者赞扬其对个人的关注、在快速的时间表上构建可工作软件的要求以及快速轻松地响应变化的能力。看板和每日站立会议等流程受到许多已在其团队或组织中转向敏捷实践的人的赞扬和推广。

但敏捷并非没有批评者。批评者说,当花费太多精力维护流程本身以追求流程时,敏捷可能会浪费时间,并且它根本不兼容某些性格类型、工作方式和某些类型工作的需求。他们甚至可能因频繁的签到而感到受到微观管理。虽然敏捷可能对管理层有效,但对他们无效。

那么您怎么看? 显然,敏捷在整个软件行业中持续得到采用。但这是否使每个人都受益? 如果没有,真正的受益者是谁?

标签
User profile image.
杰夫·马卡尼克在红帽工作了九年多,目前负责红帽的创意服务团队。在多家电子商务公司取得不同程度的成功后,杰夫成为 Akopia 的最初员工之一,该公司基于 Interchange 平台交付电子商务解决方案。

10 条评论

实施“敏捷”和真正敏捷之间存在差异。如果您发现精力浪费在维护流程上,我敢说您做错了。回到基础,停止实施一成不变的解决方案。

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

对于适合 2 到 4 周增量的迭代,没有适当的分析和适当的计划是敏捷失败的原因。

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

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

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

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

如果不针对这些主要领域进行良好的分析,您的团队尝试构建的软件将面临很高的失败风险……

回复 作者:吉米·肖伦德

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

我见过敏捷做得非常好,也见过非常糟糕的情况。我的经验是,当敏捷做得不好时,基本上只是采用冲刺,而没有做其他任何可以被认为是敏捷的事情。整个产品仍然使用瀑布式管理。从好的方面来说,我见过敏捷做得非常好,并产生了一些出色的成果。KPI 是一个精心准备的积压工作和与 PO 的良好工作关系。在好的例子中,团队来自更传统的基于流程的组织,他们适应良好,我们发现信息共享和跨团队协助以及信息共享非常棒。真正敏捷的团队发现任何问题的唯一时间通常是与非敏捷团队打交道,并因等待他们的流程而受到拖累。

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

在敏捷出现之前,全球已经构建和部署了成功的软件项目…… 它们失败的唯一原因是缺乏良好的软件工程原则,例如有效的分析或计划或质量测试。

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

回复 作者:拉斯达德

它证明了经理职位的合理性,而经理往往是资源的浪费。此外,敏捷始终通过“如果它对您不起作用,那么您就做错了”的口头禅保持领先一步。行业中又一种荒谬的时尚,肯定不是最后一种。

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

嗨,姆拉登

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

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

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

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

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

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

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

遵循 AGILE 并不能构建可靠的解决方案,而是根据项目规模和团队需求,为 SDLC 的每个阶段投入所需的软件工程工作,以便构建可靠的软件以及良好的项目交付计划。

让我们不要仅仅因为它是趋势或酷炫的流行语而遵循流程,请确保您的团队遵循良好的软件工程实践,无论您想采用什么框架。

非常感谢您对我的回复的评论。

回复 作者:姆拉登·戈加拉(未验证)

良好的沟通始于尊重员工的经理。如果您的经理是混蛋,那么再多的流行语也无济于事。如果他们不是混蛋,那么流行语就无关紧要。

我遵循爱德华·约登和汤姆·德马科的结构化分析和设计。

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.