2.3 敏捷软件开发的精髓
2.3.1 人与实践
本质上，软件开发是人类的一种智力活动，是一种艺术性和科学性相结合的工作。不关注人的因素，软件开发就会失去控制。
要关注人的因素，最实际的办法就是注重以人为本的实践。我认为，敏捷软件开发思想的精髓就在于人与实践。
与很多传统行业不同，软件开发行业汇集了高度密集的智力活动。众所周知，智力活动是一项非常特殊的工作。
多年的实践告诉我：追求人的主动性，是智力活动密集型企业的最高目标。追求主动性的原因在于，评价智力活动的成果是一件非常困难的事情，如果缺少了人的主动性，一切工作都会流于表面，组织的目标就会无法实现。
有一家顶尖的高科技企业，对员工采取军事化的管理，企业的规模和技术能力以惊人的速度在发展。
这种现象超出了我的理解。军事化管理只有在狂热的理想主义支持下，才能激发人的主动性。狂热的理想主义在一个商业化企业中是无法持久的。
我宁愿相信这是个特例，其中有很多我不了解的特殊机遇和背景。
为了说明主动工作的重要性，我想举个例子。
在建筑工地，一堆建筑材料要搬送到指定的地点。工地上的项目经理，指派了两个建筑工人，要求他们在下午5点前完成这项工作。项目经理下午来看了看，建筑材料都已到位。好，任务完成了。就这么简单。
软件开发就不同了。Robert C. Martin在Agile Software Development: Principles, Patterns and Practices一书中详细介绍了一次编程实践。
Bob Koss和Bob Martin为了编写一个保龄球记分小程序，进行了长时间的讨论和尝试。尽管在思考不成熟的阶段就进行频繁交互是错误的，但是，我不得不指出，主动性在这一次编程实践中发挥了极其重要的作用。
没有主动性，他们也可以完成这个程序——一个不那么精炼、合理、稳健，而且没有经过全面测试的程序。他们可以把表面上没有问题的程序交付给用户。接下来，就是众所周知的故事，那些隐藏着的维护成本，一定会在计划之外的某个时刻冒出来。
主动性很重要，它是提升组织生产效率的关键因素之一。但是，仅仅强调个人的主动性还不够。作为一项社会性的工作，软件开发还需要更多地考虑团队这个整体。
软件开发人员聚集在一起工作，他们有着各自的性格、文化背景、信仰、好恶、做事风格、能力和利益。像所有的社会性活动一样，各种复杂的关系会逐渐在团队中形成。在这样一种复杂的社会关系中，要保持个人的主动性，是一件很微妙的事情。我们会在后续的章节中，详细讨论团队的话题。
在软件开发组织中，应该设立一个专门的部门。它没有建立秩序的职能，而是专注于调整社会关系、提供心理指导、服务于个人。这个部门的目标，是在保持个人主动性的基础上，充分发挥个人的技能。
为了提高软件开发人员的主动性，通常有两种方法。一种方法是，传播信仰，使团队成员成为同志；另一种方法是，建立一系列以人为本的实践方法集，用习惯和文化融合组织成员。敏捷软件开发致力于第二种方法。
我希望有一种更准确的表述。在我看来，通过方法或手段来提高软件开发人员的主动性是错误的。从理想主义者的角度来看，软件开发人员和企业之间的关系是平等的，他们以一种契约的形式，相互服务于对方。一切都建立在“内驱力”之上。
Alistair CockBurn
在Agile Software Development: The Cooperative Game, 2nd Edition一书中，从西方人的角度，对人的因素进行了分析。我总结了一下，在他看来，软件开发中的人主要有以下的缺陷：
- 人的沟通永远是不完全的，完全的沟通是没有必要的；
- 人是古怪的；
- 人们通常宁可保守地失败，也不冒险用不同的方式追求成功；
- 人们喜欢临时创造而不喜欢积累；
- 人们不能始终如一。
从东方人的角度来看，这些缺陷也是存在的，而且远远不止这些，在2.4节中我还会继续展开这个话题。
Alistair Cockburn在《敏捷软件开发》一书中，还提到一个故事。
Dave A. Thomas是Object Technology International的创始人，这是一家拥有很多成功项目记录的公司。一天，他向我总结了他的成功公式：“有些人能交付软件，有些人不能。我雇佣那些交付过软件的人”。
这是一种结果导向的方法，绕过了所有复杂的过程，就像看云识天气。但是，我们这里要讨论的是一些更普遍的问题——讨论云如何形成。
敏捷方法的拥趸针对软件开发中人的缺陷提出了很多解决方法，包括那些众所周知的方法集，像XP，Scrum等。与CMM的境遇完全相反，这些方法集在业界大受欢迎，不仅仅受到了软件开发组织管理者的欢迎，也受到了广大软件开发人员的欢迎。
这种现象一点也不奇怪。首先，敏捷方法是旧秩序的反对者。在新秩序建立之前，人们期望改变的想法，会给反对者加足分数。其次，敏捷方法以人为本的思想，是符合时代潮流的。人们渴望被尊重，不喜欢约束性强的事物。
尽管我见过的很多软件开发组织都声称自己使用了敏捷方法，但是真实的情况是怎样呢？与没有真正发挥CMM的作用一样，声称的敏捷方法实施大多都成了失去控制的代名词。
意外的想法仍然产生了。AlistairCockBurn指出了一些敏捷方法实践者的误区：
- 迭代必须简短；
- 敏捷团队必须驻扎在一起；
- 敏捷团队不需要计划；
- 架构已死，重构是你全部所需要的；
- 我们不需要什么经理；
- 敏捷开发在纪律上要求很低；
- 敏捷只适合最优秀的开发人员。
有趣的是，尽管没有外部的指导，很多人却不约而同地陷入相似的“误区”。看上去，人们过于期待那些可以把自己从约束中解脱出来的方法了，所以，人们往往走向了约束的反面。这些误区的存在，说明很多人还没有真正理解敏捷方法的本质。
场景故事点评：
宗方推行的敏捷方法，是教条式的。这和敏捷方法实践者的“误区”有所不同。“误区”来自更加激进的一些人。在宗方看来，敏捷开发需要强有力的纪律保障，需要很好的管理，也需要细致的计划。他要求迭代必须简短，这并不是出于技术上的考虑，而是觉得人太闲了不好。我们可以看到，他关注人的因素，但是关注的角度和敏捷方法不太一样。
例如，宗方认为：每个岗位上的人都要做备份，这可以解决人员流动问题；技术人员只需要解决眼前的问题，这足以让客户满意；通过季度奖的考评，可以保证软件生产的顺利进行；进行短期培训，技术人员可以快速上岗等。
孔如之则不同：他更加关注人的主动性，他相信团队可以解决问题，他更加关注培训的效果，以及对人员评价的客观性。他希望的是一种公平、有趣、有意义的工作环境。另外，他追求一种积极的文化气氛。
我们前面谈到，人的性格是多种多样的。宗方和孔如之在性格上的不同，给团队建设带来了一定的复杂性。我们会在以后的章节中讨论解决这一问题的办法。但是，无论如何复杂的环境，追求人的主动性是不变的，这是提高生产效率的唯一途径。
我们来看看敏捷软件开发宣言：
“通过开发软件和帮助别人开发软件，我们找到了一些更好的开发软件的方式。通过这一工作，我们得出了这些价值：
- 个人和交互要胜过过程和工具；
- 可工作的软件要胜过全面的文档；
- 客户的协作要胜过合同协商；
- 对于变更的响应要胜过遵循计划。
也就是说，尽管右边的项也有价值，但我们认为左边的项更有价值。”
在这份敏捷软件开发宣言中，表达了一些思想，但是没有具体的实施细则。这给了我们更多的实践空间。从一个实践者的角度，我更愿意用一种灵活的眼光，来看待软件开发中的事物，比方说，项目经理的职责问题。
在我看来，项目经理最重要的工作，应该是为软件开发提供服务。他是那个扫清路障的人、积极进言者、精神鼓舞者，而不是那个拿着时间表、冲着软件开发人员发火的人。要保证软件开发的进度，项目经理的频繁干预，不是一件好事。组织必须培养有责任、有追求的团队。这类团队，应该围绕着一位主刀医生角色的软件开发人员展开工作。
我的想法并没有违背敏捷软件开发宣言。
和CMM相比，敏捷软件开发欠缺了一些系统性，运用时显得更加随意，或者说，灵活。Alistair Cock Burn在反驳实践误区时，还隐约表明了一种态度，对敏捷方法来说，任何有利于目标实现的实践，都是不反对的。
敏捷软件开发不是一个有着固定套路的方法论，这有点像风清扬的独孤九剑。但是，它非常重视实践方法。这些实践方法，被有意识地汇集在一起，然后通过“手册”和“指南”，向大众传播。敏捷软件开发希望人们快速展开行动。
和RUP这类以结果（文档和报告）来约束的方法论不同，敏捷方法以可供模仿的实践为核心。
敏捷方法中的实践就像导演提供的剧本。在影片拍摄期间，导演总是会要求你完成那些设计好的动作和台词，从而快速进入角色。相比而言，敏捷方法中的“剧本”更加简单，它给人们留下了巨大的发挥空间，当然，与此同时，它也对人们的能力提出了较高的要求。
XP要求的工作方式是这样的。
开发队伍和几个客户一起工作，两个人使用一台电脑。三周为一个周期，每个周期都要交付可运行的、已通过测试的、用户可以直接使用的代码，2到5次周期后有一次发布。需求以故事的方式表达。程序员估计一下完成一个故事的时间。客户根据需要定义优先级，调整范围，尽量在周期内完成最有价值的故事。开发过程中，每天举行例会，陷入困境的人可以在这个时候找到帮助。最后是不断地简化和重构代码。
敏捷方法，以人与实践为核心，有一定的积极意义。在“剧本”的帮助下，我们可以在认清事物本质之前就展开行动。同样，在“剧本”的约束下，我们即使犯错误，也不会走得太远。当我们有朝一日恍然大悟的时候，会发现自己还是在同一个“剧本”下工作，但认识已完全不同。
最后，在敏捷方法中，一项计划用两个月完成的任务，可能在两周内就交付了，原因是选对了一个关键的软件开发人员。而在CMM中，所有的人，都被假定不具备这样的能力。每个人几乎都要通过过程的审查。这也许是二者之间另一个比较明显的差异吧！