欢迎大家来到IT世界,在知识的湖畔探索吧!
不知您是否也曾听闻类似的感慨，且先听我一一道来。
欢迎大家来到IT世界,在知识的湖畔探索吧!
当下，软件开发周期正不断拉长，技术团队的规模愈发庞大，管理开发工作所需的应用程序日益增多，真正投身编码的人员占比却越来越少，交付时间愈发紧迫，而各检查节点之间所取得的实质性进展反倒愈发寥寥。此时，一个问题不禁涌上心头：究竟从何时起，敏捷开发不再是开发特定软件的可选良策，反倒突兀地演变成了一场席卷整个组织的 “宗教式” 狂热？如今，我们似乎都沦为了 “Jira 崇拜” 的信徒，可这一切究竟是如何发生的？又该如何挣脱这一桎梏呢？究竟是敏捷开发的哪一环节出了差错？
为了快速阐释敏捷开发的要义，我打算直接引用维基百科的内容，毕竟它足以满足当下所需。简而言之，对于尚未投身这一 “崇拜” 的人而言，敏捷开发是 21 世纪初应运而生的一种方法，旨在取代那种以文档驱动、流程繁琐的重量级软件开发模式。没错，敏捷本应是对那些逐渐沦为 PMP（项目管理专业人士资格认证）甚至六西格玛之类 “赚钱机器” 的传统项目管理方法的革新之举。然而，现实究竟怎样呢？
我不敢妄言能代表所有人，毕竟我个人在敏捷开发领域的专业实践一直处于边缘地带。我知晓它的存在，认可它的价值，也努力让它发挥效用，同时避免它引发混乱，就如同每个技术团队角落里总会有那么一位极具潜力却需悉心引导的开发者。巧合的是，我的经历恰好与敏捷开发的式微阶段重合。
回顾在 Automated Insights 的那段时光，大致从 2010 年至 2017 年，我从未为敏捷开发的事儿操过心。实不相瞒，即便冒着自夸的风险，也要说那时我们早在生成式人工智能、甚至自然语言生成概念大热之前，就已经涉足相关领域，发展速度之快，连敏捷开发都有些望尘莫及。诚然，若从方法论角度考量，我们或许能从中受益，但平心而论，由于缺乏系统方法论，当时我们在高速发展的同时也犯下诸多不必要的错误。
再看在 Spiffy 的经历，大约从 2017 年到 2022 年，我与公司的 CEO 和 CTO 都旗帜鲜明地抵制各类敏捷开发形式。不过在实际操作中，我们采用了持续开发、持续改进、持续部署等理念，只是并未遵循正式采用敏捷开发所必需的那些强制周期、检查点以及自我反思环节。
到了 2023 年在 Growers 时，我踏入的是一个因过度依赖敏捷开发及其衍生形式而陷入僵局的组织。这里所说的困境并非仅局限于产品和工程部门，整个公司都在为应用程序与平台组合的发布速度、交付质量苦苦挣扎。虽说公司上下不乏好点子、优秀人才以及十足干劲，可过程却异常艰辛。这个难题耗费了大半年时间才得以解决，即便此刻撰写此文，我仍在努力收尾，但好在已经跨越了主要障碍，因而也能总结些许经验教训。
追根溯源，关键问题在于技术膨胀。
我时常接触的诸多人士，涵盖初创企业与财富 500 强企业的业务及技术高层管理者，他们已然或即将摒弃敏捷开发，而背后的主因正是技术膨胀。技术膨胀堪称每家科技公司的劲敌，即便对于那些未被严格定义为科技公司，却设有内部或外包软件开发部门的企业而言，同样是一大隐患。需要明确的是，技术膨胀并非技术债务，技术债务指的是开发过程中的种种不规范，致使问题日积月累，后续逐渐显现，不过技术膨胀必然会催生技术债务。
技术膨胀通常伴有如下症状：频繁与客户沟通交流，却始终无法成为洞悉客户行为的行家；反复评估、重新敲定截止日期与交付日期；在详尽记录所有细节之前，极度抵触启动开发流程；总是倾向于从最简单的任务入手，而非优先处理最棘手的难题。
技术膨胀引发的混乱局面在组织中有如下表现，这是我屡次见证、反复上演的恶性循环，或许您也曾目睹，甚至亲身经历。
其一，流程中逐渐涌入海量文档，不仅用于追踪开发内容与缘由，还详尽记录开发过程，而这一 “如何开发” 竟成了状态更新的核心关注点，团队不断复盘工作方式，结果往往是众人纠结于事情为何未完成，实际耗时远超预期。
其二，更为频繁的检查点催生出更多截止日期，最终导致在软件开发这一本应充满创造性的过程中，每个关键节点都陷入微观管理的泥沼。这与打造高质量软件的初衷背道而驰，毕竟每项任务都得在预设截止日期前交付，至于执行质量反倒无暇顾及。
其三，重新评估阶段频繁的事后诸葛，使得最佳实践难以确立，资源浪费无法杜绝，规模效益难以实现。
其四，对生产过程的微观管理，意味着当整体功能仅完成 30% 左右时，便不再被视作优先事项。随后，无论原定路线图是否契合打造成功产品的需求，组织都会依葫芦画瓢推进生产，自此陷入恶性循环。
最终结局便是产品在众多不同客户需求的拉扯下不堪重负。功能常常无法顺利推向市场，且交付方式与顺序往往更贴合技术团队偏好，而非市场需求。长此以往，销售与营销部门奋起反抗，只因他们都摸不清自家产品究竟为何物，客户更是一头雾水。紧接着，组织便不得不大刀阔斧进行整顿。
这是否就是近期科技行业裁员潮的根源呢？当然，这并非唯一诱因。
事实上，当下世界所需并非更多繁杂功能，而是更精简高效的软件，以便出色完成关键任务。这并非全新理念，却也是各类方法在实践中屡屡偏离的方向，从准时生产，乃至丰田生产方式中那些稍纵即逝的精髓，概莫能外。到头来，人们开始质疑丰田方式是否足够 “丰田”，进而使其沦为为做而做的形式主义。
事已至此，敏捷开发如今已然变得与 PMP 无异，不过是顶着个俏皮名字，会议稍短，规则却愈发繁杂。
所以说，问题的症结从来都不在敏捷开发的理念本身，而在于执行环节以及管控乏力的领导力。这是中层管理者一味紧盯截止日期，忽视实用性；着眼削减成本，而非谋求增长；力求节约资源，却阻碍了进步。
说实话，如今想要挽救敏捷开发，或许为时已晚。您大可将其弃如敝履，甚至 EOS（Entrepreneurial Operating System，创业操作系统）也不妨一并丢进垃圾桶。后续我会在专栏中深入探讨相关话题，若您感兴趣，不妨加入我的电子邮件列表，以便第一时间获取最新消息。
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://itzsg.com/103988.html
