标签：而且 lock 价值 ref 敏捷 授权 日常 包括 需求
译者：Nikijv
审校：Bob Jiang
英文原文
一个Twitter的帖子问"敏捷"是否反管理，以及"敏捷"为什么经常看起来很像反管理。简单写一下，本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样，并不是反管理。这比反管理更激进：这是一种完全不同的管理方法。
敏捷软件开发仍然比当今的认知更激进，相当的不幸，包括大部分品牌和方法，在我这个有点老的男人对云观点大喊大叫的时候，也被大多数较小的"敏捷"供应商所采用。
敏捷软件开发正如我们所定义的那样，对于业务与开发间的日常协作较为频繁，以维持增量的可工作软件。这样团队称为自组织团队，尤其要说明的是：最好的架构、需求、设计来自这些自组织团队。
原则上很清楚，软件、架构、设计等一切工作都源自于团队，从团队中涌现。
例如，需求不来自于一些业务单元，而是通过中央委员会进行传递，然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。
这不是"反"管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他"管理"关心的主题。
当然，敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术，是解决软件开发应该被管理的新方式。
敏捷是反管理的么？我不这么认为，敏捷明确反泰勒式的管理，而支持推动管理。
同样，像所有好人一样，我们更乐于好的富有成效的管理，强烈反对贫瘠、无效、有害的管理。
但是我想建议这个底线是：
如果一个组织试图通过任何传统的方式控制团队的选择，该做什么以及如何做的选择来管理敏捷软件开发，这样很可能他们做错了。
如果你是敏捷的支持者，你试图与传统管理达成某种中间状态或和解，有可能你也是没有真正理解敏捷软件开发的根本意图。
一、scrum在发光
考虑到Scrum的构想，最流行的敏捷方法如果不是最有效的，那什么是？
Scrum称为自组织的团队，包括产品负责人，被授权于全部权利和责任，负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队，必须包含交付产品增量的"全部必要技能"，一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。
Scrum承认Scrum团队是嵌入式的，以某种方式，在一个组织中，组织提供了资金（投资），干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作，邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。
冲刺审查是Scrum团队及其嵌入组织之间的完整接口。
关于Scrum仍然有些问题没有解答，同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算，如何决定补偿，如何评估性能等等。
在Scrum课程中，人们经常询问各种管理职能。有个经典实践可以回应，课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置：开发团队，产品负责人，Scrum教练以及其他。
将会有两件事发生。首先，许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务，由产品负责人决定要构建什么，由Scrum教练支撑和引导等等。有趣的一点是，总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些：这已经超出了Scrum的范围。
然而，很明显，Scrum打算不管这些超出范围的管理职能是什么，它们与团队的首要接口，可能只通过冲刺审查。尤其是除了产品负责人，没有人可以要求团队做任何事情，Scrum对"经理"在Scrum团队运行时可以做什么做了非常具体的限制。
二、敏捷软件开发是反管理么
敏捷软件开发需要一种新的管理方式，在团队规模上，团队内部拥有对产品的所有权利和责任，而且最主要的接口是检查实际演变的产品。
不一定是"反管理"，但一定与某些类型的管理背道而驰，尤其是源自于泰勒主义更具有侵入性的形式------福特主义，将工作视为机器，工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念，但与戴明和统计过程控制等概念的对立程度要小得多。
但我觉得主要的概念已经相当清楚：敏捷软件开发是一种完全不同的管理方法，尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限，但它设定了一个相当严格的下线，这个下线是嵌入在团队内部的产品做什么以及如何做。
三、这些想法的限制是什么
这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队，这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作，客户有时基于固定价格安排，或者更常见的基于运行速率为产品提供资金。
今天，更多的限制是被组织强加的------试图做"敏捷"，这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位：不同的团队成员"属于"一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。
坦白讲，自组织团队被授权，而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。
底线，敏捷软件开发提倡不同的管理方式，很可能与一些过时的管理观念不相容，不幸的是，这些观念在今天仍然相当普遍。
反对的？不。完全不同？是的。
本文首发于 Bob Jiang的博客 ，转载请联系 Bob Jiang
标签：而且 lock 价值 ref 敏捷 授权 日常 包括 需求
原文地址：https://www.cnblogs.com/bobjiang/p/12804261.html
