敏捷的十年危机

作者 Philippe Kruchten 译者 高翌翔 发布于 2011年8月1日

领域

过程 & 实践

主题

敏捷联盟 ,

敏捷 ,

认证

分享到

本文是正在InfoQ上发表的“敏捷宣言发布十周年纪念”系列文章之一。

“房间里的大象”是一种隐喻，用于说明人们故意忽视迫在眉睫的问题的行为。他们完全知道存在一些必须处理或决定的重大问题，但是每个人都忙着处理其它一些小问题，忽视大问题，假装大问题根本不存在，希望或许通过魔法让它消失，或是别人将会处理它，也就是有朝一日，大象将会离开房间。

雪鸟村

2011年2月12日Alistair Cockburn在犹他州雪鸟村组织了一次纪念敏捷宣言发布十周年的庆祝活动，此次活动聚集了自十年前那次会议举办以来与社区紧密联系的三十多人。这是一次非常有趣的讨论，不过我在这里并不打算报道此次伟大事件的主要成果或发现。当四周墙壁被数以百计的问题卡片覆盖以后，David Anderson注意到“房间里有一头大象”，这是很少有人愿意在笔头上辩论的话题，那就是敏捷联盟（包括其作用、任务、成就等等）。午饭后，一小群人聚集在一起并确定了房间里其他这样的大象，即一些在敏捷社区中由于各种各样原因确实不愿解决的话题。我们在讨论结束时得出一个长长的列表，其中包括大约二十种此类“未经讨论的”话题（或者至少不能在公开场合进行讨论）。

一群大象

根据我的努力回忆（参见底部照片），下面列出了一群未经修饰的大象，并用附加的一两句话来解释标题的含义：

1. 无法审查商业利益

敏捷社区中的关键人物拥有直接经济利益，因此惧怕任何负面信息被放大、扭曲，并导致遭到反对。

2. 假装敏捷不是生意

参见上面的 1.

3. 无法抑制消极行为

我们没有正视此问题，然后分析失败以及我们所提出的主张、声明、实践的局限性（参见上文）。

4. （各种实践的）情境和情境的适用性

我们没有描述某些实践有效或无效的情境。

5. 情境阻碍教义

只有抛开情境，我们才可以回归到那些教义、偏执以及对于普遍适用性的声明上来。

6. 虚伪

……这是“房间里的大象”问题的根本原因之一（我们实际上都知道）。

7. 政治

更加系统而全面的认识是，组织政治在采用敏捷实践方面扮演着重要角色。

8. 无政府主义

……对于敏捷和精益社区自身而言，它们阻碍了更加系统的知识体系机构的形成。

9. 精英化

……作为一种（抵御失败的）防御手段，我们会尽量限制消息的传播……并且将失败归咎于“无知”的其他人。

10. 敏捷联盟

在对于敏捷联盟所起的作用上存在意见分歧，本应是什么，将来又是什么……

11. 认证（僵尸大象）

好几次人们都报告说这头巨象已死，但似乎它又再次出现……对于评估个人和组织的成熟度，或来自培训师和顾问的商业策略的成熟度而言，认证真的是一种有效的工具么？

12. 将确保产品成功的责任推卸给其他人

特别是，大部分责任似乎被推给了产品所有者、业务分析师、用户等等。

13. 商业价值

人们随时随地都会提到价值的概念，特别是商业价值，但从来没有对其进行过明确的定义，或是与（开发）成本混为一谈，或是推给其他人（例如产品所有者）去解决。

14. 经理和管理都不好

……能否作为将任何失败都推卸给其他人的实例呢？

15. 文化

我们（软件开发者）常常会心照不宣，文化对于我们而言都是相同的，无论是在组织层面还是在国家层面，敏捷运动都没有与文化概念及其微妙的实践互动（这是情境中不可或缺的一部分）完全融为一体。

16. 架构和设计的作用

……根据上下文；它们仍然常常等同于BUFD（Big Up-Front Design，肥大的前期设计），而且由于YAGNI（You ain't gonna need it，你不会需要它）或“我们稍后将重构”的声明，它们很快被置之不理。

17. 自组织团队

或许可以看做是“管理是不好的”公理的一条推论，同样对软件开发管理的概念置之不理。

18. 对于规模缩放的天真（例如，在scrum之中嵌套scrum）

想象一下，假如我们扩大了所有敏捷实践的应用规模，如果某项实践不起作用，那只是因为你没有尽全力去尝试。

19. 技术债务

尽管敏捷实践可以帮助我们控制技术债务，但是它常常也是导致大量技术债务的根本原因。

20. 无需编码就能发现信息的有效途径

在许多软件开发组织中对于最后几头大象（第16至20）的实践存在着很大的差异，而且很少有人对此进行深入分析，特别是关于它们如何与情境联系的问题。

给大象们分组

这是一个十分庞大的象群。几个月以后，我对于敏捷社区房间里那些大象的观点进行了总结如下。

1. 敏捷联盟大象

我先把这个问题放在一边；首先进入位于雪鸟村的房间，对此我没什么可说的。在那天晚些时候，我注意到一位小组前敏捷联盟董事会成员在处理这头大象。或许这仅仅是“社区领导”的一个实例，其中还可能包括其他组织……是否还存在一头scrum联盟大象？

2. 敏捷实践的失败和限制，及其情境

社区擅长把可以工作的实践做得更好，但是通常并不擅长对无法工作的实践进行抑制，并分析它为什么无法工作，或者是在什么状况下无法工作（情境！）。在某些情况下存在一定程度的虚伪（许多相关各方知道这一问题，有些人在私下谈话时愿意承认此问题，但随后……在更开放的场合下，他们会假装此问题不存在，或回归到官方的教条上）。

有几个原因导致了这头大象的出现，而这些原因本身又被视为大象（即“未经讨论的”），我们上面曾经列举过：

1. 商业利益

在敏捷社区中的许多关键人物在销售某种敏捷的工具、咨询、培训、新思想时拥有直接利益，而且任何负面消息都会减少潜在买家，让他们可能会产生恐惧，害怕坏消息都会被过度放大，害怕最终会变成反对他们或反对整个社区的因素。

2. 脱离情境的研究

在大多数情况下，当描述实践时对于实际情境的描述太少，以至于让听众觉得该实践具有非常广泛的适用性，即便描述者并未实际声明这种广泛的适用性。有时候这只是纯粹的教条主义或偏执。

3. 没有基于故障取得进展的明显方式

不同于其他学科，譬如医学，很少有针对软件故障或限制的报告，而且对于此类报告没有明确的立场、甚至没有可参考的模板或样本。此外，人们还担心对于相关人员的报道无论是对于“受害者”还是对于“犯罪者”的组织都会产生恶劣影响。此类报告的好模板应包括对情境的详细描述。

4. 有限的客观证据

除了极少数易于检测的实践（例如结对编程）之外，很少有人为了我们所进行的实践去收集客观的、重要的、科学的证据。某些学术上的当务之急可能加剧了以下观点发表：对于一篇期刊文章或硕士论文而言，针对开发实践进行大量的定性研究并不容易做到。

5. 认知上的偏差和推理上的谬误

例如过度泛化等推理上的谬误（“由于它在两种情况下可以工作，因此它将在所有情况下都可以工作”），以及认知上的偏差导致了：锚定效应、黄金锤、货物邪教等等充斥着敏捷的世界。其他我经常遇到的推理上的谬误包括：不合逻辑的推论，以及倒果为因的谬误（相关性暗示因果关系，或“牵连犯罪”）等等。

两头稍小的大象是精英化和虚伪，它们可能是位于此阴影下的最主要问题，而且我们社区的无政府主义无助于组织出知识体系。

在上面的列表中，那些由于缺乏证据或者是对不同情境中的作用缺乏了解而存在问题的实践同样是一些稍小的大象，它们往往是未经讨论的（除了招摇的修辞与姿态）：

• 全面阐述商业价值的概念，
• 架构和设计的作用，技术债务，
• 自组织的团队，
• 优先考虑编写代码，等等。
3. 政治和文化大象

对这两头大象还需要更多的调查。关于敏捷实践对国家和组织文化的影响的问题上我有一些个人意见，而且在最近的六、七年间已经在全球软件工程社区进行过一些调查。但是我对于政治一无所知，不管是我们社区的内部政治，还是在组织变革时被视为阻碍但可以被我们的社区明确地加以解决的政治。

敏捷少年

敏捷运动在某些方面有点儿像一位少年：非常的自我意识，对着镜子不断地检查其外貌，接受少数批评，只对同龄人感兴趣，排斥来自过去的全部所有智慧，只因为那来自过去，采用时尚和新的行话，有时狂妄而傲慢。但我毫不怀疑它会进一步成熟，对于外界变得更加开放、更加深思熟虑，并因此变得更加有效。我知道我要在以后的雪鸟会议上打算做什么了，那就是找到比这次会议更多的大象。

注：本文最初于2011年2月13日发表在这里。

作者简介

Philippe Kruchten是英属哥伦比亚大学电气工程与计算机科学系的一名软件工程学教授，该校位于加拿大温哥华。他是NSERC（Natural Sciences and Engineering Research Council，加拿大自然科学和工程研究理事会）设计工程学领域的成员之一。在结束长达三十年的工业领域职业生涯之后，他于2004年加入UBC（University of British Columbia，英属哥伦比亚大学），在他的职业生涯中主要工作是参与大型的软件密集型系统的设计，涉及的领域包括：电信、国防、航空航天及运输。他的部分经验体现在Rational统一过程（RUP，Rational Unified Process）中，他从1996年到2003年一直指导RUP的开发工作，直到Rational软件被IBM收购为止。RUP中包括一种被称为“RUP 4+1 视图”的体系结构设计方法。他目前的研究兴趣仍然主要集中在软件架构上，特别是对架构决策及其决策过程，以及敏捷软件工程过程。他是IFIP WG2.10软件架构的创始人之一。Kruchten在里昂中央理工学院获得了机械工程学毕业证书，并在国立巴黎高等电信学院获得了博士学位。他分别是IEEE（Institute of Electrical and Electronics Engineers，美国电气和电子工程师协会）、ACM（Association of Computing Machinery，美国计算机学会）、AIS（Association for Information Systems，信息系统协会）的成员，还是英属哥伦比亚省的一名专业工程师。

查看英文原文：Agile's Teenage Crisis?

感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

1. 返回顶部

   这翻译

   发表人 Cai John

   英文不过关啊。

   回复