“敏捷项目管理就是胡闹！”

摆脱繁冗的流程制度文档的敏捷项目管理是否真的敏捷？

| externalreality

译者 | 弯月，责编 | 屠敏

首先，我想说“敏捷项目管理就是胡闹，其弊大于利”。最近一段时间里我一直在研究科技界的人员流动，重点研究了程序员的流动，我可以毫无保留地说所谓的敏捷项目管理是导致程序员流动的一个主要原因。

敏捷项目管理的目标是以客户为中心和迭代的方式开发软件。这个目标很崇高。然而，无论是有意还是无意，敏捷对于剥夺开发人员对工作的满意度有着负面的影响。

举一个例子。大约在10年前，我曾与一些对Ruby社区中有影响力的人共事。我们都曾就职于“敏捷”软件公司。我记得在完成了项目的某项任务之后，开发人员回过头想认领与该任务在逻辑上有关联性的任务。然而，他却吃惊地发现那个任务卡已经被另一个人认领走了。于是，他在办公室里愤怒地喊道：“在这种工作方式下，即便我完成了一项任务也毫无成就感。”

所以说，敏捷剥夺了开发人员拥有之后的满足感以及完成工作时的成就感。如果开发人员的这种成就感被剥夺了，那么这种成就感转移到哪里了呢？大概是项目经理吧。项目经理的职责是管理团队的“速度”，而这是努力工作的产物，而非任务管理。

因此，导致开发人员离职的原因主要有三个：

1）没有拥有之后的满足感；

2）没有完成任务之后的成就感；

3）其他人抢占了他们的劳动成果。

即便这些不是开发人员离职的唯一原因，但也是主要的原因。此外，还有不友好的工作环境、各种歧视等等。

不可否认，科技公司1.5-2年的开发人员流动率让人痛心疾首。我们犯下的错最终会损害我们的业务与开发人员的职业生涯。

对此，网友们也发表了自己的看法：

评论1：

我完全同意。据我所知，管理人员一味崇尚开发速度只会摧垮软件。

我曾就职于几家中型和大型科技公司，我亲眼目睹项目经理和工程经理为了奖金，努力推动开发人员以更快的速度开发。

他们不惜让开发人员走捷径（例如跳过编写测试的步骤），甚至奖励能够更快完成任务的开发人员。如果其他开发人员在代码审查期间不批准他们的补丁，或者花时间修复那些因“快速工作”而获得奖励的开发人员代码中的错误时，他们就会大发脾气。

管理人员将他们的压力转嫁给了开发人员，而软件的质量最终被击垮。

评论2：

当有人提出总体目标是提高“速度”时，我觉得问题往往在于他们对“速度”本身有着误解。

我的意思是说，速度是“前进的速度”加“方向”，而绝大多数的组织活动在建立理性且经过深思熟虑的“方向”上面都存在失误，也就是说你要经过严格的要求、严格的设计、严格的验证才能确立正确的方向。人们往往只“前进的速度”，因此难免会陷入了南辕北辙的尴尬境地。

当组织将“速度”树立成KPI或OKR指标时，通常只“前进的速度”。只要你的开发周期越来越短，就会获得奖励。在这类组织中，激励措施简直就是胡闹，他们会要求你完成任务的速度不断增加：由每月1倍速，变成每月10倍速，再到每月100倍速。

没有人愿意为了一味地加快速度，而做一些随机的垃圾任务。这样的任务分配只适合机器，而非人类。

原文：https://news.ycombinator.com/item?id=20417768

本文为 翻译，请。

【End】