PM见习手册

一，资源管理

资源管理包括人，软件，硬件

1． 人

一个人，什么时候到你的项目的，什么时候出去的，在你的项目中的时候表现如何，优点在哪里，缺点在哪里。他的联络方式，当前的主要技能等等，需要你去了解，记录下来。当你评价你的一个员工，你只能说出来他好，不好，而不能说出来好在哪里，不好在哪里，那么很显然，你无法很好的使用这个员工，你浪费了人力资源，员工无法充分发挥出自己的能力，你得不到预期的好的结果，两伤。

 

项目经理不能高高在上，也不强迫项目经理需要跟员工做朋友，但是，你应该了解你的员工，包括工作能力，生活状况等等。项目，团队才能更好的发展。你的员工情绪不好，压力很大，那么就很容易犯错。虽然你也可以说，这不是我应该管，我能管的事情，但是不可否认，这会影响项目的质量，你会失去一次构建完美团队的机会。很难想象，在人情味缺失的团队中，会产生什么太好的工作结果。你假装管理团队，那么团队就会假装给你干活。你不关心你的员工，你的员工就不会关心你。你的团队就是个伪团队。一个伪团队项目出了问题，是隐藏问题，还没有暴露出来，团队成员的声音是：就算被发现了，那是项目经理的事情，跟我有什么关系，他一天牛轰轰的，我不说，说了工作量又增加了，说不定还被骂一顿。项目经理的声音是：那是某某没做好，就算被发现了，关我什么事，肯定是他忙着自己买车的事情，没给我好好干活，我不说，说了还需要跟客户解释，麻烦。最后，客户发现了，客户的声音是，你们团队干活质量太差了，不能继续给你们活了。

 

问题出在哪里？表面看，大家推卸责任，只要能减轻自己的负担，事不关己，高高挂起。实质上是团队建设的缺失，是项目经理没能很好的理解你的员工，并让你的员工理解你。

 

项目经理的一个重要责任，是调动团队成员的积极性，充分发挥大家的能力。那么，首先就需要了解大家，理解大家，并让大家了解项目状况，了解你。

 

项目经理高高在上，不是不可以。

 

项目经理不熟悉大家的能力，精神状态，不可以。

 

大家不熟悉项目经理，不敢跟项目经理对等交流，不可以。

 

2． 软件，硬件管理

项目中使用了哪些软件，版本多少，哪些是需要缴费的，总计费用多少，那些人安装了。出项目的时候是否删除了。这些是需要纪录的。

 

项目中使用的软件版本一定要征得客户的认可。一旦项目进行一段时间之后，客户向你强调，某某软件一定需要使用某某版本的话，你已经进行的工作该如何处理？你会陷入一个非常尴尬的境地。

 

项目中额外购置了哪些硬件，比如内存，显示器，发给谁使用了，使用期限到什么时候。这些是需要纪录的。

 

你说这些都要项目经理来做，那项目经理部就成了打杂的，什么都要管。

 

没错，项目经理就是打杂的。不过，你可以考虑在项目中安排一个帮手，帮忙你来处理这些琐碎的事情。

 

你说我不管这些事情，那么好吧，当费用超支，当有人来找你说显示器怎么少了一个的时候，你会知道，有些事情补救起来是非常痛苦的。

 

二，沟通计划

沟通计划主要考虑什么时候或者什么状况下，应该如何进行沟通。

 

1． 什么时候

比如，每周一早晨10：00—11：00例会，例会内容主要为上周工作总结以及本周工作展望。会议形式为大家报告，项目经理总结，提问。需要大家准备好自己的上周工作总结。工作总结中需要包括，上周作业预定，实际完成状况，遇到过的问题，自己的心得，等等。

 

需要项目经理明确通知大家：

        例会时间，地点

        大家需要准备的资料

        准备资料的注意事项，重点，比如：

                      进度状况

                      进度落后原因，预定解决办法，预定解决时间段

                      共享遇到的问题

                      共享解决问题经验

                      共享辅助作业工具

        等等

 

2． 什么情况

比如，当有进度出现落后的时候，需要报告，

比如，当作业相关问题，每天16：00之前，记录到Q&A之后，统一发送。

比如，紧急状况，直接跟TL联络，或者直接跟项目经理联络

 

项目经理不要认为，以上种种局面发生的时候，你的团队成员应该知道该如何处理。或许，作为一种职业素质，你的团队成员确实应该知道，但是作为项目经理你不能这样认为。

 

也许因为每个人的经验不同，理解不同，同样的局面会有不同的处理手段，有些可能是错误的，有些可能是正确的，但是项目中需要统一处理方法，同样的状况，不允许出现有些人找小A，有些人找小B，有些人直接跟客户联系，或许最终都能解决问题，但是隐患太大，当项目经理希望了解一个事情的来龙去脉的时候，会发现，谁都不了解，或者谁都不愿意承担这个责任。

 

所以，项目经理应该尽量明确，各种状况下，应该如何沟通，无法判定的情况下，应该找谁商量如何沟通，并由对应担当者将结论整理，纳入沟通计划之中。

              3.常见沟通计划

                            团队内部例会：每周

                            与客户的例会：每周

                            阶段性总结会议：一个比较完整的阶段之后，比如编码结束

                            问题讨论会：有重大课题，或者问题出现过多，或者某一阶段结束后

                            Q&A沟通计划：每天，或根据具体状况

                            进度报告：每天，或根据具体状况

 

三，环境构筑

环境包括办公室环境和开发环境。

 

1． 办公室环境

良好的办公室环境是构筑完美团队的一个非常重要的主成部分。没有人会愿意为了工作而工作，谁都愿意开开心心的工作。我们看到花草芬芳，杨柳吐绿就会心情舒畅，看到美女就会两眼星光，精神兴奋。在一个糟糕的办公环境下，谁也无法保证工作质量，谁都会希望早日逃离。

 

办公着装：汗脚穿个拖鞋，打扮得好似小混混，朋克一族，女生穿个超短裙，打扮过于性感。都是不太合适的。需要项目经理去纠正。

 

办公环境：允许大家说笑，但是不能把办公室搞得跟菜市场一样。有人在工作，有人在听音乐，有人在打游戏，很明显也是不合适的。你说，我在学外语也不行么？当然不行，耳朵里面插着耳机，恐怕谁看了都不会太舒服。

 

加班：不要让加班成为习惯。你说干不完怎么办？前面说了，项目经理应该对一项作业所需时间有一个正确的判断。如果一个人白天偷懒，晚上加班，项目经理对这些都做不到心中有数，那么这个项目经理如何管理他的团队，如何能够服众。没有人愿意加班，一个都没有。（当然，有些光棍，回去也没有事情做，在办公室吹空调，打游戏，美气名曰加班。而有的老板就愿意看这一套表面功夫，那咱们也没办法。不过这种事情形成风气以后，是一个很大的毒瘤。有些人，本来我没什么事情做了，但是如果我不加班，我的评价就没有加班的同事评价好，怎么办？加吧。不过加班没有钱，家里还有很多事情等着处理，时间长了，都会有情绪，都会有想法，都会心理不平衡，在加班这个事情上，他没办法表现，但是在其他方面，比如质量，比如责任心，比如配合度，比如其他的一些什么心思）当然，项目有波峰，有波谷，波峰的时候可能没办法，作业量就是多，无法协调，OK，可以加班，但是不要让加班形成风气。不要让加班成为表面功夫。一个习惯加班的团队，只能说明项目经理的无能，以及项目存在着巨大风险。并不能说明你的团队工作积极。

 

谈心：项目经理应该多去了解，关心你的团队成员，不只是工作上的，包括生活上的。这样可以增强团队成员的归属感，责任心，有助于团队氛围的建设。我曾经遇到过一位员工，有一天回家有点晚，冬天，他回家那条路比较昏暗，并且人烟稀少，小伙子被人抢了。第二天打电话给我说，被人抢了，打的满脸都是手印子，不好意思上班，想请两天假。并表示一部分不涉及安全敏感信息的工作他可以在家里完成。因为当时项目进度非常紧，基本没有缓冲时间，小伙子心里也清楚，所以电话中听他说得也吞吞吐吐挺不好意思地。当时我的第一反应是这小伙子人身有没有受到更进一步的伤害。在了解到没什么大碍之后，安慰他好好休息，并买了一些水果去看望他。然后向团队成员表明，小伙子遇到了一些麻烦，需要大家帮忙把他的工作承担一下，虽然为了保护小伙子的面子，没有说明具体细节，但是说清楚状况之后，团队成员都非常愿意帮助这位小伙子分担一部分工作。并且无论这个小伙子，还是其他多承担了一部分工作的团队成员，都觉得这个团队挺有人情味儿的。都挺愿意在这里工作。我想也很少人那么刻薄，不愿意互相帮助。关键在于项目经理有没有在日常的小事情中给大家灌输这个思想，有没有让大家相信，这是一个集体，大家会互相帮助。很多人，不是不愿意去帮助别人，但是有的时候，总是他在付出，在他需要的时候却无法得到帮助，他会不平衡，慢慢的，会恶性循环，大家都不愿意帮助别人。项目经理需要协调，平衡这种状况。在国内项目普遍技术含量较低的状况下，很多项目的失败，不是因为技术，就是因为这些人事上的事情，处理不够妥善。

 

2． 开发环境

比较常见的开发中会遇到的相关环境如下：

a.      版本管理，比如CVS,VSS,SVN

b.      文件服务器，用来存放一些安装软件，或其他一些项目相关的东西

c.       每个开发人员拥有的机器环境。

 

一般来说，我们要考虑如下问题。

a.      权限的控制，比如某一些文档，你的团队成员只能看，不能改，某一些文档，只有leader层以上的人可以修改，某一些文档，只有特定的人才可以修改。这些，首先当然需要立个规矩，在有了规矩之后，需要进行相应的权限设定，不是项目经理说，这个文档只有小A可以改，然后大家都去遵守就可以了。需要权限设定，以避免其他人的误操作。

b.      文件存放结构的明确。对于文件服务器，项目经理或者对应的管理人员，需要制作使用说明，用来说明文件的存放结构，比如安装软件全部都存放在Install目录下面的SoftWare，团队成员的成果物，全部都要放到成果物目录下面的以各自名字命名的目录下面。这些，需要制作文档，加以说明。否则，每个人都有自己的习惯，随意乱放，会导致局面失控。

c.       关于每个人的机器环境，应当制作相应的设定文档，文档中需要记述如何设定个人机器环境，以及如何判定是否设定成功。这样一方面可以保证团队成员环境一致，另外一方面，当团队有新人加入的时候，可以很轻松的使其保持与大家的一致。当环境设定相关做法还不明确的时候，应该安排专人进行设定尝试，避免团队多数成员尝试失败之后，无法恢复环境的现象出现。

一，作业指示

全部的作业都应该详细记录在WBS中，而当项目经理，或者各级Leader向团队成员发布作业指示的时候，需要注意说清楚：

什么时间段内

以什么资料为基础

如何

作出什么样的成果物出来。

 

 

让我们来看一个案例：

    项目开始后，项目经理没有做任何前期的准备，在接受到客户的一个作业指示之后，项目经理发布作业指示，关于XXX的单体测试作业要开始了，相关资料我已经放到了XXX地方，请尽快完成这个作业。有什么不清楚的地方请联系我。（相关资料是一些Jar包，UML图，和一些说不清楚是什么用途的文档）

 

    看出来如上的作业指示问题在什么地方了么？

 

如上作业指示的问题在于：

1．  没有明确的作业时间段，接收到作业指示的团队成员不知道这个工作是要从什么时间做到什么时间。

 

2．  没有明确工作环境，比如JRE，JUnit等等该使用什么版本。最最基本的工作环境的问题都没有解决，那么如何尽快完成这个作业。经团队成员询问后，得到的回答是各个担当者随便搭建就可以了。后来作业做到后期的时候项目经理问：环境为什么没有如何如何搭建。担当者问：现在的环境有什么问题么？项目经理回答说我们工作中用到的单体测试环境一直都是如何如何的。这个环境需要修改。团队成员问，作业开始的时候问你的时候怎么不说呢？项目经理回答说：以为大家都知道呢。“以为”。。。。。这是要不得的。如果不明确要求的话，那么工作中默认是没有特别要求，所有的特别要求都应该明确在书面材料中记载出来。在你的作业指示或者其他的，比如环境构筑中体现出来，重点地内容需要反复强调提醒。

 

3．  以什么资料为基础虽然在作业指示中有提供，但是没有对提供的资料进行必要的说明。也许客户就是这么发给项目经理的，但是项目经理不能这样直接发送给担当者，项目经理需要首先去了解这项作业的内容，而不是简单的像下传递。或者项目经理可以考虑安排人手去熟悉这一份作业的内容，然后由其制定作业计划，经过项目经理确认之后，在开始作业。项目经理在什么都不了解的情况下，简单的将作业向下发布，并简单的要求“尽快完成”，一方面，担当者不知道该做什么，该如何下手，另外一方面，很容易引起担当者的反感，导致不配合的现象出现。

 

4．  没有如何去做的说明

可能项目经理认为这不需要说明，员工应该知道该怎么做。但是事实是，每个人的做法都不尽相同，项目经理需要制定一个或粗略，或详细的工作流程说明，否则，当客户向你询问，某某错误是如何产生的，你们是如何做的，影响范围有多大。你该如何回答？每一位员工每一位员工的去确认么？随着项目规模的扩大，这显然是不太现实的。

 

5．  没有作业对象的详细列表。这项作业的源程序是客户做好了，要我们做单体测试，源程序就放在相关资料的Jar包里面，Jar包里面包括了编译后的Class文件与源文件。而一直以来团队成员得到的消息都是要从开发做起，不知道只需要做单体测试，做单体测试的话也没有任何资料中记载了哪些类需要做单体测试，源程序也没有通过cvs等版本控制软件来传送，而是直接放到了一大堆的相关资料中。那么，最终作业结果的混乱基本已经可以预期了。

 

   当时这个案例在得到缺少了众多重要信息的作业指示之后，团队成员发信以及使用即时聊天工具与项目经理沟通，希望说明如上的信息是项目经理应该主动考虑，提供的，而不是等到团队成员询问到的时候才考虑，但是项目经理的回答是这些问题都是Offsite应该考虑的，可怜的团队成员们，这些东西是Offsite能够考虑的么？每一项都是需要跟日方明确的。作为项目经理，你可以指导你的团队成员帮助你去整理这些问题点，你可以说小A，你去估算一下这项作业所需时间，整理一下作业范围以及我们能够拿出怎么样的成果物，然后交给我确认一下，这是可以的。作为项目经理，你可以因为时间不够，或者该任务重要度较低而将该任务的一些工作交给你的leader或者作业担当者去处理，但是要点是需要你来明确告知对方的，调查结果是需要你跟客户明确的。试想一下，这个案例中的项目经理，如果他的团队成员不负责任一些，既然项目经理说了，这些都是我们需要考虑的问题，那么我们就随便做。这样团队成员的积极性受到的打击可想而知，做出来的成果的质量可想而知。被隐藏掉的问题也可想而知。等到项目经理或者客户发现问题的时候去询问小A，你怎么能干成这样，你能力怎么这么差的时候，你不会得到答案，项目会走上死路。后来的实际状况也基本是这样的，经过了大量的沟通，采用作业指示模版限定了该名项目经理必须完成哪些事情。但是因为该名项目经理或者是因为责任心的问题，或者是因为能力的问题，或者是因为没有理解为什么要做这些事情，只是走形式的使用作业指示模版。为项目中发生的众多问题埋下了伏笔。

 

     为什么我会如此重视这个作业指示里面存在的问题？看起来好像也不是什么大不了的事情，没有写清楚的话直接沟通问清楚就好了嘛。事情实际上最终事件也是就这样平息下去的。但是我所担心的是，表面上看是项目经理没有考虑上面这些问题，但是，深层次的，很有可能是项目经理少考虑了很多东西，或者根本就没有考虑任何问题。项目经理本应该根据对式样，对客户，对环境，对进度等等的了解来明确以上问题的答案的，这些问题自己做不到心中有数，了解来龙去脉，只是简单的作一个传声筒，把客户的声音告诉团队成员，再把团队成员的声音告诉客户的话，那么你最多只是一个合格的翻译，不是一个合格的项目经理。甚至只是一个傀儡，这才是我所担心的。我所经历过的一些项目也证实了我的担心并不是多余的。这样的“传声筒项目经理并不鲜见”。

 

     比如，我听我的朋友小S说的几个案例（据说是一位从国企中跳槽过来的项目经理）

 

     案例1：

 

     项目经理给他安排工作，不说是给他安排的，就说：小S，你看看这个，你会做么？

 

     小S说：我不会。

 

     项目经理说：这个可简单了，你看看啊

 

     小S说：好，然后看了几眼

 

     项目经理说：简单吧

 

     小S无语，没弄明白项目经理是什么意思。继续忙自己的手头工作。

 

     然后过了三天，项目经理问小S：我给你的活干完了么？

 

     小S说：你给我什么活了？

 

     项目经理说：就三天前那个啊，你还说简单来着。

 

     小S:!@#$%^&*

 

     案例2：

     该名项目经理一般都是什么都不考虑，直接把工作向下传。

 

     这一次，小S想，反正最终还是要我做的，所以就直接把项目的体制图作了一份。

 

     然后该名项目经理这一次不知道怎么的，心情比较好，也作了一份。

 

     后来两份体制图都被老大看到了，老大说小S做得比较好，就用小S的吧。

 

     然后项目经理就不高兴了，虽然没有表现出来，但是后来多方为难小S，总要抓到小S一些问题才算罢休。

 

     我们不说后来的结果，就说项目经理不明确每个人的作业，导致重复工作，项目在一定程度上的混乱是可以预期的了。

 

     案例3：

     有一个作业报告，本来应该是项目经理做的，该名项目经理让小S帮忙做一下

 

     小S做的时候有一些事情需要跟项目经理确认，比如项目每一项都花了什么钱了。

 

     小S说：老大，跟你确认几个数字？

 

     项目经理说：恩，你等下。然后过一会儿喊小S，说：你看我上网买的这个小锅好看不好看。

 

     小S说：好看。然后说：老大，你帮我看看报销失败的这笔钱。。。。。

 

     项目经理说：等下。然后继续上网看他的小锅。

 

     再过半天，项目经理锅买完了。小S看项目经理在上网，好像没啥事情了。就过去问：老大，咱们看看这笔钱啊？

 

     项目经理说：哎呀，不好意思不好意思阿，等我把这个新闻看完的。

 

     然后项目经理慢慢的看新闻，不时的发表一下评论：你说现在这个社会阿，有没有天理了，什么什么的。

 

     小S听项目经理说完了，说：那个，要不咱们先看看这笔钱？

 

     然后项目经理看了一眼，一串儿人名。随便看了一下，问：这是什么？

 

     小S说：那是某某Team的加班费用。

 

     项目经理看完了说：凭什么XXX加了这么多的班，我怎么没看见他加班了？

 

     小S说：这个是上个月的。要不你忙的话，你就帮忙看一下报销失败的这几笔就好了。

 

     项目经理说：你赶紧做个流程，怎么能让他们随便填写加班费呢？赶紧全员发个邮件，让大家不要随便加班

 

     小S说：这个流程我早就作了，大概3个月前就生效了，当时你也看过的。而且这个是上个月的钱，他们跟你申请的时候，你同意过的。

 

     项目经理说：哦，那行。然后回去继续上网。

 

     小S想要问的问题一个字也没有解决。这一件事情，小S确认了3天。后来老大催项目经理说：你们Team那个报销的报告怎么还没整理好。

 

     然后项目经理找小S说：那个报销的报告交给你这么多天了，你怎么还没做好交给我。

 

     小S说：我早就做好了，发给你等你确认呢。

 

     项目经理说：哦，那好，我确认完了，你继续处理吧。

 

     一件事情做完了。

 

     项目经理有权利指派你的团队成员帮助项目经理完成各项工作，但是项目经理必须给予明确的指示，必要的指导，并随时跟踪作业状况。

一，极限编程

极限编程(ExtremeProgramming（XP)是一套完整的涉及软件开发各个方面的开发观念，这里截取编码相关部分。

 

1.组队编程（PairProgramming）

 

XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。——这种工作方式极大地提高了工作强度和工作效率。

 

    在实际工作中，你的老板可能不会同意你这么干，我们可以考虑一个变通的实现方法。在项目中，总会存在大量类似的工作，将这个工作安排给至少两个人以上共同承担，这些人为一组，在复核的时候互换角色。同样可以在一定程度上达到目的。这样做复核人员对自己所要复核的内容比较熟悉，可以保证工作质量与效率，同时每一项任务至少有两个人以上对其熟悉，这样在出现人员生病，离职等等调整的时候，项目经理不会因为某一位团队成员的变动，而对整个项目造成难以平衡的影响。

 

项目开发中，每个人会不断地更换合作编程的伙伴。因此，PairProgramming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个项目、开发队伍和公司。项目经理在做好项目的同时，已有责任与义务，为公司培养优秀的人才。而更多优秀的人才，会使你的工作变得轻松。

 

2．测试驱动开发

反馈是XP的四个基本的价值观之一——在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等；与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在往代码库中放程序（CheckIn）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。这样，测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充足的反馈。

 

3．重整和优化(Refactoring)

XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重整和优化（Refactoring）。这个名字最早出现在MartinFowler写的《Refactoring:ImprovingtheDesignofExistingCode》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。

 

1．  频繁地整合，集体拥有代码（CollectiveCodeOwnership），编程规范

    XP开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和PairProgramming以外，XP要求每个人的代码都要遵守编程规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查其他人写的代码。

 

频繁地整合（Integration）

在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为使用时间短，客户们心里并没有多少把握。

 

为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USERSTORY（每次整合一个新的USERSTORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。

 

集体拥有代码（CollectiveCodeOwnership）

在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。

为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。）

 

编程规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现CollectiveCodeOwnership的重要前提之一。