【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

采用敏捷需要面面俱到

  • 2009-02-08
  • 本文字数:1748 字

    阅读完需:约 6 分钟

两个月以前, InfoQ 曾报道过Jim Shore 的那篇广受欢迎的文章《 The Decline and Fall of Agile 》,该文指出在日益增长的敏捷社区中有这样一种倾向,组织只是在名义上采用“敏捷”,而没有采用如何真正成为敏捷的实践。InfoQ 和 Jim 博客中的这篇文章,都引来了无数的评论,如果你还没读过则很值得一读。

但是事情还在继续。敏捷社区领导人比如 Martin Fowler Joshua Kerievsky Ron Jeffries 以及其他人在 Shore 的基础上更进一步,纷纷就这一情况发表了自己的看法。

在 _ Flaccid Scrum _ 一 文中,Martin Fowler 重复了 Shore 大部分的观点:许多敏捷实施缺少了极限编程中强调的技术实践,比如结对编程、持续集成、测试驱动开发。和 Shore 一 样,Fowler 也承认组织实施敏捷时普遍会优先选择 Scrum,但即使这样,这也不是 Scrum 本身的错。作为补救措施和对大家的提醒,他强调说那些领 导实施 Scrum 的人需要特别留心,要找机会推动合适的技术实践:

Scrum 社区需要加倍努力,确保大家理解技术实践的重要性。无论何种类型的项目评审,都要检查项目中使用了哪些技术实践。如果你在参与或者接触这样的项目,当技术实践被弃之不管时一定要跳出来。

Fowler 发表此文后不久, Industrial Logic IXP 的创建者 Joshua Kerievsky 就在 Yahoo 极限编程讨论小组中提出这个话题。在他的初帖 the Whole Enchilada 中,Kerievsky 再次提起一个问题,他曾在 2006 年敏捷大会上提出这个问题并引发热论,问题的主要内容是“做就全做,并且从一开始就全做。”

Scrum 毫无生气?敏捷逐渐衰落?
越来越多的证据表明,组织和开发社区需要面面俱到──管理的和技术的敏捷实践,二者缺一不可。 以我之愚见,“他们会逐渐采用技术实践”这种想法极其幼稚。大多数情况下,他们根本就不会采用技术实践,即使采用也是少之又少,就好像根本没采用一样。

拿来即用的 Scrum 对技术实践毫无提及,就像卖的轿车没有安全带以及其它关键的安全措施。如果有人愿意告诉你技术实践也是必须的(虽然他们深信“后期逐渐采用技术实践”这一想法),你还算走运,总算知道了什么是正确的 Scrum。

极限编程(像本讨论组内众所周知,不仅仅是技术实践)、Scrum+ 极限编程、工业极限编程等等,都是面面俱到的例子。

我们一次又一次地发现,一开始就面面俱到的组织和开发社区要好得多,因为随后他们就会发现自己的敏捷流程缺少了多少东西。

所以我们需要承认好的流程依赖一些关键因素,而技术实践就是软件开发中最关键的因素。把它推迟到敏捷后期实施绝对是一个坏主意。

Kerievsky 的帖子引发了激烈的辩论,有大约 90 篇回帖讨论了 Joshua 建议的价值和适用性,为什么要面面俱到的各种可能原因,以及是否真的有许多组织这么做了。此帖请务必一读。

在 _ Context, My Foot! _ 文章中,Ron Jeffries 同意 Shore、Fowler 和 Kerievsky 的观点,认为多数敏捷实施失败的本质原因是没有采用那些必需的实践:

要想成功,你得先做正确的事情,然后把事情做好。

为了正确实施 Scrum、极限编程、或者任何形式的敏捷,你必须重构。很抱歉,这不是可选的,而是必须的。

极限编程以及其它地方列出了更多的实践,它们都像重构一样重要。所以要想成功,你毫无选择,必须去实施这些实践。

在重复了“要面面俱到”的观点之后,后面才是 Jeffries 这篇文章的真正亮点所在。他解释了什么才是组织实施敏捷失败的真正原因:组织本身。直接针对刻意回避真相的事实,Jeffries 说道:

极限编程 / 敏捷 /Scrum 越来越流行,许多团队和个人都想这么做,或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”,“不适合我们的环境”。所以我们不得不修改敏捷实践,因为上帝也知道我们没法修改环境。 亲 爱的朋友们,真为你们感到难过。恰恰是你宝贵的环境拖累了你:是中央级别的执行官和高管们不能把职责和权利交给大家;是产品的人总是太忙,以致不能解释真 正要做什么;是管理设施的人不能创建适合工作的环境;是程序员不愿意学习必须的技术;是经理和产品负责人不断施压,直到对项目的质量没有任何关注。

所以这个讨论值得花很大精力关注——敏捷已经到了关键时候。专家们仍在继续讨论这一话题,你也应该一起讨论,其实我们都得讨论。不如就在这里讨论吧。

查看英文原文 Adopting The Whole Enchilada

2009-02-08 07:071744
用户头像

发布了 37 篇内容, 共 10.9 次阅读, 收获喜欢 5 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营 1 期 -- 第五周作业

曾彪彪

极客大学架构师训练营

攻克金融系统开发难点,借助SpreadJS实现在线导入Excel自定义报表

葡萄城技术团队

SpreadJS 在线导入excel

Microsoft Azure机器学习采用NVIDIA AI为Word编辑器提供语法建议

吃透阿里大佬整理的Java面试要点手册,成功五面进阿里(二本学历)

Java架构追梦

Java 学习 架构 面试 核心知识点整理

ArCall功能介绍手册

anyRTC开发者

ios 音视频 WebRTC RTC 安卓

数据湖探索DLI新功能:基于openLooKeng的交互式分析

华为云开发者联盟

数据 处理

架构训练营第一周学习小结

李日盛

架构必修:领域边界划分方法--职责驱动设计(RDD)

马迪奥

架构 领域 架构师 RDD

学了那么多 NoSQL 数据库 NoSQL 究竟是啥

哈喽沃德先生

数据库 nosql 非关系型数据库

spring-boot-route(二十二)实现邮件发送功能

Java旅途

Java Spring Boot 发送邮件

千万不要往 Shell 里粘贴命令!

大道至简

命令行

DDIA 读书笔记(2)数据模型的存储与检索

莫黎

读书笔记

GitLab用户切换引发的某程序员“暴动”,怒而开源项目源码

小Q

Java git 学习 开发 代码仓库

数据结构与算法系列之链表操作全集(一)(GO)

书旅

数据结构 数据结构和算法 Go 语言

机器学习是什么?

马同学

学习

LeetCode题解:98. 验证二叉搜索树,递归中序遍历过程中判断,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

iOS性能优化 — 一、crash监控及防崩溃处理

iOSer

性能优化 ios开发 Crash 监控及防崩溃处理

趣味科普丨一文读懂云服务器的那些事儿

华为云开发者联盟

镜像 服务器 服务

vivo 商城前端架构升级—前后端分离篇

vivo互联网技术

Java 大前端 前后端分离

架构师训练营第五周学习总结

尹斌

学习总结

饺子

全面到哭!BAT内部Java求职面试宝典,必须人手一份!

Java架构之路

Java 程序员 架构 面试 编程语言

AI让远程交流“更清晰”:GAN消除视频通话中的抖动

JavaScript 类型 — 重学 JavaScript

三钻

Java 大前端

架构师训练营第一周课后作业

李日盛

typora增强-mac

老菜鸟

Typora

解析 CloudQuery 审计分析功能

BinTools图尔兹

数据库 sql 安全 工具软件

mPaaS x Menxlab | 1024程序员节:Talk is cheap,Show me the AppID

蚂蚁集团移动开发平台 mPaaS

程序员 开发者 mPaaS 1024

自动化测试框架类型,你知道几种?此处介绍5种比较常见的

软测小生

软件测试 自动化测试框架 软件自动化测试

1分钟带你get React setState 面试要点

Leo

面试 大前端 React setState

面试官的灵魂一击:你懂 MySQL 事务日志吗?

Java架构师迁哥

采用敏捷需要面面俱到_研发效能_Mike Bria_InfoQ精选文章