别再空谈敏捷开发了

更新日期: 2019-08-28阅读: 2.1k标签: 开发

现如今,“ 敏捷 ”可以是指任何东西。渐渐地,它就变得毫无意义了。很多企业已经对”敏捷“感到厌倦了,甚至有了抗拒性。

更糟糕的是,就像孔子说的那样:“当言语失去意义时,人类也就失去了自由”。在一些企业里,“敏捷”已经变成了某种“命令和管理”的化身。Kent Beck 一语道出了很多身陷其中的人的沮丧:

我在南非参加敏捷大会时,有人走过来对我说:“我们想开发软件,但无法忍受这些敏捷仪式。我们只是想写一些程序而已,至于这样吗”。我不禁热泪盈眶……我们怎么又回到了 20 年前的水平了呢?

这个问题问得很好,这是一个非常重要的问题。他们还提出了其他一些问题,比如“我们将何去何从”?Ron Jeffries 最近提出了 一个非常现实的可能性:

是时候尝试一些新东西了:开发人员应该放弃“敏捷”了……我真的认为不管哪个领域的软件开发人员都不应该再坚持任何形式的“敏捷”方法了。正如这些敏捷方法在实际当中所呈现的那样,它们更像是软件开发人员的敌人,而不是朋友。

无论我们要去到哪里,我们首先必须承认的是,我们当中的很多敏捷实践者本身就是问题的一部分。正如 Pogo 对 Porkypine 说过的一句名言:“我们遇到敌人了,就是我们自己”(Walt Kelly《 Pogo》)。Martin Fowler 在 2018 澳大利亚敏捷大会上是 这样说的 :

将“敏捷工业综合征”强加于人,这绝对是一种曲解。我本来想说是“悲剧”,但“曲解”这个词更好些,因为在软件开发中没有放之四海而皆准的东西。即使是敏捷拥护者也不会说敏捷可以被用在任何地方。关键在于团队如何去做。这是敏捷的一个基本原则。也就是说,如果团队不想使用敏捷方法,那么敏捷在这种情况下可能是不合适的,而不使用敏捷方法是他们在某种扭曲的逻辑世界中做事的最敏捷的方式。所以,敏捷并将其强加于人才是首要的问题。这是我们必须要反对的。

敏捷工业综合征、暗黑敏捷、虚假敏捷、僵尸敏捷……这些更糟糕。所以,一位企业心理学家朋友说:

敏捷是一种病毒,正在企业中蔓延。对于不断增长的阻力,你不应该感到惊讶。因为每当有抗原入侵时,抗体就会这么做。

强加的敏捷看起来就像是入侵。因为业务转型“专家”对企业变化心理学知之甚少。一个很明显的例子:当你宣布某人为“Master”时,你意识到这样会带来多大的阻力吗?尤其是当他只经过为期两天的培训的时候!

我不敢告诉她的是,“教练”其实也只是经过两天的培训而已。最近,我还听到有一位“教练”问我:“要做好敏捷,必须要有一个非常好的项目经理吗?”

“是的,一流的项目经理、迭代经理、Scrum Master,不管你怎么称呼他们都好,他们一般说话温和,但手里握着一根大棒(美国总统罗斯福,提倡大棒政策,即以军事为背景推进外交)!”

我再次热泪盈眶。

我的一个客户在研究了认证领域的业务后,创建了自己的认证系统。数十位 Scrum Master 和产品经理自豪地在他们的公司里展示它:Agile Yahoo。

我们将何去何从?


内部策略——在敏捷世界的内部

内部策略是一项广泛而全面的策略,或者说是一项具体的计划,甚至是一项简单的管理内部事务的原则。

在这个敏捷爆发的年代,先让我们来澄清一下“Agile agile agile”的含义。

一个简单的 原则 :任何形式的“敏捷”都必须显式或隐式地参考敏捷宣言的 4 个价值观和 12 条原则,必须包含敏捷“线索”。

我们必须回到未来,回到根本,回到基础。敏捷需要被重启。“敏捷”团队应该定期回顾敏捷宣言和 12 条原则:敏捷意味着什么?我们实践得如何?我们如何才能继续朝着这个方向前进?

它的部分含义是,如果想要让“敏捷”实践保持敏捷,就必须不断地做出调整。“简单即要素”(12 条原则之一)就是一个敏捷“线索”,我们必须喝下自己的“酷爱”饮料(意思是自己对自己负责)。

Dave Thomas 说,这是这么简单:

找到自己的位置。朝着目标迈进一小步,基于你所学到的东西调整自己。然后重复这一过程。

类似地,Alistair Cockburn 博士的“ 敏捷核心 ”是一种基于简单框架的不可知论方法:协作、交付、反映和改进。Joshua Kerievsky 的“ 现代敏捷 ”基于四个简单的原则:让人变得优秀、把安全作为先决条件、快速地试验和学习、持续地交付价值。


外部策略——敏捷世界之外

外部策略是一项广泛而全面的策略,或者说是一项具体的计划,甚至是一项简单的管理外部事务的原则。

在这个敏捷爆发的年代,让我们第二次来澄清一下“Agile agile agile”的含义。

当敏捷实践者这个群体开始驶向其他领域时,不可避免地会发生文化冲突。

早期的敏捷探险就像是炮艇外交。我们对项目管理领域的征服已经接近完成。

现在,我们进入到一些奇怪的新领域,比如人力资源,并遇到了企业心理学家,他们的资历比我们还高。

那么我们的外部策略是什么呢?我们把自己看成是掠夺者还是商人呢?

我们要警惕一种天真的、最终会导致自我失败的殖民主义心态,这种殖民主义假定了一种优越感,即认为当地人为了他们自己的利益和我们的利益,需要接受我们的文化“入侵”。

我们也要警惕我们自己的同化,就像曾经可怕的维京人消失在传说的迷雾中一样。例如,我是众多敏捷学家中的一员,他们正在将敏捷与积极心理学、欣赏式探究和以解决方案为重点的简要治疗方案相结合——参见我的一篇有关以解决方案为重点的敏捷的 文章 。与此同时,越来越多的“敏捷者”完全放弃了“敏捷”,因为他们已经完全融入了其他世界。

我们的外部策略不是朝着一个大熔炉,而是朝着一个什锦沙拉的方向努力。

下面的冲突解决矩阵很好地演示了这种 方法 。我们的立场不是竞争(敏捷赢了),也不是要屈服(敏捷输了),而是要协作(业务赢了)。


这是美第奇效应(Medici Effect)的一个例子。2006 年出版的《美第奇效应》(The Medici Effect,作者 Frans Johansson )对我的思想产生了革命性的影响。“美第奇效应”这个名字源自 14 世纪的一个引发了欧洲文艺复兴的意大利家族,指那些在不同学科、文化和行业领域发生的“大爆炸”碰撞中迸发出来的突破性思维和颠覆性创新。这个想法引起了我的共鸣,因为我从小就喜欢做大爆炸实验。

美第奇效应回答了一个我偶尔会被问到的问题:为什么我很少参加敏捷活动?敏捷社区其实是很重要的,但美第奇效应让我不断地超越我所知道的人和事的边界。我很快发现,对于我来说,我所得到的启迪和突破更多地来自与军官、宗教领袖、诗人、哲学家、生物学家和心理学家的互动。我一生当中的大部分工作是把这些相关的(有时是不相关的)学科之间的点连接起来,并尝试不同的工作方式。


结论

跨学科研究、原则和实践是敏捷的未来。只要我们想要继续使用“敏捷”这个名字,就必须追根溯源。请不要再空谈“Agile Agile Agile Blah Blah Blah”了。

作者简介 Maurice Mo Hagar 是美国的一位企业敏捷教练,之前曾担任 CIO 的职位。他帮助全球 60 多家财富 500 强企业加速组织变革,提升绩效和产出成果。他的专业领域包括敏捷、解决方案焦点、战略预见和设计思维。

原文链接:Maybe Agile Is the Problem

链接: https://www.fly63.com/article/detial/5009

软件开发教给我们的7个生活指南

我们在做软件开发时学到的很多思维、方法、工具、模型、算法……其实可以迁移到生活中使用,让我们生活得更美好哦。我这里暂举 7 个,以后有时间,慢慢补坑,争取补到 60 个。大家有兴趣的,可以留言补充你最有感觉的。

时间复杂度与空间复杂度分析

作为开发人员,我们都希望在完成功能的基础上让代码运行的更快、更省空间,那如何衡量编写的代码是否更有效率,这就需要我们学会如何分析代码时间复杂度和空间复杂度.

12 个概念,让 JavaScript 开发更加简单

JavaScript 是一门复杂的语言,不管处于什么样的水平,都有必要了解 JavaScript 的基本概念。本文介绍了 12 个非常重要的 JavaScript 概念,但绝对不是说掌握好 JavaScript 只需要知道这些就可以了。

js处理时间时区问题

服务器时间是东八区时间,页面会在全世界各地,页面 JS 功能需要对比服务器时间和用户本地时间,为兼容世界各地时间,需要将用户本地时间转换为东八区时间

敏捷开发

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

敏捷开发是如何被跑偏的

先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。

敏捷开发中如何做质量管理?

敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。

写给开发人员:为什么朝九晚五不适合我们?

位我很尊敬的高级开发人员给我打来电话。他想找个朋友聊聊:因为担心自己只能得到可怜的 12% 加薪——而他所管理的其他初级开发人员,则有望获得 40% 的加薪。他还抱怨道

不想谈业务的开发不是好开发?

业务,似乎与开发人员不是太相关,开发人员天生处于技术端。但是,一个只会开发的开发人员,很容易被代替,只有真正了解业务,才能真正了解需求,做出好的产品。那么如何去解决这些问题呢?

前端开发人员最困扰的事情有哪些?

前端和后端开发之间的界线正在发生变化。有一些常见的错误会导致前端开发人员增加工作量、浪费时间,本文将介绍一些常见的错误以及如何避免这些错误。公司向他们的开发人员和程序员提出更多的要求

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!