管理层遇上敏捷，是不懂，还是不想懂？

Steve Denning近期在 Forbes上发表了一系列文章，着重探讨了敏捷社区所面对的一大挑战——如何获得主流管理界的认可。

在此系列的第一篇文章中，Steve就提出他独特的看法： 当今管理界的一大不为人知的秘密就是——敏捷。他解释说，千百年来，如果某个大胆的奇思妙想并不是根红苗正、科班出身，往往就会被忽略而不受待见。

……就在十几年前，管理界发生了一系列重大的突破。这些突破使得软件开发团队完成了升华——既保持纪律性又有持续革新精神。这在传统管理理念看来是不可能完成的任务……不幸的是，这些管理界的探索者并不是那些的商学院的专业学者或者大公司的高薪经理。恰恰相反，那些在你看来最不可能完成这些探索的人居然解决了这个管理问题，他们就是技术极客们！

他还谈到，他发现在管理领域几乎找不到敏捷方面的材料：

……管理界一如既往地否定着敏捷的探索。你可以去“哈佛商业评论”上搜索一下，你甚至在那些针对基础管理问题所提出的解决方案的参考资料列表中都很难找到敏捷的身影。

Kurt Häusler则 提出了另一种可能，他觉得也许用比较通俗的方法向不写代码的经理们介绍这些观念会更有效。Steve也做了回复：

……无视世上成千上万的软件开发团队的管理经验是不合理的。好主意就是好主意，就算它出自草根，也是个好主意。 超预算（beyond budgeting）、复杂性思考（complexity thinking）、精益管理以及 Rightshifting等方法显然都与敏捷软件开发息息相关，然而显然它们都没能动摇传统的命令-控制管理模型的根基。

Yves Hanoulle从一个不同的角度做了 评论：

这让我想起了Jerry Weinberg的 木莓酱定律（Law of Raspberry Jam）。博而不精，广而不专。瀑布模型其实也深受其害。大多数用瀑布模型的人都没读过 Royce的文章（如果读过的话，他们肯定会更多使用迭代了）。根据我的经验，CFO及高层管理者并不是那些会切身感受到敏捷威胁的人。若你有机会解释给他们听，他们往往很快能理解（甚至接受）。这正是我们需要在管理类刊物上发布文章的原因。

Steve Denning在他的第二篇文章中，试图通过采访 Rod Collins来揭开一个问题的答案：为什么高管老大们就是不好敏捷管理这一口呢？Rod坦言，敏捷着实让他吃了一惊。他接着谈到了现代管理模式与敏捷管理原则上的三点相同之处：

• 以客户利益高于一切为宗旨。
• 延承传统团队管理理念，讲分工更讲协作。
• 始终坚信工作本质上是个迭代上升的学习过程。

Rod进一步解释了C字头的高管老大们为什么单单和敏捷类的方法擦不出火花来的原因：

……如果你向公司高管介绍这些，他们确实很难“理解”。权力对他们而言几乎无法与一切尽在掌控的感觉分割开来。在新的管理体系中，权力的行使形式由“掌控指挥”（in charge）转化为“退后授权”（connected）。这意味着老大们不再需要事事亲自指点河山了。然而有意思的是，采用新体系的公司却要比旧体系的更加强大。

Chris R. Chapman针对第二篇文章 评论道，这其实已经不是什么新闻了：

从二十多年前第一个敏捷项目诞生起，对于敏捷的主观认知以及无法理解敏捷理念，已经成为了横在软件行业变革之路上的重重大山。有时管理者需要拿面镜子照照自己的“新装”，看看有没有不切实际的幻想，看看一针一线是不是都落在了该落的地方……理念的转变要贯彻至公司上下，打工仔、工头、老板的老作风都得重新洗牌。这也就意味着再次创业、迎接风险和变革——即使你是老牌企业。

作为对各种讨论的回应，Steve Denning另写一篇文章，总结了这一系列的话题： 反对敏捷的案例：十个常见的管理层反对意见，而十个反对意见中的六个都源自Bruno Collet于2009年写的一篇名为 敏捷开发的局限性的文章。这十个反对意见以及Steve对这些反对意见的主要观点如下：

1. “敏捷只为明星而生”
选择高效能人还是平庸之辈？传统管理模式选择了平庸之辈。

2. “敏捷不符合我们的企业文化”
在当今市场中，他们要么改变文化，要么等死。敏捷转型是他们唯一的出路。

3. “敏捷只适合小项目，而我们都是大项目”
积极应对大项目最直观的解决方案就是把工作拆分成一些相对独立的较小的子项目，随后每个部分都能当做敏捷团队来运行。

4. “敏捷要求坐在一起，而我们的队员是四散各地的”
尽管最理想的敏捷团队确实应该坐在一起，但如果队员是分散的，团队也能运用一些技术来开展公开且持续的交流。

5. “敏捷缺乏项目管理流程”
除非你选用一个包含所有所需要的流程的敏捷方法，否则你就应该把它和定义了一些流程的某个方法学结合起来使用，并且通过敏捷来进行每天日常的团队管理。

6. “我们公司的个人问责制不适合敏捷”
改革公司的奖励制度。这才是症结，敏捷是无辜的。

7. "敏捷只是一阵风潮”
没有什么银弹或者灵丹妙药……敏捷只是针对某方面问题的解决方案，也就是高纪律性的执行、创造力和革新力的完美统一。

8. “有比敏捷更好的法子”
干嘛搞得两败俱伤呢……在百家争鸣中找到共性，同心协力以求真正的进步不是更好吗？

9. “没什么新花样”
敏捷里的每个小部分都在别处广泛运用了很长时间了。唯一的新意就是把所有的东西清晰、连贯、完整地放在一起。

10. “不是公正的比较？”
引入（真正的）敏捷意味着要拆穿各级管理者为了维护权力而在他们下属面前耍得那些不怎么见光的花样。

Yves Stalgies在他的 评论中巧妙地总结了他的观点：

……敏捷是种理念，而不是方法，这一点很重要。所以我们所需的也就是理念上的转变。敏捷观念在当今软件开发中非常普遍，所以管理也必须转变观念。敏捷理念和客户满意理念都是公司成功的关键。

Steve Denning在他的《 领导者的全新管理指南》一书中进一步探讨了传统管理模式需要改变的一些方式（InfoQ的 Shane Hastie对这本书也有比较深入的 介绍）。

那么敏捷还没有完全被传统管理理念接受是因为他们不懂，还是因为根本就不想懂呢？作为社区的一份子，我们能做点什么来改变现状吗？

查看英文原文： The Management View of Agile - Unaware or Unwilling?

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。

相关厂商内容

多名敏捷社区最有影响力人物将出席Scrum Gathering上海站大会

首席科学家Martin Fowler分享21世纪的软件设计

百度开发者大会——应用万象，云创未来（成都/广州/武汉/西安/上海 免费报名中！）