后敏捷、无管理团队中的无序架构开发 引领潮流?宣言、极限编程与失败 开发者驱动开发与*DD 开发者无政府主义、自组织与无序架构

2025-06-10

无建筑学

后敏捷、无管理团队的开发

率先?

宣言、XP 和失败

开发人员驱动开发和*DD

开发者无政府状态、自组织和无架构

后敏捷、无管理团队的开发

软件团队通常需要一名人员作为连接企业和客户的桥梁。然而,他们真的需要这些可能从未开发过任何重要软件的桥接专业人员来管理企业软件团队吗?一个团队,尤其是软件团队,能够自组织吗?

胡说八道的经理

人类学家大卫·格雷伯在其著作《胡扯工作》(Bullshit Jobs)中,探讨了无意义工作的存在及其社会危害。在五种完全无意义的工作类型中,管理软件团队的非技术专业人员可以归类为“纸上谈兵者”和“任务主管”。这些经理人将纸面工作和肤浅的文档当作真正需要做的事情的替代。他们甚至可能制造额外的工作、不必要的负担、可避免的紧迫期限,以及不适合创意和技术团队的管理策略。多年来,我认识并共事过一些才华横溢的项目经理,他们绝对不属于这些类别,但我也亲眼目睹了这些胡扯的经理人及其类似的胡扯管理技巧造成的巨大危害。

“鲍勃大叔”马丁是《敏捷宣言》的原作者之一,他在题为“编程的未来”的演讲中,精准地解释了为什么大多数软件开发团队都面临着经理入侵的问题。他从数十年的实践经验(也就是我们今天所了解的软件开发历史)中,准确地指出了当今的软件开发专业人员缺乏自我管理和风险管理的纪律。你可以在这篇文章中看到他的演讲是如何引出我在这里提出的后敏捷时代情绪的:

企业造成了这一混乱

“……企业理解纪律……所以企业非常喜欢Scrum。他们喜欢Scrum是因为它的纪律性。他们喜欢Scrum是因为它简单明了——你可以进行这些小型冲刺,可以召开所有这些会议,可以制定这些计划,这对企业来说很有意义,企业于是认为:“是的,这个认证是个好主意。我们需要对员工进行认证。”

...因为他们不了解我们的技艺和学科

但是企业不理解我们——不理解程序员,尤其是不理解我们的规程。企业理解Scrum规程,但不懂结对编程、测试驱动开发、重构、简单设计。这些技术规程不属于企业的专业领域,也不应该如此。它们属于我们;是我们专业领域的一部分。因此,企业无法批准或认可它们……也无法评估风险。坦白说,风险是我们自己必须承担的……所以,作为专业人士,我们必须将风险作为我们日常专业运营的一部分来承担。而这正是专业人士应该做的。

... 因为他们让敏捷运动变成了管理上的混乱

“……[但后来]认证引发了项目经理的入侵。认证变成了一种诱惑,坦白说,它吸引了所有不该来的人。敏捷是由技术人员开发的。它是软件行业的产物。程序员们坐在那个房间里,制定了敏捷宣言和敏捷原则。然后认证出现了,随着认证的出现,大批项目经理开始争取认证。他们上两天课,拿到一张纸,就觉得这很重要。他们实际上接管了敏捷运动。敏捷运动急剧转向项目管理。”

...为后敏捷世界铺平了道路

“现在想想敏捷开发中发生的事情,你会想到看板,精益这个,精益创业那个。技术规程去哪儿了?程序员去哪儿了?坦白说,程序员都跑了。如果你现在去参加敏捷会议,你看不到很多程序员,也看不到很多技术路线。尽管他们努力……

Kent Beck 在 Snowbird 节目中说道,

“敏捷的目标是弥合业务和编程之间的鸿沟”

我认为[敏捷运动]已经彻底失败了……必须有人来引领……文明以它尚未理解的方式依赖于我们。以我们尚未理解的方式。

率先?

那么,谁应该成为引领者呢?是那些技术极限专家和工匠,还是那些对混合敏捷性充满热情的企业?又或者两者兼而有之?

Martin Fowler 在其关于FlaccidScrum的文章中解释了scrum(尽管不是一个技术框架)如何适应工艺最佳实践和纪律(例如 XP 或 TDD)。

为了维护Scrum,必须指出的是,仅仅因为它没有将技术活动纳入其范围,并不意味着它认为这些活动不重要。每当我听著名的Scrum开发者讲话时,他们总是强调,必须拥有良好的技术实践才能成功完成Scrum项目。他们并没有强制要求这些技术实践应该是什么,但你确实需要它们……

我总是喜欢指出,成功或失败的并非方法论,而是团队……许多人都期待精益成为下一个敏捷热点。但精益越流行,就越容易遇到与Scrum目前面临的相同问题。但这并不意味着精益(或Scrum)毫无价值。

它只是提醒我们个人和互动比流程和工具更有价值。

宣言、XP 和失败

敏捷宣言如下

我们致力于探索更好的软件开发方法,并不断实践和帮助他人。通过这项工作,我们认识到:

  • 个体和互动高于流程和工具
  • 可工作的软件优于详尽的文档
  • 客户协作优先于合同谈判
  • 响应变化而非遵循计划

也就是说,虽然右边的物品有价值,但我们更看重左边的物品。

XP 重视反馈、简洁、沟通、勇气和尊重。Agile 最初的最佳实践包括站立会议、故事、回顾、迭代、估算、测试、重构和持续部署。

大多数团队失败的原因在于缺乏XP价值观,以及/或者管理者的世界观——打着实用主义的旗号,优先考虑更快的交付速度,而不是以意识形态的名义,遵循敏捷交付原则。有些失败则比较温和,根据我的经验,是因为管理者让开发人员长期与业务问题脱节,以至于他们与过去的机器或电话接线员没什么不同。还有一些管理者宣扬这样的观点:QA工具和测试并非完成工作的一部分,而是一种奢侈品。

然而,最大、最陈词滥调的失败根源是将程序员视为一种

  • 不知道怎么说话
  • 缺乏“社交技能”
  • 无法理解客户的复杂要求

因此,企业需要引入一个神奇的中间人,来处理他们自己的非技术性管理策略和基于贪婪算法的产品交付策略。这些经理也永远不会同意以代码重构为中心的史诗级任务,更不用说彻底的修改和重写了。实际上,由于缺乏深入的技术知识,这些经理也无法做出理性的风险管理决策。

开发人员驱动开发和*DD

后敏捷运动主要是为了消除上述这些类型的管理者。我们不需要业务经理在经过几周的软件开发管理原则培训后就领导获得认证的软件团队。相反,我们需要一种相反的做法,让软件开发人员学习适合其领域的管理原则。没错,这甚至适用于团队中最初级的开发人员,因为了解特定领域的管理原则对每个领域的人来说都很有用。

Fred George 提出的后敏捷程序员无政府主义愿景,源于另一个深刻的认识:客户与开发团队之间推动软件开发项目的合作关系本身就存在缺陷,而且进展极其缓慢。与客户的合作关系应该仅限于定义他们的问题以及解决方案的理想特性,仅此而已。否则,我们本可以打造客户尚不了解的汽车甚至星际飞船,却只会制造客户梦想中的马车。

这种与传统和敏捷现状的彻底背离是可能的,因为开发团队了解业务指标、以客户为导向的开发,并遵循极其强大的持续反馈-持续部署周期。

从更根本的层面上来说,

如果你要开车,你需要让司机坐在驾驶座上

其次,如果司机是一位经验丰富的专业人士,你已经告诉他们要带你去哪里,

不需要后座司机

几十年来,我们已经认识到我们需要测试、特性、行为、验收测试、数据、领域、设计、模型,或者,如果你愿意的话,* 驱动开发。也许其中一个或多个符合你团队的需求,但如果开发人员本身无法驱动开发实践,那么这些都无法付诸实践。正如上述两位 Martin 所说,失败的是团队,而不是工具,应用正确的技术工具是技术团队的责任,而不是业务领域的责任。

开发者无政府状态、自组织和无架构

关注点分离是开发人员普遍秉持的价值观和常见的元设计模式,因此开发人员需要将同样的原则应用于其软件架构和开发团队的沟通结构。根据康威定律,这两者密不可分且相互影响

无政府主义:种子与需求

企业始终需要由业务经理来领导。软件开发始终需要由软件开发人员和架构师来领导。企业无需关注解决方案,因此应该将解决方案设计的控制权交还给开发人员,以保持正交性。企业仍然可以以敏捷的方式与软件团队合作,以正确定义问题,并就经过足够多的迭代后可能出现在解决方案空间中的任何潜在解决方案的所需功能达成一致。

显然,只有当您的开发团队拥有足够多具有行业经验的高级开发人员,并且所有成员之间有足够的沟通时,这才会奏效。作为一名专业人士工作与真正成为一名专业人士截然不同。但是,如果您有幸拥有一支由专业人士和渴望成为专业人士的年轻人组成的团队,那么每位开发人员都可以理所当然地成为他们所构建系统中各自领域的架构师。您不必总是采用微服务架构来实现这一点。只需让最有经验的开发人员创建一个功能核心,其他人则围绕它开发自己的命令式外壳部分,作为高效且集成良好的插件。更值得信赖的开发人员将负责与更重要插件的开发人员配对。

自组织超有机体

这种所谓的“后敏捷”技术仍然高度契合最初的敏捷宣言。然而,现在不再有程序员经理,他们那些错位的繁文缛节和错位的规则可能会限制技术创新和创造力。由于这些开发人员在早期迭代中尽可能地容忍失败,传统的经理们无论如何也无法提供可靠的进度指标。理想的无政府开发团队是团队成员主动承担起任何外部经理都无法预见的责任。这样的团队可以根据团队成员的特定子专业、兴趣和专长,民主地分配工作,而不是强迫每个人根据分配的“用户故事”从技术栈的顶部到底部完成一个故事或任务。这些开发人员将直接与产品负责人或客户合作,并建立比瀑布式开发或不纯粹的敏捷衍生产品所能提供的更多的信任。

因此,开发团队架构的一个重大变化是,开发不再由故事驱动。如前所述,客户应该提供正式、全面的问题描述,或许还能提供解决方案所需的功能,但绝不会直接参与解决方案设计和技术规范。无政府主义的团队不能容忍客户故事,因为这些故事会将开发人员与客户面临的实际问题割裂开来。客户和经理都没有足够的知识来告诉开发人员解决方案应该是什么或应该如何实现。如果他们这样做了,编程部分早就自动化了,或者变成了业务经理友好的自动化DSL或UI。清晰理解问题的开发人员能够更好地理解最终用户,并为解决方案制定更完善的规范和截止日期。他们或许还能为早期的失败和实验留出足够的空间。总的来说,这样的团队将表现得像一个自组织的超有机体。

从无政府状态到无政府主义

最后,无论是 Fred George 还是两位 Martin,都不主张激进的无政府主义,也不主张完全背离 Scrum 和其他敏捷框架(无论是管理还是技术)的经验教训。即使是无政府主义者也应该互相交流和学习。无政府主义团队拥有新兴的领导力和自组织策略,而不是预先设定的领导力或缺乏合适的组织策略。

一个无政府主义团队打造的系统架构会是什么样子?这种无政府主义肯定会渗透到架构本身。或许会出现插件和微服务架构的爆炸式增长,也或许不会。但我确信软件架构本身会受到根本性的影响。什么样的架构能够支持灵活的微架构?最好的那种。或许吧。我们还能称之为架构吗?再次强调,解决方案源于问题定义本身。

我们可以称之为“anarchitecture”

鏂囩珷鏉ユ簮锛�https://dev.to/risavkarna/anarchitecture-4eng
PREV
构建 React 应用程序——我从作为一名 Web 开发人员的经验中学到的东西
NEXT
热情开发者的优先事项