敏捷真正惠及谁?

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

Opensource.com

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

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

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

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

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

那么您怎么看?很明显,敏捷在软件行业中的采用率持续上升。但它是否对每个人都有好处?如果不是,真正的受益者是谁?

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

10 条评论

实施“敏捷”和保持敏捷是有区别的。如果您发现能量浪费在维护流程上,我敢说您做错了。回到基础,停止实施盒装解决方案。

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

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

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

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

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

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

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

回复 作者:jimmysjolund

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

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

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

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

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

回复 作者:Lhasadad

它证明了管理人员的工作是合理的,而管理人员往往是资源的浪费。此外,敏捷始终领先一步,这要归功于“如果它对您不起作用,那就是您做错了”的口头禅。行业中又一个荒谬的潮流,肯定不是最后一个。

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

嗨,姆拉登

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

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

我已经做了 30 多年的软件工程师,并获得了我的 Scrum Master 证书,以找出以下内容

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

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

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

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

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

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

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

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

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

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

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