敏捷与软件的长期危机 - logicmag

首先什么是敏捷？它来自哪里？

我第一次遇到敏捷是在图书馆的工作中。我被雇来帮助一个新的数字学术中心落地，有时与图书馆的软件开发团队合作，建立工具来支持我们的项目。这个团队大约有六名成员，我马上注意到他们做事的方式与非技术人员不同。在会议上，他们不谈产品功能，而是谈 "用户故事"--描述功能的微小叙述--他们给这些故事分配 "故事点"，以衡量完成相关任务的努力程度。他们每天早上都要举行 "站立 "会议，这个会议实际上是站着进行的，这样可以使会议更加简洁。白板在他们的工作区占据了重要的位置，我看着开发人员在白板上移动便利贴，以表示他们的完成情况。他们以 "冲刺 "的方式工作，为期两周的时间专门用于特定的任务。

在与我们图书馆其他员工的会议上，开发团队的负责人用软件报告进展情况，其中包括一个显示每个项目状态的仪表盘。经理还可以向我们展示团队的 "速度 "图，即开发人员完成任务的速度，并附有历史比较和预测结果。

我了解到，这是一种管理软件开发的方法，在各种技术工作场所获得了极大的欢迎，而且，越来越多的人甚至在非技术工作场所（包括，正如一位TED演讲者所说的那样，在家庭中）也是如此。说实话，我被打动了。在我自己的工作中，我经常觉得自己好像是在瞎折腾，从不确定自己是否在取得进展或做任何真正有价值的事情。相比之下，开发人员似乎很清楚他们在做什么。如果他们遇到路障，那也没什么大不了的；他们只是在处理它。他们预计需求会随着他们的进展而改变，而两周的时间跨度允许他们用一个功能替代另一个功能，或者采用一个新的框架，而不需要从头开始。

这就是敏捷的魅力：为最终的灵活性和速度而设计，它要求开发人员将每项任务分解成尽可能小的单元。重点是快速发布，经常进行评估，必要时改变方向。

我很感兴趣；敏捷与我之前经历的任何事情都不同。它是从哪里来的，为什么？

我开始探索敏捷的历史。我发现，在管理者希望的软件开发和编写代码的工人所实践的软件开发之间，存在着一场长期的角力赛。一次又一次，组织试图通过引入新的管理方式来控制软件最麻烦的倾向--它习惯于超越时间线和可衡量的目标。有一段时间，公司似乎已经在敏捷中找到了让开发人员愉快地完成任务的解决方案，同时也在以疯狂的速度工作。但最近，一些迹象表明，敏捷的力量可能正在消退。

一个新的清算时刻正在形成，它可能最终将敏捷从它的宝座上击落。

把怪人变成工程师
甚至在 "软件 "这个词被创造出来之前，软件开发就处于危机之中。1954年，在底特律的韦恩州立大学召开的一次由工业界、政府和学术界领导人参加的会议上，专家们警告说，训练有素的程序员即将出现短缺。四年后，"软件 "一词首次出现在统计学家John W. Tukey的文章中，指的是应用编程。到20世纪60年代中期，美国至少有10万人从事程序员工作，但评论家们估计立即会有5万多人的需求。

在编程职业的最初几十年里，大多数专家认为制定计算机可读的指令是一项相对微不足道的工作。毕竟，系统分析员--指定高级架构的专家--已经完成了设计程序和硬件的艰苦智力工作。编码员的工作只是将设计转化为计算机可以使用的东西。因此，当人们发现这个翻译过程实际上对智力要求很高时，就会感到很惊讶。

这些智力要求的性质，以及软件开发究竟是什么样的工作这一更大的问题，今天仍然令管理人员感到困惑。在计算机的早期，对一些人来说，编码似乎是，或应该是，一个纯粹的逻辑问题；毕竟，机器只是做你告诉他们做的事。不言而喻，有一种形式上正确的方法来做事情，而编码者的工作只是找到它。

然而，编程的实际经验表明，编码既是艺术也是科学。正如克莱夫-汤普森（Clive Thompson）在其2019年出版的《编码者》（Coders）一书中指出的那样，一些最先进的编程是由下班后在大学实验室闲逛的长发怪人推动的，这些黑客认为自己既是工匠又是逻辑学家。人们无法实际接触软件--也许是其存储介质，但不是软件本身--这一事实使得软件开发比其他工程领域更抽象、更神秘。其他领域可以被期望遵守物理定律，而软件脚下的土地似乎在不断变化。硬件永远在改变其参数和能力。

然而，电子数据处理领域--办公功能的自动化，如时间卡和工资单--正在迅速增长。从IBM租来的为此目的而设计的庞大机器，迅速成为技术上具有前瞻性的运作的标志。但它们需要一组操作人员来设计程序，准备打卡，并将数据输入系统。既定的经理们对越来越多的 "计算机男孩 "队伍的专业知识和职业怪癖感到不满。他们也反感软件项目似乎违背了对成本和复杂性的任何估计。著名的计算机科学家弗雷德里克-布鲁克斯（Frederick Brooks）将软件项目比作狼人：它们开始时像小狗一样天真无邪，但更多的时候，它们会蜕变成 "一个由错过的时间表、被破坏的预算和有缺陷的产品组成的怪物。" 那么，你可以说，到了60年代末，软件开发正面临着三个危机：对更多程序员的迫切需求；将开发变成更可预测的东西的迫切需要；以及，正如企业所看到的，管理上的需要，让开发人员不再表现得如此古怪。

正是在这种职业化的精神下，行业领导者鼓励程序员接受 "软件工程师 "的称号，许多历史学家将这一发展追溯到1968年的北约软件工程会议。组织者指出，计算机工作范围广，难以组织，而且出了名的难以管理。那么，为什么不从工程的既定领域借用一套方法（和一个标题）呢？这样一来，编程就可以坚定地成为一门科学，拥有所有的秩序、影响力和随之而来的既定方法论。组织者希望，这也会使工业界更容易管理：软件工程师可能会更好地顺应企业文化，遵循其他学科工程师的模式。"历史学家Nathan Ensmenger写道："为了高效的软件制造，编程的黑色艺术必须为软件工程的科学让路"。

追逐瀑布方法
而且，它还起了作用--某种程度上。软件工程 "的称谓开始流行起来，与写软件的人的机构威望一起上升。大学院系采用了这一术语，鼓励学生在学习编程的过程中实践合理的工程方法，如使用数学证明。计算机科学家Tony Hoare称，这些技术将 "改变计算机编程的神秘和容易出错的工艺，以满足工程专业的最高标准"。

经理们兴致勃勃地处理组织新的智能软件劳动力的任务，导致了许多不同的组织方法。其中一种方法是在IBM建立的首席程序员团队（CPT）框架，把一个 "首席程序员 "放在等级制度的首位，监督一批专家的互动。另一种流行的方法是将程序员置于多层管理员之下，由管理员做出决定并将工作分配给他们手下的程序员。

随着这些新技术的出现，出现了一套管理开发工作的理念，这种管理理念被称为（主要是贬义的）"瀑布法"。瀑布法在理论上是有道理的：有人为软件产品设定了一个目标，并将其生产分成一系列的步骤，每一个步骤在进入下一个任务之前都必须完成和测试。换句话说，开发人员遵循管理层为他们制定的脚本。

具有讽刺意味的是，"瀑布 "这个词第一次出现在一篇指责这种方法不现实的文章中，但这个名字和理念还是流行了起来。瀑布法不可抗拒地与管理它的企业层次结构相匹配。它吸引了管理人员，因为正如Nathan Ensmenger所写的，"软件工程运动的本质是控制：对复杂性的控制，对预算和时间安排的控制，以及，也许最重要的，对顽固的劳动力的控制。这正是瀑布式开发所要适应的专业人员。

但不久之后，软件开发又陷入了危机--或者说危机。问题的一部分是要跟上对新的计算机科学家的需求。1980年的大学无法填补必要的教职，以培训大量有志于成为软件工程师的学生。"计算机械协会警告说："这种情况严重威胁到计算机科学系继续培养我们的信息处理行业和日益增长的技术社会所需要的技术人才的能力。

该行业缺乏合格的开发人员并不是它唯一的问题。软件开发本身似乎也在挣扎。瀑布法对严格控制管理的承诺是一个幻影。无论多少文件、过程或程序，似乎都无法使开发变得可预测。软件项目规模大，成本高，而且似乎失去了控制--由于需求的变化和项目组之间对细节的争吵，巨大的计划没有完成。尽管经理们努力使软件开发变得可靠和可预测，但如果有的话，它似乎只是变得更加笨重。正如计算机科学家Jeff Offutt所说，"在20世纪60年代，程序员建造了'小木屋'，"而 "在20世纪80年代，程序员团队正在建造办公大楼"，到了20世纪90年代，则是摩天大楼。然而，技术专家团队似乎无法协调他们的工作。技术行业顾问彼得-瓦霍尔（Peter Varhol）估计，在20世纪90年代初，从创意到成品，应用程序的开发平均需要三年时间。技术本应使美国企业更聪明、更快速、更有利可图，但最受尊敬的公司似乎无法让他们的项目落地。

"工程师 "的称号，行政等级制度，仔细的计划和文件：所有这些都是为了给新兴的软件开发领域带来秩序和控制。但这似乎适得其反。瀑布法非但没有为软件开发者扫清道路，反而用成堆的文件和无休止的会议堵塞了工作。

就他们而言，工程师们抱怨说，他们感到被强硬的管理技术所限制。他们只想开发软件。为什么他们会被文书工作所束缚？20世纪90年代企业编程的典型形象是道格拉斯-库普兰（Douglas Coupland）的小说《微观世界》（Microserfs）中那些存在感极强的20多岁的年轻人，或者迈克-贾奇（Mike Judge）的电影《办公空间》（Office Space）中那些绝望的开发者，他们的愤怒就潜伏在表面之下。

敏捷宣言：卡其裤和爸爸牛仔裤
这可能是世界上最不可能的一群摇滚明星：17个中年白人，穿着卡其裤和爸爸牛仔裤，都对管理很着迷。2001年2月，被称为 "敏捷宣言 "的这些现在具有传奇色彩的作者们聚集在犹他州的雪鸟滑雪场，为软件开发过程制定新的愿景。这并不是他们的第一次会议；他们以不同的形式聚集在一起讨论软件开发已经有一段时间了，尽管在2001年的会议之前，他们还没有拿出什么东西来。这一次则不同。白板上写着《敏捷宣言》，这是一套价值观，在接下来的几年里，从刚起步的初创公司到庞大的公司，这套价值观在程序员的管理中几乎无处不在。它简明扼要，令人愉快。

我们正在通过实践和帮助他人来发现更好的软件开发方式。

通过这项工作，我们已经开始重视。

• 个人和互动胜过流程和工具
• 工作中的软件胜过全面的文件
• 客户合作胜过合同谈判
• 应对变化而不是遵循计划

上述四条中分左右对比，也就是说，虽然右边的项目有价值，但我们更重视左边的项目。

宣言中补充了十二条原则，针对的是工程师所描述的职业挫折。瀑布理论认为，软件应用的需求是稳定的，减速和堵塞是偏离管理层的精心计划的结果。敏捷抛开了这些高层次的路线图，而是强调需要在飞行中做出决定。这样一来，软件开发者自己就可以随着需求或技术的变化而改变他们的方法。他们可以专注于构建软件，而不是文书工作和文件。他们可以消除对无休止会议的需求。

这是一份有趣的文件。鉴于合格的开发人员的短缺，技术专业人员可能会要求更直接的物质利益的让步，例如，工会，或对他们的知识产权的所有权。相反，他们要求的是一种能够让他们做得更好、更有效率的工作的工作场所配置。
事实上，正如作家Michael Eby所指出的，这种对管理层的反抗与之前的一些工作场所不满的表达方式不同：科技工人不是要求物质上的改善，而是创造了 "一种新的'精神'，基于文化、原则、假设、等级制度和道德，吸收了艺术批评的抱怨。" 也就是说，该宣言直接攻击了开发者所痛恨的官僚主义、幼稚化和虚无感。开发人员并没有要求更好的报酬；他们要求被当作不同的人对待。

组织无政府主义者
关于软件开发性质的意见变化似乎并不完全发生在2001年，而是发生在《敏捷宣言》发表之前的十年间。越来越多的人--包括开发者和管理者--达成了共识，即软件开发不可能符合分析家们寄予厚望的流程图和工作表的要求。正如历史学家Stuart Shapiro在1997年所写的那样，软件以一种特别复杂的方式存在：问题是 "模糊的、可变的和多方面的，因此很少被证明适合任何一种方法；相反，它们需要混合和适应性的解决方案。那么，不是表格和时间卡。此外，随着20世纪90年代程序员队伍的飞速增长，公司不得不雇用没有经过正式计算机科学培训的人。这些年轻的工人很可能对20世纪70年代和80年代将软件开发变成一门科学的努力投入较少。宣言并不是真正的横空出世：它更像是一个标点符号，强调了多年来对企业管理的主流模式的不满。

然而，虽然敏捷有一批忠实的追随者，但它的任务--取消自上而下的计划和行政等级制度--是一种风险。这意味着管理层将控制权，至少在某种程度上，让给开发人员自己。而大多数大公司并不愿意这样做，至少在2010年代之前是这样。不过，根据敏捷咨询公司Planview的数据，在2012年至2015年期间，有超过50%的实践开发团队将自己定性为 "敏捷"。

毫无疑问，这种流行与高速互联网连接的增长有关，它极大地改变了软件的发布方式。以前，软件每年更新一次，甚至更长的时间间隔也不稀奇。更新必须通过CD-ROM和软盘等物理媒介来发布，这限制了新版本的速度。但是，高速互联网使得公司可以按照自己的意愿频繁地推送修复和功能，甚至一天多次。敏捷在这种环境下有很大的意义。

Facebook著名的座右铭："快速行动，打破常规"，很好地诠释了新时代的精神。这是一个奖励大胆的时代，在软件开发和CEO中都是如此。风险投资公司为了寻找 "独角兽"，在2010年代向技术领域投入了创纪录的资金，他们希望迅速看到结果。要与初创企业竞争，就必须具备瞬息万变的能力，不断发布，并以极快的速度发展。风险的计算发生了变化：现在看来，坚持瀑布式开发是很危险的，因为敏捷承诺了这么多的速度。

同样的，作为一个软件开发者的意义似乎也发生了变化。在20世纪70年代和80年代，专家们把具有系统意识、热爱逻辑的科学家作为理想的软件工作者。但多年来，这一理想未能扎根。1990年代的程序员阅读的是《连线》，而不是《Datamation》。如果他们的特点可以从《敏捷宣言》中推断出来的话，他们坚定地致力于最高标准，快速而自信地工作，因为管理者 "相信他们能完成工作"。他们拒绝仅仅因为事情一直是这样做的而去做，将他们的思想转向 "持续关注技术的卓越性"。他们没有被多变的、快速变化的要求所吓倒；相反，他们把这些要求作为一个机会来接受，"为客户的竞争优势驾驭变化"。

自由思考的不循规蹈矩者的形象符合敏捷的理念。宣言的作者可能看起来像教科书上的工程师，穿着扣子衬衫，带着手机皮套，但据他们中的吉姆-海史密斯说，"很难找到更大的组织无政府主义者群体"。特别是在早期，有很多关于敏捷对传统管理范式的挑战的讨论。敏捷的拥护者们为这种不合规性感到自豪：该框架 "让传统主义者感到恐惧"，Highsmith在2001年写道。"敏捷在一开始就公开地、激进地反对管理，"软件开发者和顾问Al Tenhundfeld写道。"例如，Ken Schwaber[宣言作者]曾大声疾呼，明确表示他的目标是摆脱所有的项目经理"。

反管理，也许，但不是反企业，不是真的。
我们很想把典型的敏捷开发者看作是60年代末潜伏在打卡机周围的长发反文化怪人的复兴。
但这两个角色在重要方面有所不同。
计算机早期的怪人想为把这种新技术用于工作的纯粹快感而编程。
Agile敏捷想象中的编码者首先是致力于项目、讨厌行政干预，因为这妨碍了他最大的愿望，那就是在最高水平上完成他的工作。

就像亚伦-索尔金（Aaron Sorkin）的《社交网络》（The Social Network）中的开发者一样，他最希望的是进入 "状态"：戴上耳机，排除杂念，与他的工作处于一种纯粹的交流状态。

管理层的报复
在图书馆工作时，我一直关注着开发人员，钦佩他们的团队精神和务实精神。不过，随着时间的推移，我不禁注意到团队的表面出现了一些裂痕。尽管有速度表和严格的功能跟踪，但开发人员似乎并没有取得多大的进展。他们都在努力工作，这是显而易见的，但有一个致命的缺陷：没有人真正知道这个项目最终应该是什么样子的，或者它到底应该有什么作用。团队成员可以开发功能，但不清楚所有这些功能被附加到什么上面。也许这个问题来自于我的工作场所本身的功能障碍，这是很重要的。不过，我开始怀疑敏捷方法论是否有一些局限性。

事实上，任何接近软件开发的人都有可能听说过关于敏捷的传闻。尽管宣言有很多承诺，但在与从事技术工作的人交谈时，人们开始感觉到，在敏捷下工作可能并不是它所宣称的那种解放的体验。的确，软件开发再次陷入危机--但这次是敏捷的危机。在网络上，从普通的开发者到一些原始的宣言作者都在对敏捷实践提出担忧。他们谈论的是 "敏捷工业综合体"，即那些收取高额费用来调整敏捷流程的顾问、演讲者和教练的网络。几乎每个人都在抱怨敏捷走错了方向：在过去的20年里，敏捷已经偏离了最初的宣言愿景，变成了比它本意更严格、更费力、更紧张的东西。

问题的一部分是敏捷的灵活性。自由开发者Jan Wischweh称这为 "没有真正的苏格兰人 "问题。任何有人不喜欢的敏捷实践，都不可避免地被证明不是敏捷的。宣言的构造使这一点几乎不可避免：因为宣言没有规定任何具体的活动，人们必须衡量到位的方法的精神，这完全取决于体验者。因为它坚持认为自己是一种 "思维方式"，而不是一种方法论，所以敏捷似乎注定要具有任何采用它的组织的一些特征。而且它对批评有明显的免疫力，因为它不能被简化为一套特定的方法。"如果你做错了一件事，而且它对你不起作用，人们会认为这是因为你做错了，"一位产品经理告诉我。"而不是因为这个框架有什么问题。"

尽管它的定义有这种灵活性，但许多开发人员对敏捷的理念失去了信心。Wischweh本人在向一位律师阿姨描述一个阶段性会议时遇到了一个转折点。她感到难以置信。一个有能力的专业人员每天都需要以微小的单位来证明自己的工作，这个概念对她来说是荒谬的。Wischweh开始思考敏捷鼓励开发人员将自己视为机器中的齿轮的方式。他们可能不会像瀑布模式中那样被埋没在层层管理之下，但他们还是将企业的优先事项内化为自己的优先事项。"作为开发人员和IT专业人士，我们喜欢把自己当作知识工作者，他们的工作不能被合理化或商品化。但我认为敏捷试图完成完全相反的方法，"Wischweh说。

宣言的作者之一Al Tenhundfeld指出，他的同伴们都是在职的开发人员，而且宣言最初是在自我组织的编码员团队中被接受的。然而，现在有很多人专门帮助实施敏捷，而敏捷会议众所周知地倾向于由管理者而非开发者主导。敏捷的普遍性意味着它很可能是由上面强加的，而不是由下面要求的。敏捷项目经理，通常作为 "产品所有者 "被嵌入到团队中，他们发现自己被拉向两个方向：一方面是对开发者最好的，另一方面是他们向管理层承诺交付的东西。

即使团队被拉向多个方向，它也被要求以不断加快的速度推进项目。毕竟，"冲刺 "的定义是快速。事实上，对我所接触的许多科技工作者来说，职业倦怠的前景十分明显。"技术作家萨拉-莫尔（Sarah Moir）说："你试图在这段时间内定义什么是合理的。"然后跑到终点线，再做一次。然后再跑到那个终点线，一直跑下去。如果你投入百分之百的能力，这可能是一种疲惫。"

此外，被称为轻量级的、低调的检查的日常会议，对一些工人来说，已经成为监视的练习。特别是当工作被分解成小部分时，工人感到有义务列举他们所完成的每一项任务。每个工人都有压力来证明他们的价值；他们毕竟是雇员，需要被认为是赚取他们的工资。

"故事点"--团队用来衡量特定开发任务中所涉及的努力的抽象概念--也失去了一些诱惑力。他们开始是为了让工程师对其工作的数量和内容进行一些控制。然而，在实践中，它们经常被用作评估工程师业绩的一种方式。"西雅图的软件工程师Yvonne Lam说："一旦你把一些东西放在数字工具中，人们想要的监督量就会增加，对吗？

问题不仅仅在于监督，还在于积分计算成时间轴的方式。一家平台公司的工程师约翰-伯恩斯(John Burns)回忆说，以前的工作场所只是将故事点乘以一个共同的系数，以便粗略估计一个项目将需要多长时间。尽管故事点的公开地位是一种非正式的、内部的衡量标准，但经理们还是将其作为一种规划工具。

下一个危机
这些抱怨的背后是对敏捷所承诺的自由的更深层次的怀疑。敏捷的价值观赞美开发者的独创性和特立独行的工作方式。但是，工人们觉得在敏捷中行使的创造力有明显的限制，特别是因为问题往往被分解成如此小的碎片。很明显，"敏捷 "消除了许多更明显的等级管理控制的特征，"迈克尔-埃比写道。"但它这样做只是为了以微妙和细微的方式重新保持它们。" Yvonne Lam指出，敏捷下的自主权有明显的参数。"人们说你有自主权来决定你要怎么做工作。这就像，是的，但有时你想要的是自主权，说这是错误的工作"。在任何软件开发项目的过程中都有许多选择--关于语言、框架、结构--以至于有可能忽视这样一个事实，即开发人员往往没有机会对更大的问题进行权衡。

而且，在过去的几年里，这些更大的问题已经变得更加重要和紧迫。
我们已经看到了许多科技工作者组织起来改变其公司业务战略方向的例子：

• 谷歌的开发者们鼓动他们终止与国防部的人工智能合同，
• 游戏开发者们鼓动他们结束性骚扰。

同样值得考虑的是，在创造一种对女性、有色人种和性别少数群体成员越来越显示出毒性的工作文化方面，Agile可能起到了作用。一个不可回避的事实是，《敏捷宣言》的作者是一群非常特殊的人：白人男子，无论他们有什么不同的经历，可能都没有在他们占少数的工作场所呆过很长时间。工作小组后来承认了团队多样性的不足，并发誓要在与宣言相关的非营利组织--敏捷联盟中纳入更多的声音。

但是，当你调查与敏捷相关的方法论清单时，如果你是那种在工作中面临歧视或骚扰的人，就会敲响警钟。例如，许多人证明了 "结对编程 "的实用性，但这种做法--两个开发人员一起编码，每个人轮流看着对方的肩膀--假定两个编码员对彼此都很满意。同样地，敏捷 "回顾 "的所有细节似乎都很健康，但我看到它们沦为无结构的一系列指责；一切都取决于谁在领导团队。而GitHub的前社区安全经理Coraline Ada Ehmke描述了其他开发者是如何利用代码审查的--这本来是一个让开发者互相检查工作的低风险方式--作为骚扰的工具。我们早就知道，消除官僚主义、等级制度和文件感觉很好，直到你是需要规则来保护的人。

敏捷甚至可能在科技行业的一些更臭名昭著的失败中扮演了一个角色？2021年10月，当我看到前Facebook经理转为举报人的弗朗西斯-豪根（Frances Haugen）在国会作证时，我突然想到了这个问题。如果一家公司设定了提高用户参与度的目标，敏捷的目的是让开发人员一心一意地朝着这个目标努力--而不是与经理争论，例如，向人们展示激起他们偏见的内容是否是个好主意。这种道德上的争论与敏捷所宣称的让开发人员在项目上狂热工作的奉献精神是不相容的，不管它是什么。

当我们考虑到当代软件可能涉及机器学习、大型数据集或人工智能等技术时，这个问题就变得特别紧迫，这些技术已经显示出其潜在的破坏性，尤其是对少数族裔而言。数字理论家伊恩-博戈斯特（Ian Bogost）认为，这种快速移动和打破东西的方法正是软件开发人员应该停止自称 "工程师 "的原因：他指出，工程是一套具有道德准则和公认的对公民社会承诺的学科。敏捷承诺没有这样的忠诚度，除了对正在建造的产品。

敏捷善于将各种功能分门别类，将它们整齐地打包到冲刺阶段和交付成果中。实际上，这也是软件工程的一种趋势--模块化，或者说 "信息隐藏"，是人类管理太过复杂的系统的一种重要方式，任何一个人都无法掌握。
但是，通过把功能变成白板上的 "用户故事"，敏捷有可能创造出Yvonne Lam所说的 "否认链"：
在一条流水线上，没有人在任何时候对团队创造的东西承担全部责任。

《敏捷宣言》描绘了一幅诱人的工作场所民主的图景。问题是，它几乎总是在致力于底线的工作场所实施，而不是致力于工人的福祉。有时，这些优先事项是一致的；宣言提出了一个强有力的理由，即企业的产品可以通过工人的自主权得到加强。但它们也有可能发生冲突，比如当项目经理在对客户的承诺和开发人员自己的优先事项之间徘徊时。

"一家学术机构的软件工程师Mark Matienzo说："人们希望将流程作为一种管理你无法控制的模糊性的方式。"特别是在那些你被视为有些无能为力的地方，无论是对上层管理或行政部门的奇思妙想。所以你可能无法在高层次上影响项目的战略方向，但敏捷允许某种概念上的开发者自由意志。" 与我交谈的产品经理说得更直白。"敏捷使人们认为他们对自己的工作有所有权，但从劳动的角度来看，他们实际上没有所有权，除非他们有大量的股票期权或其他东西。

软件开发从未整齐划一地纳入公司所期望的时间表和指标。现代应用程序的复杂性使得它的开发有时感觉像炼金术一样合乎逻辑。计算机可能是作为军事装备出现的，但要使编程工作完全服从于资本的优先次序，却出奇地困难。当软件工程不能约束开发的不稳定性时，企业转向了敏捷，它将开发者要求的自主权与对组织目标的一心一意的关注相结合。然而，这种自主性是有限的，正如开发人员越来越多地指出的那样。当应用于企业环境中时，敏捷所推崇的方法和价值观无一例外地都是以企业的需要为导向的。无论工作场所多么灵活，会议多么随意，底线都必须是组织的利润。

不过，关于敏捷还有一个角度。与我交谈的一些人指出，敏捷有可能促进工人之间的团结。如果团队真正地自我组织，分享关切，并公开发言，也许敏捷实际上可以借由工人组织起来。也许管理层通过敏捷正在制造自己的掘墓人。也许软件开发的下一个危机将来自工人本身。

banq注：注意黑字圈重点。