关于 XP 中的设计 - 是百川归海， 还是歧路悲歌

xp中不需要引入竞争，因为竞争实际上非常非常多的存在于xp的实施中。
在PP中会有竞争，这一点大家都会明白。而实际上由于必须交换PP的伙伴，这个竞争将是非常非常的明显而激烈的。
而由于代码的集体所有，竞争将被无遮掩的暴露于所有人的视野中。
同时由于实施了持续集成，紧张的过程中经常性的会有竞争的结果在大家互相的交流中被传递。
同时由于大家采取的任务分配完全是自愿的，会使竞争的因素在最开始就已经存在。
实际上xp的组织中竞争是非常激烈的，人们的劳动也是强度非常大的。实际上实施40小时工作制在xp中是最基本的保障。
我曾经试验过一个组织，结论是一个人一天最大的精力只能维持3个小时。所以我基本上都是白天工作，半天重构和编码以及协调。即使如此，效率依然非常的高。又加上我使用了FDD的工作分工方式，基本上就不存在任何的管理死角。

而我认为系统隐喻是一个最让人容易忽略的部分，也是xp的那些大家介绍最少的部分。我认为这也是xp今后最可能会加强的一个部分。

而电路图的例子我认为可以最好的解释为什么软件设计和其他的传统设计那么不同。即便我们由于要设计一个复杂的庞大的电路，我们会存在一个概要的不牵涉细节的设计思路。但是这个设计思路，实际上依然比我们的软件的设计思路具体而现实的多，你可以依赖那个梗概的电路设计思路，去设想各个部分的负载和连同，以及运行时的种种大致情况。而软件的由于存在静态的结构和动态的结构，造成你的对于软件的静态的设计，和系统运行的动态形态，非常难于统一（实际上这也是我们这些老家伙比现在这些年轻程序员最强的一个方面：当我们看到一段代码的时候比仅仅看到了是不是代码清晰，我们还会同时设想出这些代码在内存中的运行方式。而这一点需要对系统的底层十分的熟悉，知道非常多的细节。而由于现在的软件经常性的要考虑多种平台和多种的运行环境，这样的能力已经变得不可能）。从这一点上来说，软件的设计更加需要不断的进行验证。
实际上从设计的正确性上来说，尽早的编码是必须的。

同时我还要告诫大家一点，在TDD的过程中不要过分。
不要把所有的东西都去单元测试，比如简单的set和get。而且单元测试也要有过于复杂，以至于还需要专门的对于单元测试的单元测试加以保证。
当然这种情况出现的不多，但是我想随着TDD实施的普遍，会有一些人钻这个牛角尖的。

从电路图的比喻来讲,可能不太恰当.
软件工程是一门新的学科,一直从其他地方吸收方法学的经验,比如电子工程和建筑工程,但是我觉得其中却有很大差别,因为他们对应于物理世界(受电学和力学的约束),而软件是软的,因为实际上是人-社会关系的一种抽象和映射,而这些社会关系的变动比物理关系的变动要复杂和频繁多了,所一软件需求和设计本质上和硬件,建筑设计是不同的.不过也许问题域的特性决定了我们的过程方法，比如CMM为基础的还是XP的。
一个软件项目的更像是一次旅途，XP里用开车来作比喻。我觉得设计和过程就像是一张地图和行程安排，当你对地形比较了解就用一张详细些的地图，不然就简单些的。但有一张正确的地图总不会是坏事。
CMM/CMMI这些东西，来自于SEI和DOD以及Watts.Humprey,IBM很多借鉴于制造业和硬件开发的经验。用来练练功是可以的，打仗却不一定行。不过最重要的是裁减和灵活运用.

昨天参加RUP需求分析会议，更加体会到了RUP与XP对人要求的不同。RUP要求需求要做的尽量深入、全面，分析、设计也是一样，目的是减少变更的成本，因为每个需求的变化，都必须重新经历用例－分析－设计－编码－测试这样的一大圈，这不仅要求分析人员具备多年的开发经验，更要有相当的社会经验（当然，对于纯粹的设计人员，这一点要求不是特别突出），缺少社会经验的人，编程能力再强，做出的需求也是很脆弱的。
而XP对人的要求则完全不同，XP强调纪律，没有自律性的人一定无法融合到XP的团队中，同时，XP成员也必须具备极强的责任心。当然，技术方面是肯定还是有最低要求的，一个从来没写过超过100行程序的人，不管什么团队恐怕都会拒绝。XP对成员技术方面的要求比RUP的编码人员要高一些，但是远比RUP的分析设计人员低的多。

同意楼上的意见。

我谈谈个人对XP的应用的一些看法吧（我的水平只能谈应用）。
   我觉得XP带给我的冲击是非常大的，从我大学毕业工作起差不多就一直受到RUP的影响（因为公司一直实施到过了CMM2），但是总是发现一些问题感觉无法解决，感觉会议总是无穷的多，感觉总是走着一样又一样的形式。XP给我解决了许多的困惑，不过自然，也给我带来了许多的困惑。
   首先，就是结队编程，我不清楚这需要在一个怎样的环境下才可以得到实施，难道有公司运行？而且就我对现在大多数程序员的了解，工作懒散的比比皆是，我实在怀疑这一项是否成功。
   其次，对于持续集成中的大量且非预留的check in/out操作，我也感到怀疑，我有差不多四年的SCM使用经验，也担任过QA的负责人，因为非预留的check out所带来的merge而引起的恐怖后果，我是领略过的，我非常怀疑这种实践的有效性。
   最后，就是代码＝设计这种理念了，至今我对它仍持有一丝怀疑的态度（不过也许正如dlee所讲，我的功力还不够，也没有完全领略XP的充分优势吧）

结队编程的经历我有过，不过不是在实施 xp 。 而是刚工作时， 没有什么软件工程方法时的做法。当时我们负责的一个通信模块很重要， 而项目组都是刚毕业的学生， 领导为求保险， 由我和另一个同事共同负责。

我的体会是， 结队编程感觉还是好的， 效率也不低， 而且出现问题之后由于可以有人商量， 比较容易解决， 不会卡住， 可以舒缓压力。 因为有一定的冗于，附带的效果是降低了风险。 结队编程怎么避免懒汉产生？ 谁愿意和懒汉结队呢？

不过，全项目的结队编程我是没有经验。

代码就是设计， 是对传统观念一种反叛。 当然要激进一点才会起到效果。 这是我的理解。

我们团队在新项目中采用结队编程的方式，感觉结队编程的效率比单人编程的效率高，就是2>1+1,我想实践过结队编程的都会认同这个观点，在队结队编程之前，我和我的同事和你一样都有过怀疑的态度，有点抵触的心理。但采用过后大家都认为结队编程的效率是相当高的。个人认为结队编程适用了多人做同一个项目。结队编程的其他好处，比如团队的沟通交流（代码的质量当然高了），知识分享（每个人在开发的时候都会有自己的独门绝技，你坐在他旁边你可以学习哦），项目的熟悉（经理们最喜欢这样，不会再有项目由于当事人不在而没人接的了手）这些就不用说了。

对于持续集成，我觉得只要在项目的开发过程别忘了给代码打好分支tag，在分支上开发，合并的时候应该不会有什么大的问题。

      首先感谢楼上的好经验，我如果有机会，我想这么尝试一次。我上面的话只是从公司角度，难道公司愿意这样做么？或者允许这样做么？（纯粹是一种现实的探讨，没有钻牛角尖的含义）。
    其次，对于SCM，我了解还算有些的。我们一般在如下情况用到分支，比如说，我们有一个1.0的版本，同时，我们需要在此基础上开发1.2的版本，当然，我们同时又需要根据客户的某些要求定制1.0版本的内容（两个版本间有关联，但是也有区别，或者这么说，定制的内容最终要加入到1.2中，所以并不需要使用两个不同的库），因为1.2版本所做的没有经过系统测试，所以不能给客户发布，这个时候，我们用到了分支。并且，分支的合并是相当繁琐和容易出错的，我不清楚楼上所谓的分支是怎么样的分支？如果在普通的编码过程中就使用这样的分支是相当可怕的。反正就我个人经验来说，对那些使用配置管理工具或者对配置管理不熟悉的团队以及开发人员使用非预留的check in/out操作是一个灾难。我曾经差不多用了三个月的时间强制纠正团队开发人员的这个习惯，才帮助将配置管理真正使用上，使用好。

xp对于SCM是一个严峻的考验，这一点凤舞凰扬考虑的确实是对的。但是持续集成，以及由其所带来的重构和代码公有，给开发过程带来的效益要远远大于在SCM上的付出。这个方面应该听听charles和pation的说明，他们都是有这个方面的丰富的经验的。
而pp这个问题其实往往引起管理层的猜疑，认为是浪费人力资源。当然如果他们没有实际的操作过PP，他们猜疑是很正常的。但是一旦试验过几次以后，管理层比技术人员会更加喜欢这个做法。关键就是说服管理层开展一些这样的试验。
而实际上目前至少我在comp.object看到过多次了，xp已经成为一种广告的手段，客户对xp的要求强烈往往在促使开发者不得不去xp。我不知道这样的后果到底会好还是坏。至少使我产生了某种的担心。实际上在敏捷已经从一种新的思路变成一种主流的开发方法后（在一些大学已经把xp作为一种开发方法课程进行教学,一些研究机构比如SEI的一些人在xp等敏捷方法上也投入了很多的热情），我们反倒应该从以前的对xp的热情中冷静下来更加关注这个方法的一些有待加强的部分。
在我看来xp的隐喻可能是目前最为模糊的一个实践，也是经常被人误解的一个部分。这个关系到系统的整体的把握和设计，这个方面应该得到加强。而在细节上的设计，我认为xp是目前最实际也是最有效的。但是单纯的依赖细节的最优，并不能代表整体的最优。重构也未必可以解决一切的问题，同时也不是任何时候重构都是最好的选择。而快速进入编码，往往又让一些人误解为xp没有前期的设计准备，从而否认xp的设计理念。实际上xp的系统隐喻就是系统的整体的设计主题，就是Architecture。而这个隐喻的来源绝对不是某些高手的一时的灵感，更多的还是来自项目开始之前的其他项目的结论和对行业的研究。而xp由于信息的高度透明，知识的集体共享，代码的共同所有，给知识的积累带来了良好的素材基础。没有这个积累的过程，单独的xp效果会受到影响，或者说长期的使用xp效益会随着时间逐步的更显著的提高。实际上xp也是有前置的设计的，只不过这个前置不是项目的前期，而是在项目开始之前就已经开始了。
xp这样紧密地团队，不仅仅是对一个项目有好处，而是对一个相当长的时间的所有开发都有好处。这个积累的过程不是很缓慢的，而是很快速和明显的。