论敏捷管理与团队文化的契合度

前言

说到敏捷管理，很多程序员或者软件开发公司的管理人员第一反应就是“小步快跑，频繁发布”。这令公司决策层（老板）觉得敏捷能解决一切问题，想啥时候上线就啥时候上线。

其实这只是一种表象。

要深刻理解敏捷的本质和内涵，必须先了解一下它的前辈：科学管理。

什么是科学管理

科学管理的代表产物就是“流水线分工生产”，根据它的提出者，又叫“泰勒式科学管理”。

科学管理的产生背景是在第二次工业革命期间。之前依靠经验的作坊式生产，已经被工厂和机器生产代替，但工人工作习惯依然受传统经验式生产影响，没有合作、分工的机制。对于生产效率的追求，促使人们开始研究生产活动中的劳动时间和工作方法。

其中，泰勒通过三个实验，奠定了其科学管理的理论基础。

金属切削实验

从1881年在米德韦尔公司，为了解决工人的怠工问题，泰勒进行了金属切削试验。他自己具备一些金属切削的作业知识，于是他对车床的效率问题进行了研究。在用车床、钻床、刨床等工作时，要决定用什么样的刀具、多大的速度等来获得最佳的加工效率。金属切削试验前后共花了26个月的时间，实验三万多次，耗费80万吨钢材和15万美元。

搬铁块实验

1898年，弗雷德里克·温斯洛·泰勒从伯利恒钢铁厂开始他的实验。这个工厂的原材料是由一组记日工搬运的，工人每天挣1.15美元，这在当时是标准工资，每天搬运的铁块重量有12～13吨，对工人的奖励和惩罚的方法就是找工人谈话或者开除，有时也可以选拔一些较好的工人到车间里做等级工，并且可得到略高的工资。后来泰勒观察研究了75名工人，从中挑出了四个，又对这四个人进行了研究，调查了他们的背景、习惯和抱负，最后挑了一个叫施密特的人，这个人非常爱财并且很小气。泰勒要求这个人按照新的要求工作，每天给他1.85美元的报酬。通过仔细地研究，使其转换各种工作因素，来观察他们对生产效率的影响。例如，有时工人弯腰搬运，有时他们又直腰搬运，后来他又观察了行走的速度，持握的位置和其他的变量。通过长时间的观察试验，并把劳动时间和休息时间很好地搭配起来，工人每天的工作量可以提高到47吨，同时并不会感到太疲劳。他也采用了计件工资制，工人每天搬运量达到47吨后，工资也升到1.85美元。这样施密特开始工作后，第一天很早就搬完了47.5吨，拿到了1.85美元的工资。于是其他工人也渐渐按照这种方法来搬运了，劳动生产率提高了很多。

铁锹实验

铁锹试验是被称为科学管理之父的弗雷德里克·温斯洛·泰勒所进行研究的三大试验之一,也称铁砂和煤炭的挖掘实验。它是指系统地研究铲上负载后，研究各种材料能够达到标准负载的锹的形状、规格，以及各种原料装锹的最好方法的问题。
他对每一套动作的精确时间作了研究，从而得出了一个“一流工人”每天应该完成的工作量。这一研究的结果是非常杰出的，堆料场的劳动力从400－ 600人减少为140人，平均每人每天的操作量从16吨提高到59吨，每个工人的日工资从1.15美元提高到1.88美元。
泰勒因这项实验提出了新的构想：将实验的手段引进经营管理领域。计划和执行分离。标准化管理。人尽其才，物尽其用，这是提高效率的最好办法。

泰勒对于生产活动中涉及生产的所有要素以接近实验科学的方式进行定量分析和改进，提出了一系列划时代的管理思想：工作定额原理、挑选头等工人、标准化原理、计件工资制、劳资双方的密切合作、建立专门的计划层、职能工长制等等，最终其出版的《科学管理原理》迎来了一个全新的管理时代。

福特汽车公司之所以取得今天的巨大成就，与福特汽车公司创始人亨利·福特推行科学管理是分不开的。1910年，福特开始在高地公园新厂进行工厂自动化实验。他率领一群高效率的专家，检讨装配线上的每一个环节，试验各种方法，以求提高生产力。而他最重要的突破就是利用甘特图表进行计划控制.创造了世界第一条汽车装配流水线，实现了机械化的大工业，大幅度提高了劳动生产率，出现了高效率、低成本、高工资和高利润的局面。

树型组织结构和科学管理

泰勒对于生产活动的定量分析并大幅提高生产效率令人印象深刻，但实际上都是针对工厂管理生产活动的，并未涉及大型企业的组织治理问题。而对于敏捷管理来说，通常还会强调一个组织形式问题。讨论敏捷组织的时候，我们往往拿树型组织结构来类比（敏捷团队是自组织的，更像网状），但实际上树型组织结构比科学管理出现的更早。

有史可考的第一张组织结构图很可能晚至1854年才问世，它的编制者是纽约铁路公司的总裁丹尼尔·麦卡伦（Daniel McCallum）。
当时，麦卡伦的公司正负责建筑一条从泽西城到大湖区、贯穿宾州与纽约、全长近500英里的铁路。麦卡伦认为，在其他条件均等的情况下，这条铁路的每英里建筑成本应该低于那些短程铁路。
然而，事实上这些其他条件却很难等同，修一条长500英里的铁路，牵涉的方方面面工作肯定要比修50英里铁路复杂得多。若无高效组织，这条铁路的每英里建筑成本很可能要比那些短程铁路不降反贵。
为此，麦卡伦编制了一张组织结构图。根据亨利·瓦卢姆·普尔（Henry Varnum Poor）的记载，这是一张树型结构的图表，其根部代表铁路公司的总裁和高管层，枝干代表公司的5个职能部门和客运、货运部门，树叶则分别代表地方票务代理、货运代理、工段长及其他员工，等等。
历史上，组织结构图的诞生被认为是西方工业社会从自然的人治向企业化管理转变的一个重要标志。经此转变，组织能力逐渐成为企业生存竞争的先决条件。

而之后泰勒的科学管理开始将计划与执行分离，将管理人员和生产人员的职能分开。而对大型企业组织按功能性进行划分和科学管理的人员专职化思路，两者正好契合，就携手发展成了现代的企业组织和管理模式。

科学管理的小结

科学管理是“传统管理”么？在今天看来可能算是一种“传统管理”。但实际上，我们可以看到科学管理出现的年代，“传统管理”是指作坊式经验式管理。就是，依赖每个人自己的经验和想法去组织和管理生产活动。十年经验的老师傅必然生产效率比两年经验刚入门的工人要高，但再高也难有数量级的差异。而科学管理通过分解生产流程，工人专职化，通过设计整个流程，每个环节上的工人尽量做最标准化、最简单、最容易培训的事项，通过分工，实现流水线生产，从而整体上达成生产效率数量级的提升。

我们可以看到科学管理的巨大成功，但同时也可以看到它的一些特点：

要生产的产品必然是标准化的，确定的，有固定的设计图或者配方
生产的流程是可以分解的，步骤化的，可度量的，每个环节要处理的事项是标准化和明确的，或者培训成本不高的
生产效率的提升核心是做设计规划的人，执行者只需要挑出够用或简单培训后即可上岗的工人，以及根据个人产出（计件）的度量引入竞争机制和激励机制来对执行者进行优胜劣汰
对工人的要求，从工作时间到休息时间，甚至每个动作，用的工具都可以提出规范性的要求（对人工的需求也是标准化的，可替代性非常强）
产能规模的扩大只需要复制一条又一条“流水线”，包括机器、够胜任的工人和车间主管。只要资金足够，水平扩展非常容易。

敏捷管理的来源

那么，敏捷管理的思想又源自何处？

在软件开发行业，一开始的软件工程项目的实施过程和流水线是非常像的，我们称之为“瀑布式开发”。按需求,设计,开发,测试，逐一执行。只有前一环节完成了，再进行后续环节。

需求阶段，要把需求调研清楚，需求文档完全确定下来，然后进入设计阶段；
设计把实现方案完全考虑清楚，设计文档完全确定下来，然后进入开发阶段；
开发进行编程编码，封版，然后进入测试阶段；
测试按需求文档和设计文档，进行非常周全的测试，修复缺陷，最后出具测试报告。

最后一个软件就开发完成了。

看起来很合理，制造业的流水线在软件开发项目中好像也行得通，而且在早期这种模式确实是可行的，因为早期软件项目都是大项目，要解决的是非常专业领域内的问题，比如航天软件、操作系统，编程开发有极高的门槛，使用计算机也有极高的门槛，对于一个需要采购计算机的企业，硬件都是一笔巨款，软件研发经历几年都是很正常的。

而随着PC作为企业办公硬件的普及，以及后来互联网信息化时代的到来，世界瞬息万变，需要开发软件的企业越来越多，而企业发现自己的软件项目还在编码开发的时候，突然原先理解的业务发生变化了，等软件开发完成，可能已经不适用了。从90年代开始，软件行业就显现出了交付危机。

在2001年，随着一群敏捷先驱针对行业项目管理和交付困境的讨论，以及各自的实践经验总结，敏捷宣言诞生，一种新的软件项目管理思想和众多实践方案开始推广。（实际上是先有Scrum、XP等敏捷实践方案，后有的敏捷宣言，这一事实是不是也挺违反直觉的呢）

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具

可工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷宣言遵循的原则：

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷管理的小结

和泰勒近乎实验科学式地定量分析生产活动一样，敏捷宣言是对软件开发活动的观察和经验总结。

敏捷宣言的目标是解决瀑布式软件项目管理的长周期和应变不足导致交付灾难的问题，通过沟通进行协商来应对变化。

从敏捷宣言的内容我们可以发现敏捷倡导的是：

主动沟通，积极反馈，不仅是团队内的沟通，还指所有干系人包括客户
通过协商来应对变化，交付的是价值
用交付可工作的软件来说明软件自身的功能以及实际研发进度
团队持续学习，团队基于信任自组织化

这里我不展开Scrum的具体做法（不打算在本文继续展开具体的敏捷实践方法论了），敏捷具体实践中一般都有迭代/冲刺概念，即倡导在一个固定的较短实践周期内去增量的交付软件项目的功能特性。

即使敏捷宣言的每个字我们都认识，我们可能还是无法掌握敏捷的精神；即使我们一遍遍的培训Scrum的343或者Scrum的5个价值，我们在具体落地的时候依然会遇到各式各样的问题。

从个人所经历的多年软件项目敏捷实践经验，我得出的结论是必须对你想搭建的敏捷团队的每一个成员解释清楚为什么需要敏捷，以及敏捷是一种什么样的工作模式。这个过程实际上是打造团队文化的过程，但这真的不是一件容易的事。

敏捷团队文化

铺垫了这么多，要开始扣题了。

制造业流水线的目的是为了规模化生产，提高生产效率，生产目标是标品；而软件开发的目的是为了满足各种各样的定制需求以及研发过程中可能出现的需求变化，生产目标是非标品（如果是完全一样的需求，软件系统的自身的复制几乎是毫无成本的）。

科学管理的目标是希望生产过程如流水线一般一切都可控可度量，精确到不会因为任何一个不可控因素而导致生产效率受到影响。科学管理把人分成不同职能，安排好不同职能的人的分工，并且在分工上是有序的，各司其职，各做各的，不需要关心整体流程，只要做好自己那一环，整体的流程由另一群人设计。它的本质（做一个不太恰当的比方）是整个生产过程的机械化，包括生产工具和参与生产的“人”。“人”在满足基本技能要求的情况下，也是和工具一样可替换性越强越好。

而敏捷管理正好相反，敏捷团队中虽然也会有分工，不同职能的人形成一个团队进行工作，但其实对团队中的每一个人，都有很强的全局意识要求。因为团队工作核心在于持续交付和应对变化，每个人都必须清楚知道自己以及和自己配合的人，是否在做正确的事，是否按预期在推进。任何理解上的不一致，都有可能对团队目标造成影响。

所以敏捷对于个体的主动性要求是非常高的。

而即便有了主动性，也还是不够的。主动性只能保证沟通是及时的，却无法保证信息传递的正确性和完整性。敏捷团队实践中最困难和最具挑战性的是达成集体共识，这指的是对需求的理解一致，对当前团队要完成的目标，要实施的方案以及各自分工要完成的任务的理解一致。

由此敏捷对于沟通中的语言和表达方式的一致性也是有要求的。团队成员必须在同一个层面上，以相同的形式进行沟通。不同职能的人会有不同的专业技能，不同的专业技能可能会在表达中掺杂各自的专业术语，这种沟通方式就是不合适的。对于软件开发来说，所有的沟通术语都应当是团队所面对的业务术语，而沟通方式，我这里强烈推荐以UserStory为基准，贯穿所有职能和整个研发路径。UserStory描述的是用户以什么身份、为了什么目的、如何使用软件的。这个表述方式可以直接和用户/客户讨论（获得客户的反馈是至关重要的），无需任何专业背景就可以理解，当然也适合团队中不同职能的成员。试想在一个需求讨论会议中，几个开发人员在讲设计模式，讨论数据结构，此时旁听（甚至插不上话）的产品经理如何确定大家理解是一致的？

科学管理要打造一个有序世界，并且不停思考如何优化以提高效率；
而敏捷面对的是一个混沌世界，要考虑的是如何在不确定性和复杂性中围绕团队的目标摸索出一条能持续前进的道路。

很多讲敏捷的书都会特别强调这里的“复杂”是指“错综复杂”，即各种各样的因素，互相之间也会有影响，有连锁反应。在软件开发中，一方面指的是业务的复杂性（问题域），另一方面指的是系统的复杂性（解决方案域）。为了应对这两方面的复杂性，对于敏捷团队来说，又会需要一种持续学习的特质。只有不断学习业务领域的知识，不断学习可能要用到的专业知识，才能有更好的敏捷能力去达成团队目标。（对于持续学习业务知识这件事，很多高级开发可能受领域驱动设计理论影响认为项目里必须要有一个领域专家，但实际上在大多数中小项目中，这是可遇不可求的。比较好的情况是能在实际用户群体中找到那么一个对业务非常了解的人，那么一定要珍惜向对方学习业务知识的机会）

最后，缩短反馈周期，以交付可工作系统为进度，就需要固定的Timebox和稳定的增量交付节奏。这自然而然又会引导团队工作是价值导向的。而到底什么工作是对客户有价值的，实际上是由团队中不同职能的成员一起决定的。

总的看下来，会有一种感觉：其实敏捷团队自始至终都是在“一边学习了解要解决的问题，一边增量式的交付，一边验证并反思积累经验再应对下一步”。好像和科学管理比起来，敏捷团队做事情不那么专业和靠谱的样子，甚至很多客户会觉得你区区乙方还拉上我甲方，教我做事？

强调个体互动，强调沟通和共识，强调持续学习，允许团队自身决定工作安排。我突然领悟到，敏捷团队实际上是把一群不同职能的人当成一个人来用，实际上是在科学管理出现之前的依靠老师傅经验的作坊式生产的回归（现在的敏捷培训必不可少的环节就是工作坊演练）。

所以，敏捷的团队文化，就是主动、共识、信任、成长以及凝聚力。这些措辞并不是一句空话，而是真正能跑顺敏捷的关键。“成功的团队”最终会如同“一个人”。

至此，对于敏捷实践中如何打造一个团队的文化的关键点，你是否Get到了呢?