【IT168 专稿】 近来写了不少敏捷开发的系列文章，如《敏捷开发中如何开发高质量产品》，《敏捷开发的架构设计》，《我的敏捷开发实践》,《敏捷开发中的Code Review》等，这些都是关乎方法的。方法固然很重要，但还有另外一部分笔者觉得非常的重要，而且不容易被人关注，也是这篇文章想和大家一起探讨的内容，这就是敏捷开发的“精神”。笔者认为敏捷开发的“精神”是敏捷开发的核心，也是敏捷开发之所以称为敏捷开发之所在。
方法和精神，孰重孰轻，是仁者见仁智者见智。但缺少精神的方法，长久以往，便形似而神不似，缺乏核心和灵魂，犹如 “行尸走肉”。君不见，美国的民主模仿者不在少数，民主民权，三权分立，权力制约，方法可谓一套一套，有Best Practice（非常好的实践）可循，但强大富强如美国者也仅此一家，如铁杆小弟墨西哥却是远不如，偷渡到美国倒是积极有余。想起前阵有一部电视剧——《士兵突击》，受到广大观众的喜爱，假如我们做一个问卷调查，问一些观众：什么是“钢七连”？答案有：钢七连是超强的作战能力，钢七连是纪律严明的团队，钢七连训练刻苦，钢七连是“不抛弃、不放弃”的一种精神。我想很多观众都会说，钢七连是“不抛弃，不放弃”的一种精神。所以，作者认为方法之外，还有超乎方法的所在，就是精神。敏捷开发也是如此，方法之外（迭代、测试驱动、重构、结对编程等），还有超乎方法的精神存在。
记得前两年敏捷开发流行之始，在公司上下掀起了一股敏捷之风，尤为壮观的是“一夜”之间所有的团队都敏捷了，全都号称自己团队正在敏捷开发，全部装备了“敏捷开发”的光环。了解之后，发现其中大部分团队的确是开始使用一些敏捷开发被推崇的方法，比如，一些团队使用了迭代开发，还有一些团队使用了结对编程，还有一些团队开始使用测试驱动开发。当然，我们团队（包括我本人）也是其中的一员。这倒让我认识到，从众心理不仅在人与人之间存在，在团队之间也是存在的。
这里倒不是去点评这些团队的做法，开始使用敏捷是值得鼓励和赞赏的。只是这样的现象引发了我当时不少的困扰和思考：到底什么是敏捷开发？是否真是“神说，要有敏捷，于是就有了敏捷”？是否一夜间大家就由于使用了一个迭代开发的方法（尽管一个迭代里面还是用瀑布），大家就都敏捷了？
直到前几天去上地的“小肥羊”吃火锅，又触动了心中一直在思考的什么是敏捷开发的问题。在“小肥羊”里现在也能看到和“海底捞”一样拉面条的小弟，也有免费送豆浆的服务。但是虽然这些方法都类似，却还是觉得和“海底捞”不太一样。后来觉得二者确实不一样，不一样的是人，是气氛，是那种服务的精神。
所以，总而言之，笔者认为：敏捷开发之所以为敏捷开发，不是因为其方法（虽然方法也很重要），而是因为敏捷的精神存在，我称这种敏捷的精神为“小跑精神”。下面让我们一步一步去看看，到底敏捷开发的“小跑精神”是什么？
敏捷开发的“小跑精神”
不知诸位读者是否都注意到一个现象，不管在哪个行业，餐馆也好，酒店也罢，甚至飞机上的空乘服务，总有一些好的服务人员，他/她们在服务时总是满怀热情地，“小跑”着为大家服务。他/她们总能注意到客人的需求，总能给客人提供及时的服务，而且总是在寻找“金矿”似的寻找自己可以贡献的地方。他/她们或许没有那种所谓的礼仪方法，满口的“您好”，“您辛苦了”，“谢谢”，“谢谢光临”这些方法，但他们的态度和精神，无时不刻地体现她们的热情，无时不刻不在感染顾客。
这就是我称之为“小跑精神”名字的来源。“小跑精神”是一种主人翁态度，是一种自动服务的热情，而不是表面的方法和寒暄。现在太多的公司和团队，都太注重所谓表面的形式，而往往忽略了内在的精神。如在任何银行的电话中心，拨打进去后都是机器的寒暄“您好，欢迎光临某某银行电话中心……”，但是如果没有真的传递“小跑精神”的服务给客户，这样的话语只不过是浪费顾客的时间和顾客电话费而已，不能感染顾客，并提高的客户满意度和忠诚度。
敏捷开发中“小跑精神”也是这样的一种精神和态度，一种对产品，对项目的由内而外的热爱，乐于贡献的主人翁精神。每个个体都可以按照组织的最高利益，自我驱动的完成组织的目标。
小跑精神可以体现在下面几点：
1. 人找问题，而不是问题找人
问题找人，是一个极其普遍的现象。在组织协调中，一个很常见的现象是“责任分散”。当一个问题由一个人负责时，犹如个体户经营，那这个个体肯定是尽心尽责，因为这是他一个人的“责任”。当组织逐渐壮大，特别是近几年全球化的经营方式，一个任务由多人负责，甚至多个不同国家的人负责的情况，已经司空见惯，这样的团体协作中，容易滋生“责任分散”的现象。
什么是责任分散？比如，在街头，四周只有你一个人，当你看到旁边有个小孩躺在地上哭，你一定会过去扶起小孩，然后提供你的爱心和帮助。但是，换另外一个场景，在一个繁忙的街边，四周都是匆忙而过的人群，当你看到旁边有个小孩躺在地上哭时，你可能会随着人群走过。这就是责任分散，当人越多时，大家都觉得，一件事情可能是别人会去做，所以自己就不去做了，而且自己不去做内心收到的谴责也不会很大。因为，所有的责任都分散到了所有的个体上，收到的内心的谴责也都分散到了所有的个体。
在软件项目管理中，也是经常问题找人，而不是人找问题。下面的场景大家肯定不陌生：
在产品开发早期，由于代码开发过快，代码混乱，需要重构。但开发人员觉得还没发生问题，无需重构。所以一拖再拖，最后索性不重构了。
今天有个Defect开给了某个开发人员，测试人员在Defect里面的描述写的不是很清楚，导致无法重现Defect。开发人员一直等着测试人员，测试人员等着开发人员，一拖就是两天过去。
今天是Code Review deadline，但没找到会议室开review会议，就延迟到了明天，明天还是没找到，就延迟到了后天，最后就是由于会议室，导致Sign Off延期三天。
类似这些人找问题，而非问题找人的现象缺的不是技术、也不是条件，缺的正是一种“小跑精神”。一种不断主动发现问题，积极解决问题的精神。
敏捷开发中的“小跑精神”下应该是人找问题，只要是对组织和项目有帮助的，都要积极主动的去思考和提高，并积极的采取行动，不要等到每次问题找你头上了再开始消极的去回应。
2. 自我决策，而不是事事等待命令
“小跑精神”崇尚流程与灵活的平衡，科学管理与情感精神的统一。当今商业环境快速变化，唯一不变的就是变化。冲在一线的“开发人员”是最了解系统架构和技术、开发工作量，某一件改动对项目影响的人。“小跑精神”的团队成员，应该拥有在一定范围内的自我决策的能力，充分灵动的为产品创造最大价值。
如果把项目比作从北京到广东自驾旅游，那除了项目目标、方向和主要的汇合点外，团队在哪个路段开什么速度行车，由于堵车走哪个小路，哪天在哪个加油站加油这些具体的执行层面，完全交由团队自身决策。这样既能下方复杂度，又能充分发挥团队的“小跑精神”，选择非常好的方式实现组织的目标。
所以，“小跑精神”是在大方向和策略不变的情况下的自我决策，而不是事事层层汇报，等待上级命令（当然在影响大方向和战略的情况下，还是应该向上汇报）。
敏捷开发“小跑精神”的管理方式
精神，是一个艺术性的事物，无法像科学一样定量衡量。敏捷开发的精神，是随着团队文化和管理方式孕育而生。软件开发的团队文化，大体可以分为下面这两个维度。一个是自上而下的计划与控制，一个是自下而上的灵活与主动。他们二者的关系如下：
计划、控制意味着从需求，到架构，到设计，到开发，测试的完全的控制和计划，代表就是传统的瀑布开发了。在软件开发管理中，总是喜欢把软件工程和另一个领域做比较：建筑工程。而且最早的软件工程的思想来源就是受到了建筑领域的深刻影响，《建筑的永恒之道》一书估计是软件从业者人尽皆知了。这对计算机软件工程的发展起到了很大的积极作用。因为软件和建筑有很多的相似性，如组件，设计，分工，计划等等。所以，早期的软件工程，强调“瀑布”开发，需求、架构、设计、开发，规划和设计好一切。这在软件出现的最初的一段时间，是被很好的应用并推广，为软件行业起到了很大的促进作用。
但随着社会的发展，企业信息技术的成熟，以及越来越变化的客户需求，建筑式的瀑布开发，已经不能符合软件团队的需求。以前，企业只要能有个网站可能就很满足，也没有太多的需求诉求，现在就不一样了，每个企业的各个部门都有信息化的需求，而且需求不断变化，不同部门之间需求有时还有冲突。这时完全计划、控制式的软件开发方式，就不能满足商业发展需求了。
此外，软件研发是管人，是管理人脑力创造性的产出，是知识密集型产业管理。管死物，可以规划计划的很详细，然后根据规划优化资源，因为事物是死的，不会产生波动和变化。犹如，泰勒用秒表对的生产的每个操作步骤进行了精密监测之后，才有了精确的工作度量方法，才能衍生大规模流水线生产，因为只有绝对的稳定，才能有绝对的控制和规划，才有了流水线的批量大规模生产和资源优化，这在管理高度劳动密集型工作时是常见的。所以，泰勒的秒表试验，量化的工作时间是是福特流水线的基础。而软件行业，是一个创造力的脑力活动过程，人的产出是波动的，变化的，很难用秒表精确（大家应该都认识到一个现象：即高产出的研发人员是一般产出研发人员的好几倍），所以知识密集型行业和人的积极性和主动性等精神方面是紧密相关。所以试图用管死物优化控制的方法去管人的大脑，是会出问题的。现在的软件行业，许多的经理和企业，都有把人当作机器般对待的倾向，大量的控制与规划，规章制度，汇报会议，审核流程，这样的企业文化和团队中，是很难出现员工的主动创造，主动贡献，更不可能出现“小跑精神”的企业文化和好员工，不钻流程的空子偷工减料就算不错了。所以敏捷开发是在计划控制的基础上，把上图的中间线向右边移动的过程。敏捷开发注重灵活主动，更加注重人的作用，而不是以控制、流程管死物的方法来限定人的积极性，这样的管理方式更容易产生精神产物，也就是敏捷开发“小跑精神”的基础。
中国人向以以德服人、无为而治的管理方式而著称，这是上图中偏右的管理方式，而西方则擅长量化的科学管理方式，是偏向左边的管理方式。而敏捷开发则是一个中间的一个平衡。计划和控制，是科学；灵活、主动是艺术，敏捷开发是科学与艺术的统一。
计划和控制是冰冷的，没有情感的，没有活力的；灵活主动是火热的，是洋溢热情的，是突出主动贡献的。绝对的灵活，也是要出大问题的，组织会变得失控，失去章法，最后慢慢衰退。很多国内的小型软件公司，很多就是过度灵活，软件生命周期没有良好的定义和流程，没有良好的质量控制，也没有开发流程和测试流程，如此企业规模一大，就很容易出现问题。所以一些民营企业软件公司，想要做大做强，就必须要有章法，要有控制和规划，引进科学的管理方法来管理软件研发过程。绝对的计划和控制，组织就会僵化，没有创新力，失去激情，如一些大型的国企，过度的规章制度和控制，使得组织缺乏激情和创造力。所以，这二者，没有绝对的好，也没有绝对的坏。上图中，中间的虚线是软件管理的方式，那么敏捷开发，是从以往的绝对控制的科学管理开发方式，逐渐向右移动。当然，这就导致敏捷开发中控制和规划的元素少了一些，艺术管理的意味大了一些，但艺术这东西，说不清道不明，这也难怪大家用方法来衡量敏捷开发。
敏捷开发更加注重管理艺术的成分，而不是把软件工程当作绝对的科学。强调灵活、主动、热情的“小跑精神”。融合了人性化的管理和科学的方法，这不能不说是软件业管理方法的一大改进。
敏捷开发的“阴阳之道”
前不久，和一位资深的架构师谈天，他说了一个形象的比喻来形容组织中的“老化现象”，他说道；组织就像一棵树，组织变得越来越大，树干、树枝就越多，而树枝和树干逐渐失去活力，而最新加入公司的员工，就犹如一颗大树上的新叶，迸发着青春和激情，但随着工作时间增长，也就慢慢的老化，失去往日的激情，慢慢成为组织的“朽木”。任何组织和团队，如果这样的朽木越来越多，终有一天会枯竭。
敏捷开发正是这样一种软件管理方法，崇尚组织和人的精神，它的灵魂是灵活、热情、主动的“小跑精神”。敏捷开发是计划控制到以人为中心的一个转变，是“中间线”向右一直移动的过程。至于那根线该移到哪个位置，应该灵活到什么程度，就没有绝对定量的衡量。管死物还可以是科学方法，用Project工具、甘特图等方法规划，加以定量；而精神层次则带有艺术成分，是难以科学量化，而敏捷开发就是这样科学与艺术的结合管理方法。它们二者之间难以去量化，你无法去确定他们的比例是什么样的，也无法量化哪个多、哪个少。所以，用下面这张图来描述敏捷开发我觉得更为合适。
上图是中国古代的太极阴阳鱼，形象化地表达了阴阳轮转，相反相成是万物生成变化根源的哲理。对敏捷开发而言，也正适合深刻表达出计划控制和灵活主动，科学管理与艺术管理之间的互相转化，相对统一的关系，所谓动极而静，静极复动，一动一静，互为其根，而这就是敏捷开发的管理之道。
精神是艺术层面的产物，比较困难去定量的衡量和引导。如何去建立和加强敏捷开发团队的“小跑精神”，又如何去衡量团队成员的绩效评估呢？下一篇文章，我们将继续这个话题。
