这是一本讲敏捷软件管理的书籍，但是封皮上赫然写着海尔集团首席执行官张瑞敏推荐作序，一个副标题是“让每个人成为自己的CEO”，这个封面就让我很讶异，海尔是做家电的，张瑞敏怎么会关注起敏捷软件开发的书来？

序言中他提到的是海尔的人单合一以及自主经营体和自组织，这个确实是和敏捷想要达成的目标一致的。万维钢在精英日课的第二课中推荐的书籍就是Ken的《Scrum敏捷项目管理》，是讲怎样提升工作效率的。物理学家也在推荐敏捷的工作方式。Scrum的另外一位发明人Jeff Sutherland今年的新书《敏捷革命》，其中举的很多例子也都不是软件行业的，说明Scrum这种工作方法和框架已经在强力的向软件之外的行业渗透。想想也难怪，其实Scrum本身是从橄榄球借鉴而来，并不是软件行业的专利。所以，从这个标题来看，这本书并不是讲软件开发的，其中并没有一行代码、模式或者框架，也没有提到任何工具。

另外两位作序的也都是牛人，一位是bob大叔，一位是Edward Yourdon，但都是老外，感觉没有张瑞敏的说服力大，就不多说了。

好了，言归正传，说下从这本书中学到的东西和一点感想。

前言

什么是管理3.0？

管理1.0=层次体系

大家都知道泰勒的科学管理，这个作者认为是管理1.0，典型特征是层次体系。

在金字塔顶端的人拿着最高的薪水，实现最大的自我，拥有最昂贵的座椅。在金字塔底端的人则拿着可怜的薪水，不用负什么责任，也没有任何动力好好工作。

显然作者对于科学管理是颇有微辞的，不过其实科学管理刚刚诞生时把组织的运作效率提升了很多倍，也许是在当前的社会形态下越来越有些不合时宜了。

管理2.0=流行

平衡计分卡、六西格玛、约束理论、全面质量管理、《一分钟经理人》、《领导力21法则》、《从优秀到卓越》，这些工具、理论或者书籍，作者全部将其归入到管理2.0的范畴，这些确实都是现在流行的东西，也是我们一直在努力学习的东西啊。作者认为管理2.0有时管用，有时不管用，总的来说就是这套东西过时了。

这些东西有时是正确的，有时却是错误的。他们推陈出新的速度比为小孩换尿布的速度还快。

确实，管理理论实在太多了，应接不暇，冯仑也提出过管理的五大悖论。

管理3.0=复杂性

二十一世纪是复杂的世纪。所有的组织都是网状系统。管理主要关乎员工及其人际关系，而非部门和利益。

仔细思考一下这几个观点，其实和罗胖几年前一直鼓吹的互联网思维，去中心化是一样的意思。作者把他的这个想法命名为管理3.0，当然并没有申请任何专利。

领导和管理

作者提出自己对领导和管理的认识：

领导的职责是鼓舞人心和引领方向，而管理则是具体执行。
——错。因为任何人都可以成为领导。所有员工，从高层的主管到底层的开发者，都可以鼓舞他人并给他人指引方向。这个观点和温伯格在《成为技术领导者》中表达的思想相同，在几位技术人员处理一个故障时，并不是最活跃提供最多想法的人是领导，而是那个沉浸在问题分析中并最终给出解决方法的人是领导。

自组织的人不需要管理者管理，只需要有远见卓识的领导。
——错。因为企业拥有资产，关心组织命运的人要能判断自组织的结果是“好”还是“坏”。自组织和层次体系并没有好坏之分，不能只靠信仰做事情，还要有科学基础。这个观点说的是不是“无恒产者无恒心”的意思？

实干家领导

现实要求我们对管理和领导采取实用主义。每一个业务都必须站在所有者的角度进行管理。管理者要有领导能力，但很多领导角色都可以由组织中自组织（不是管理）起来的人来担任。这些非正式领导者应当明白自组织不怎么受所有者意愿的支配。这一切都是在管理者授权的情况下发生的。

这本书是为实干家写的。

前言结束，正文开始

第1章 为何事情没有那么简单

任何复杂问题都有一个清晰、简单但错误的答案。

——H.L. 孟肯，新闻记者，作家（1880-1956）

开篇作者就表明了自己的态度：

敏捷软件开发是最好的软件开发方法，旧式的管理方法是实施敏捷的最大障碍。

为什么？

无论你怎样为系统做计划，它就是不会如你所愿，现实世界是非线性的。在科学世界里，因果决定论取得了巨大的成功，科学家可以据此准确地预测诸多事件和现象。复杂理论是二十世纪的产物，在二十世纪末成为一门独立的学科。霍金说二十一世纪是复杂的世纪。复杂理论是二十一世纪最重要的概念之一。

每发生一个问题，我们都习惯于找到一个根本原因，温伯格将其称为因果悖论。

控制的概念在工程师和其他理科生中格外有“市场”。正是这些工程师创造出科学管理，并使命令和控制的管理风格从20世纪早期风靡至今。

我正在反思每个一级故障都要找到一个根本原因到底对不对的时候，作者给了我一个参考答案：

根源分析难道一无是处吗？
根源分析有许多价值。我的意思其实是根源分析只能帮你回顾过去。可以使用它来解决已经发生的问题，并防止它们再次发生。然而，它不能帮你预测未来的问题。

这个答复很及时而且到位。

敏捷管理

敏捷软件开发（部分）植根于复杂性理论，它承认因果决定论无法胜任成功的项目交付。许多众所周知的敏捷概念，诸如自组织和涌现，都直接来自于复杂性科学文献。

尽管敏捷软件项目在投资回报上取得了巨大的成功，但世界各地的管理者对组织内采用敏捷项目管理和敏捷软件开发方法的设置的障碍有着不可推卸的责任。

在任何类型的变更管理中，传统管理方法通常都是问题，而不是解决方案。

管理3.0模型

管理3.0，关注的是如何管理团队，如何集中精力于能力而不是预测性。管理3.0模型从6个视角来看待管理：赋能团队、激励员工、调和约束、培养能力、壮大组织结构、全面改进，作者将其描绘为一只6眼怪兽，算是一种可视化吧。

每一个视角，作者用两章来描述，一章是理论，一章是实践。

反思和行动

在复杂系统中，很多结果存在着多个原因，并且原因和结果之间存在着循环关系，没有一个原因是真正的根本原因，因此，根因分析可能无法捕获你所在世界的复杂性，但与聪明能干的同事讨论则可以。组织进行这样的讨论。

嗯，貌似这是我经常要做的事情，故障定责确实麻烦，很多故障并没有这么清晰的界限。

第2章 敏捷软件开发

这本书讲敏捷管理，先用一章的内容把敏捷软件开发是怎么回事讲了一下。

敏捷前传

作者说到年轻时自己编写的一个账本应用软件的经验，这个软件功能很好用，并且质量非常稳定，卖了很多份，为自己赚了第一桶金。成功经验是如下几条：

我对构建产品充满了激情
我本人就是一个关键客户
我没有计划，只有一个功能列表
我在构建产品时不断地完善流程

“就是这样。我有强烈的动机，有关键客户，没有前期的计划，遵守严格的纪律和自组织的流程。即使我从来没有开发过账本应用也没有关系，真正重要的是我渴望学习。”

在我完成账本应用十年之后，我发现我以前遵循的（部分）流程，现在突然被称为“敏捷软件开发”。

今天在和一位同事讨论敏捷的时候他也提到了，你说的这些敏捷的原则，和我们十几年前做软件时有什么区别？我说根本思想差不多，现在增加了不少成体系的工程实践，本来理论就是实践的总结。软件研发的核心是人，所以敏捷是希望能够把人员激活，把组织激活，把组织的学习意愿带起来，同时，我们的版本质量和效率也会有很大提升的。

敏捷宣言和敏捷联盟

经典的4+1的敏捷宣言，就不列出来了，具体的解读在敏捷导入时也说过了。

很多人认为，敏捷宣言是对那些正式的、按部就班的官僚化方法的反击。然而，几乎没有人意识到它也反对软件开发世界中那些不和谐的地方，比如无纪律性的程序员，混乱的流程，质量低劣的产品。

纪律、流程，在敏捷软件开发中仍然是需要的，并且可能还更加强调，比如会议的纪律，CI的纪律等等。

敏捷的基本原则

人：首先最重要的是，敏捷认为人是独一无二的个体，而不是可替换的资源，同时人的最大价值不在于他们的头脑，而在于交互和合作。

职能：团队和客户（或客户代表）一起合作，维护一个始终变化的未完成功能列表，并持续为其设定优先级。对所有功能来说，简单是良好设计的关键，当功能实现后，客户将立即验证其有效性。

质量：关注质量是产品取得成功的关键，所以技术上的精益求精在敏捷核心中找到了自己的一席之地。敏捷专家承认涌现式设计的必要性，即最好的架构不是预先就定义好的（可能有一个基本的形式），它可以在产品开发过程中逐步浮现出来。

工具：在敏捷环境中，工具的目的是促进团队的激励、交流与合作。

时间：每个发布都是一个潜在的可交付产品，同时，团队总是孜孜以求可持续的开发节奏，使其能够长期保持其开发速度。

价值：价值始终在变化中，所以需求会变化。敏捷宣言诞生的主要原因是为了拥抱变化，环境从来不是静态的。这一点说起来容易做起来很难，客户和我们的意识很难转变过来。

流程：尽管敏捷宣言提倡人胜于流程的模式，但这并不意味着流程不重要。敏捷环境本身就包含许多必要的流程：最小计划（或递进式规划），每天面对面的交流（通常是站立会议的形式），通过评估可以工作的软件来衡量项目进度（客户签收的功能）。

冲突：内部冲突既是复杂系统固有的一个方面，同时也是创新的土壤。对于那些乐于持续改进的人来说，它将是一种巨大的特权。

敏捷的竞争

这是我觉得最有意思的一段，作者提到敏捷这个大社区中互相进行良性竞争的各种方法，包括：Scrum与XP，Scrum与看板，甚至Scrum与Scrum。一个比较大的竞争对手是精益软件开发。

精益软件开发旗帜鲜明的集中于消除浪费和整体优化，从管理学的角度对敏捷世界做出了巨大的贡献。

软件工艺运动是一个规模略小却颇具实力的竞争对手，其指导思想是软件工艺宣言，该宣言既是对原有敏捷宣言的扩展，也是对它的挑战。

软件工艺宣言

精益求精

作为胸怀大志的软件工匠，我们在亲身实践专业化软件开发，也在帮助他人掌握这一工艺，我们要设立更高的目标。我们认为：
“可以工作的软件”犹不足，尚需精益求精；
“响应变化”犹不足，尚需稳步增加价值；
“个体与交互”犹不足，尚需专家社区；
“客户协作”犹不足，尚需卓有成效的伙伴关系
在追求左项的过程中，我们发现右项亦不可或缺。

还有一些传统的软件工程方法：CMMI, PMBOK, PRINCE2, RUP以及从没听说过的AUP, OpenUP, EssUP。

读到这句的时候我肯定笑了：然而敏捷实践者倘若不彼此反对的话，他们就不是敏捷实践者了。

我想起来何勉在他的《精益产品开发》中也搞了个宣言的，我司在成立专家组的时候也搞了个专家宣言。要做大事，必须要先有个旗帜才行，所以《建军大业》中抛弃之前的军旗，重新画一个镰刀军旗的那一幕才是真正的转折点。

敏捷与职能管理

VersionOne在2009年的报告中认为管理者阻碍了敏捷转型，对此作者有一点不同意见，认为敏捷软件开发低估了职能管理的重要性。

为了让组织享受到敏捷转型的好处，他们需要知道一个重要问题的答案：在敏捷世界里，管理者路在何方？

作者把职能管理和项目管理两个角色分开，这本书的主要目标是帮助职能经理（包括开发经理和团队主管）理解他们在组织中的角色。

时间已过12点。从8点半到现在，3个半小时过去了，本想继续写第3章的，但一篇文章也不宜太长，同时要保证睡眠时间，不然影响明天工作，所以留待下次吧。