1、Extreme Programming（极限编程，简称 XP）是由 Kent Beck 在 1996 年提出的。Kent Beck 在九十年代初 期与 Ward Cunningham 共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有 效。Kent 仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996 年三月， Kent 终于在为 DaimlerChrysler 所做的一个项目中引入了新的软件开发观念XP。 XP 是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观 是交流、朴素、反馈和勇气；即，任何一个软件项目都
2、可以从四个方面入手进行改善：加强交流；从简 单做起；寻求反馈；勇于实事求是。XP 是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个 相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚 开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。 什么是软件开发 软件开发的内容是：需求、设计、编程和测试！ 需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解 决什么问题；测试案例中应该输入什么数据为了清楚地知道这些需求，你经常要和客户、项目经理 等交流。 设计：编码前，肯定有个计划告诉你要做什
3、么，结构是怎样等等。你一定要按照这个来做，否则可能会 一团糟。 编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。 测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你 是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。 软件开发中，客户和开发人员都有自己的基本权利和义务。 客户： 定义每个用户需求的商业优先级； 制订总体计划，包括用多少投资、经过多长时间、达到什么目的； 在项目开发过程中的每个工作周，都能让投资获得最大的收益； 通过重复运行你所指定的功能测试，准确地掌握项目进展情况； 能随时改
4、变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划； 能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的， 正在进行或未完成的的工作则应该是不难接手的。 开发人员： 知道要做什么，以及要优先做什么； 工作有效率； 有问题或困难时，能得到客户、同事、上级的回答或帮助； 对工作做评估，并根据周围情况的变化及时重新评估； 积极承担工作，而不是消极接受分配； 一周 40 小时工作制，不加班。 这就是软件开发，除此之外再还有其它要关心的问题！ 灵巧的轻量级软件开发方法 一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格
5、定义了许多的规 则、流程和相关的文档工作。灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起 来相对较容易。 在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很 繁琐，程序员之间也很难读懂对方写的代码。1968 年，Edsger Dijkstra 给 CACM 写了一封题为 GOTO Statement Considered Harmful 的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转 而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定 了很多规则和做法，发明了很多软件工程方法，软件质
6、量开始得到大幅度提高。随着遇到的问题更多， 规则和流程也越来越精细和复杂。 到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的 制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大 的辅助开发工具（Case Tools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。 为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。 失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行 删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。在这
7、些流程中，合乎实际需要的规 则被保留下来，不必要的复杂化开发的规被抛弃。而且，和传统的开发方法相比，轻量级流程不再象流 水生产线，而是更加灵活。 Extreme Programming（XP）就是这样一种灵巧的轻量级软件开发方法。 为什么称为“Extreme”（极限） “Extreme”（极限） 是指，对比传统的项目开发方式，XP 强调把它列出的每个方法和思想做到极限、 做到最好；其它 XP 所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施 XP 的项目，其 开发过程应该是平稳的、高效的和快速的，能够做到一周 40 小时工作制而不拖延项目进度。 XP 的软件开发是什么样 1 极限
8、的工作环境 为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP 要求把工作环境也 做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利 和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点 供应；每周 40 小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的 Story 卡、CRC 卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游 戏。 2 极限的需求 客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户
9、一 直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story ），例 如“计算年级的总人数，就是把该年级所有班的人数累加。” ；这些模块又会根据实际情况被组合在一 起或者被分解成更小的模块；它们都被记录在一些小卡片（Story Card ）上，之后分别被程序员们在各 个小的周期开发中（Iteration，通常不超过 3 个星期）实现；客户根据每个模块的商业价值来指定它们 的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验） 需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被 安排
10、在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试 （功能测试）。 每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面 实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发 完成后才能开始使用。 3 极限的设计 从具体开发的角度来看，XP 内层的过程是一个个基于测试驱动的开发（Test Driven Development）周 期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试 （Unit Test）。刚开始，因为什么都没有实现，所以所有的单元测试
11、都是失败的；随着一个个小的需 求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行 了对客户的承诺。XP 提倡对于简单的设计（Simple Design），就是用最简单的方式，使得为每个简单 的需求写出来的程序可以通过所有相关的单元测试。XP 强调抛弃那种一揽子详细设计方式（Big Design Up Front），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP 还大力提倡设计 复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过 程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优
12、化后的系统仍然符合所有需 求。 4 极限的编程 既然编程很重要，XP 就提倡两个人一起写同一段程序（Pair Programming），而且代码所有权是归于整 个开发队伍（Collective Code Ownership）。程序员在写程序和重整优化程序的时候，都要严格遵守 编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。 5 极限的测试 既然测试很重要，XP 就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到 一起（Continuous Integration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运 行单元测试；发现了
13、BUG，就要增加相应的测试（因此 XP 方法不需要 BUG 数据库）。除了单元测试之外， 还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是 XP 开发过程中最重要的文档之 一，也是最终交付给用户的内容之一。 XP 中的重要惯例和规则 1 项目开发小组（Team） 在 XP 中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人 对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项 目计划等。这个人扮演的是“客户” 这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕 最终用户的需求而展开的。程序员是项目开
14、发小组中必不可少的成员。小组中可以有测试员，他们帮助 客户制订验收测试；有分析员，帮助客户确定需求；通常还有个 Coach（教练），负责跟踪开发进度、 解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的 交流沟通等等。项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP 鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的 XP 开发小组。 2 计划项目（Planning Game）、验收测试、小规模发布（ Small Releases） XP 开发小组使用简单的方式进行项目计划和开发跟踪，并以次预测项目进展情况和
15、决定未来的步骤。根 据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过 测试的、可以使用的系统。 计划项目 XP 的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该 做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始 就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP 中又两个主要的相应过程： 软件发布计划（Release Planning）。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成 本、风险和每个需求的重要性，制订一个
16、大致的项目计划。最初的项目计划没有必要（也没有可能）非 常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程 中被不断地调整以趋精确。 周期开发计划（Iteration Planning）。开发过程中，应该有很多阶段计划（比如每三个星期一个计 划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新 功能，或者会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已 经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在 每个开发周期中，开发人员会把需求分解成一个
17、个很小的任务，然后估计每个任务的开发成本和风险。 这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过 一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。 这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星 期，客户总能够实实在在地看到开发人员已经完成的需求。在 XP 里，没有什么“快要完成了”、“完成 了 90%”的模糊说法，要不是完成了，要不就是没完成。这种做法看起来好象有利有弊：好处是客户可以 马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做 出来的东
18、西，可能会很不满意甚至中止合同。实际上，XP 的这种做法是为了及早发现问题、解决问题， 而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加 哪个内容等等。 验收测试 客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件 是否符合要求。XP 开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间，最好能 将这些测试过程自动化。 频繁地小规模发布软件（Small Releases） 每个周期（Iteration）开发的需求都是用户最需要的东西。在 XP 中，对于每个周期完成时发布的系 统，用户都应该可以很容易
19、地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说， 不再是看不见摸不着的东西，而是实实在在的。XP 要求频繁地发布软件，如果有可能，应该每天都发布 一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。这些版本的 一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。 3 简单设计，Pair Programming，测试驱动开发，重整和优化 XP 程序员不但做为一个开发小组共同工作，还以两个人为一个小开发单元编写同一个程序。开发人员们 进行简单的设计，编写单元测试后再编写符合测试要求的代码，并在满足需求的前提下不断地优化设 计。 简单设计 XP 中让初
20、学者感到最困惑的就是这点。XP 要求用最简单的办法实现每个小需求，前提是按照这些简单设 计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何 画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。 在 XP 中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在 XP 中，设计过程几乎一直贯 穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求 模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不 断前进和发展的过程。从这个角度看，XP 是把设
21、计做到了极致。 Pair Programming XP 中，所有的代码都是由两个程序员在同一台机器上一起写的这是 XP 中让人争议最多、也是最难实 施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因 此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。 这种工作方式 极大地提高了工作强度和工作效率。 很多程序员一开始是被迫尝试这点的（XP 也需要行政命令的支持）。开始时总是不习惯的，而且两个人 的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统 计，在所有刚开始 Pair Programming
22、的程序员中，90%的人在两个月以后都很认为这种工作方式更加高 效。 项目开发中，每个人会不断地更换合作编程的伙伴。因此，Pair Programming 不但提高了软件质量，还 增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个 项目、开发队伍和公司。从这点看，Pair Programming 不仅仅适用于 XP，也适用于所有其它的软件开发 方法。 测试驱动开发 反馈是 XP 的四个基本的价值观之一在软件开发中，只有通过充分的测试才能获得充分的反馈。XP 中 提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等； 与众
23、不同的是，XP 将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。 另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在往代码库中放程序 （Check In ）前，都应该运行一遍所有的测试；任何人如果发现了一个 BUG，都应该立即为这个 BUG 增加 一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设 计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。这样，测试才能真正起到帮助 获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求， 因此开发人员和客户可以得到
24、尽可能充足的反馈。 重整和优化 (Refactoring) XP 强调简单的设计，但简单的设计并不是没有设计的流水帐式的程序，也不是没有结构、缺乏重用性的 程序设计。开发人员虽然对每个 USER STORY 都进行简单设计，但同时也在不断地对设计进行改进，这个 过程叫设计的重整和优化（Refactoring）。这个名字最早出现在 Martin Fowler 写的Refactoring: Improving the Design of Existing Code这本书中。 Refactoring 主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring 的概念并
25、不是 XP 首创的，它已经被提出了近 30 年了，而且一直被认为是高质量的代码的特点之一。但 XP 强调，把 Refactoring 做到极致，应该随时随地、尽可能地进行 Refactoring，只要有可能，程序员都不 应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序， 保证新系统仍然符合预定的要求。 4 频繁地整合，集体拥有代码（Collective Code Ownership），编程规范 XP 开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和 Pair Programming 以外，XP 要求每个人的代码都要遵守编程规范，任何人都可
26、以修改其他人写的代码，而且所有人都应该主动检查 其他人写的代码。 频繁地整合 （Integration ） 在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程 中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍 使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为 使用时间短，客户门心里并没有多少把握。 为了解决这些问题，XP 提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的 USER STORY （每次整合一个新的 USER STORY）。每次整合，都要运行相应的单
27、元测试和验收测试，保证符合客户和 开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会 发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的 功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。 集体拥有代码（Collective Code Ownership） 在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。 因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代 码；而且，因为不清楚其他人的程序到底实现了什
28、么功能，一个程序员一般也不敢随便改动其他人的代 码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被 发现或得到比较好的解决。针对这点，XP 提倡大家共同拥有代码，每个人都有权利和义务阅读其他代 码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开 发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。 为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可 以再次看到，XP 的各个惯例和规则是怎样有机地结合在一起的。） 编程规范 XP 开发小组中的所有人都遵
29、循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为 有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现 Collective Code Ownership 的重要前提之一。 5 Metaphor（系统比喻），不加班 XP 过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP 认为加班是不正常的，因 为这说明关于项目进度的估计和安排有问题。 Metaphor（系统比喻） 为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP 开发小组用很多形象的比喻 来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的 Metaphor
30、可能就是“一大群蜘 蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。” 不加班 大量的加班意味着原来的计划是不准确的，或者是程序远不清楚自己到底什么时候能完成什么工作。而 且，开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。XP 认为，如果出现 大量的加班现象，开发管理人员（比如 Coach）应该和客户一起确定加班的原因，并及时调整项目计 划、进度和资源。XP 中一些基本概念的简介 User Story：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完 成。开发过程中，客户可以随时提出新的 User Story，或者更改以前的 User
31、Story。 Story Estimates 和开发速度：开发小组对每个 User Story 进行估算，并根据每个开发周期 （Iteration）中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多 少 User Story。 Release Plan 和 Release Scope：整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一 起确定每个发布所包含的 User Story。 Iteration（开发周期）和 Iteration Plan：在一个 Release 过程中，开发人员要求客户选择最有价值的 User Story 作为未来一两个星期的开发内容
32、。 The Seed：第一个开发周期（Iteration）完成后，提交给客户的系统。虽然这不是最终的产品，但它 已经实现了几个客户认为是最重要的 Story，开发人员将逐步在其基础上增加新的模块。 Continuous Integration（整合）：把开发完的 User Story 的模块一个个拼装起来，一步步接近乃至最 终完成最终产品。 验收测试（功能测试）：对于每个 User Story，客户将定义一些测试案例，开发人员将使运行这些测试 案例的过程自动化。 Unit Test（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。 Refactoring (重整和优
33、化 ) ：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。 小结 XP 的一个成功因素是重视客户的反馈开发的目的就是为了满足客户的需要。XP 方法使开发人员始终 都能自信地面对客户需求的变化。XP 强调团队合作，经理、客户和开发人员都是开发团队中的一员。团 队通过相互之间的充分交流和合作，使用 XP 这种简单但有效的方式，努力开发出高质量的软件。XP 的设 计简单而高效；程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早 地将软件交付给客户。XP 程序员能够勇于面对需求和技术上的变化。 XP 很象一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好
34、后，一幅美丽的 图画就会呈现在你面前。 Extreme programming 还要挑人，还有种族歧视？ 答案是“对” 也 “不对”。Extreme programming 当然没有歧视任何人的，任何人都可以去尝试 和使用 XP。可不幸的是，使用 XP 确实不是所有人都可以做的到，它对实施的和参与的程序员都提出了更 高的要求。这种要求不是技术水平，也不是学历水平，水平不高的程序员一样可以 XP，甚至可以是一很 好的 XP programmer。这种要求是对一个人的心智，道德，修养的更高要求（有点儿修道的样子哦）。 一个 XP programmer 应该具备这样一些基本素质：诚实，公正，坦诚，o
35、pen-minded，勇敢。 在这些素质的基础上，才是对技术水平，能力和天分等的要求。 让我们一起来看一下为什么 XP 要要求这些基本素质。 诚实：诚实其实是一个 Programmeer 的最基本要求，不管是 XP 还是传统或其他方法。在 XP 的项目计 划阶段，要求程序员能准确的估计一个 Task 的开发时间（小时为单位），在开发阶段，则要求程序员能 根据自己的开发进度估计剩余的时间并汇报给 Tracker。所有这些估计都是很主观的东西。而恰恰这些 准确的估计构成了 XP 规划的基础。如果程序员不能根据自己的能力做出准确诚实的估计，不但会影响自 己，更重要是对整个 Team 和项目的损害。比
36、如说如果一个程序员为了显示自己的能力，可能低估了 Task 开发时间。或是在开发中为了面子而没能及时汇报 Delay。当然 XP 的本身有针对的解决方法（Pair programming)，但是对诚实的要求仍然是必须的。 公正：XP Team 是一个紧密的团体，而 group planning 和 pair programming 都会有很多的意见的碰 撞。XP programmer 必须能客观公正的看待问题。 坦诚和 Open-minded：XP 的 group planning,group design,pair programming, code review 等都使 个人的知识水平的不
37、足或失误暴露出来。如果别人当面指出你的设计失误或编码错误，XP 程序员需要能 很坦率个开明的去看待别人的批评和自己的缺陷。我想我们在工作中也会遇到这种情况，一个人对别人 的批评最基本的反映就是防卫和反击。很多时候这种放应不是建立在对和错的基础上，而是个人自尊。 XP 的解决方法是 Colletive ownership，代码所有权共享。整个 Team 的所有程序员对所有的 Code 都有编 写和维护的权利和责任。尽管如此，坦诚和开明还是 Team work 的基本之一。其实这也就人和人的相处 之道：就事论事。一个 XP programmer 应该也必须能做到这点。 勇敢：XP 的开发是完全的
38、Team work。在设计上和编码上采用的是也是 team plannig 和 team design。XP programmer 因该主动勇敢的提出自己的意见，也需要能对 Team lead 或高级别程序员的设计 提出疑问。在以往的环境中，往往是高级人员作出决定由其他人执行。如果有人有意见通常也很难提出 不同意见，比如说你可能不会或不能够对 System Architect 的设计提出疑问因为他是高级人员和拥有独 立的办公室。虽然很动公司提倡提意见，但是往往公司的氛围和文化或制度（系统设计师设计然后程序 员编码）已经建立起一个无形的屏障。 XP 是一个完全以来 Teamwork 的管理方法。
39、不仅仅是一种管理方法，也是一种文化。 在以往的开发环境中，我们最常见的环境是这样的： 一个个小小的间隔中程序员在安静的工作 程序员都埋头专注自己的程序编写 不少的开发会议用与协调程序员之间或各个 Team 之间的工作 每周一个例会汇报个人的工作进度 每周还可能会有一个会议进行 Code Review 和学习 以往的 Teamwork，多为在口头上表达强调的人与人之间要互相帮助和协作。其目的的正确的。问题是如 何确保人和人之间真的可以互相帮助和协作。开更多的会，口头在多的宣示或行政上的压力也无法保证 Teamwork 的实现。一个很常见的例子。程序员 A 问程序员 B 的一个关于模块 A 问题，
40、程序员 B 虽然也很乐于 助人，可当时正忙于自己模块的编写，所以他以没作个这个模块 A，帮不了。这个回答是很合理的。B 正 忙，他也真的没作过模块 A。 相对来说，人总是愿意少干些活的。也总可以找到合理的借口给自己或别人。在人类进化 到无私之前，我们都无法保证自己能全心全一的去帮助别人。而人和人之间也总存在这样或那样的隔 阂。如何克服这些私心和隔阂呢？在很多公司的中采取了各种团队活动和培训来增进员工之间的团队精 神，但工作以外的活动和培训中的合作和工作中的合作毕竟有很大的不同，比如说没有时间或甚至利益 上的冲突等，因此这种方法是一种辅助但不是一个直接的解决方法。 让我们来一起看一看在 Extr
41、eme Programming 中如何来建立 Teamwork。 首先，对 XP 程序员素质的要求为有利于建立有效的团队精神。那种自命不凡，不能平等待人的程序 员不可能出现在 XP 的队伍中。 而从管理方式上，Team planning, Team design, collective code ownership 和 pair programming 都是强调用团队的力量来高质量的设计和编码。可见，Extreme programming 的所有环节都 是以 Team 为单位来进行的。这是 Extreme programming 和以往的方法很大的不同。 Team planning 和 Tea
42、m design 就是说整个 Team 一起来做项目计划和设计，所以所有的 Team member 对整个项目和设计都有发言权，同时也是有整个 Team 来对项目进行负责。这里的负责是指所有人对项目 中的所有部分负责。而在以往的环境中，很多时候是一个 Team 中的各个人负责个人设计，这样就很容易 给破坏 Teamwork 造成合理的借口，也容易在开发人员之间造成隔阂和误会等不合作的现象。在各个环节 以 Team 为单位进行开发能够针对性的克服这些弊端。 既然是以 Team 为单位进行设计，就是让所有的人员对系统的设计有控制权和全面了解，如果项目设 计出现问题，也把以往可能完全针对个人的责任分
43、给整个 Team 来分担。这样不单减轻了开发人员的压 力，而对整个 Team 的压力有进一步迫使开发人员必须全力合作来完成项目。从而进一不增强 Teamwork。 于是在 XP 项目中，就不会有这样的对话：“这个模块不是我设计的，我不懂，帮不了你啊”。 Collective code ownership（代码所有权共享）。同样的，我们也很唱见这种情况。某个模块是 A 写 的，如果有 Bug，A 就需要负责修改和测试。其他人可能会出于不伤害 A 的面子而不去修改他的程序。当 然也可能是懒惰的一个借口咯。Collective code ownership 的意义在于把以外个人对项目的责任有整 个
44、Team 来承担。所有的 Team member 必须对所有的 Code 付有责任。平等的，项目的任何成功都是所有 Team member 的努力成果。代码所有权共享鼓励任何人都可以根据需要更改其他人的 Code。所以不存在 这样的借口“这个模块不是我写的.” 。更重要的是它避免了在程序员之间的不良竞争，并把他们之 间的竞争引导到对整个项目有利的方向上。 除了这些开发管理方法外，XP 还需要其他一些微小的方式来促进 Teamwork。XP 需要一个开发式的开 发环境。过去那种一人一个小间隔的环境不是一个很有生产力的环境。开放式的开发环境允许程序员之 间可以很容易的直接交谈，随时让所有人了解项目
45、的进度和出现的问题。比如 Pair A 遇到问题，他们可 以马上和对面的 Pair B 商量解决方法。又或 Pair A 的两个程序员讨论问题，Pair C 刚巧作过同样的问 题，于是 Pair C 就可以提供意见。总之，目的就是让所有的开发人员都第一时间知道项目的开发进度和 出现的各种问题。而对项目管理者来说，他也可以随时掌握开发的状况。一个的开放式开发环境应该是 键盘声，程序员之间的讨论声，笑声交织在一起。活跃的气氛是激发创造力和提高生产力的有效方法。 出了在制度和环境上去建立 Teamwork 外，同样的,XP 也需要各种辅助方法来促进 Teamwork。在一些 XP 项 目中，电子游戏
46、（如 Delta Force,Half Life）即是一种很好，很有效和很便宜的团队合作训练。各种 需要合作的电子游戏都可以有效的提高队员之间的默契和友情。在我的经历中的一个项目中，整个 Team 的程序员们每天都在午休和下班后一起玩 30 分钟的游戏。由此一群本不认识的年轻人很快就建立起信任 和默契。Teamwork 也自然由此产生罗。当然可要有节制哦， Teamwork 可主要是用来工作的。 总之，XP 努力去建立一个开放，有趣味的工作环境，一个合作高效的开发队伍，并允许和要求队伍 中的任何一员都可以去承担项目的任何一个模块。从程序员的角度来看，他们可以放心地去度假而不需 要担心公司的紧急电话。从项目经理的角度来看，一个程序员的离开也不会对项目有不利的影响。这不 是所有管理方法所追求的么？
