困惑的结对编程？

how?
至少这个时候PP是不合适的，但是可以用指导的方式。注意这个和PP是有很大区别的，PP是平等，而这个时候需要划出一定的层级来适应人性，使得这两位仁兄能够一起工作。

所以，就像这里展现的，根本的问题是合作，如果一个团队是相互合作的团队，根本就不需要固定的PP方式存在，这种合作会使得问题发生的时候自发产生一种组织形式来适应解决问题的方法。
PP是一个强制性的平等关系，和乌托邦没什么两样。都很美丽，在某些瞬间都会有实现了的场景，但是仅限于瞬间。

我2P都没有试过，你们就开始4P了， 真是先进，爽！

pair programming有很多种不同的风格，其中至少有一种是专门供资深开发者辅导新手的。
所谓指导，如果你不能立即、持续地看到效果，那么效果就会大打折扣。如果是要辅导新手，我更认为应该pair，采用“ball and wall”风格。

这一点我也很有体会。不过遇到问题我还是会现debug，不过debug确实比以前少了。因为有开始的单元测试。需要花太多时间的话，就想同事请教。经常碰到"旁观者清"的情况。

本身我还没有体验过pp编程。很希望有机会试试。

其实，有时候水平相同的两个程序员的确很难找到，但作为一间大公司，如果你真想要这样的程序员出现的话，我相信你会找到的，即使真的在市面上找不到的话，你也是可以自己花一点代价培养出一两队这样的程序员。如果真能培养出这样的程序员，相比你花的这一点代价来说，他们所能给公司带来的价值是巨大的。

看到这么多人对此贴这么感兴趣，那么就让它接着下去吧。你也可以到此http://huangzh.iteye.com来阅读或发表更多有关敏捷开发（结对编程）技术。



如果你不是一位经理，但是根据你自己的所见所闻，却又想在你们的公司试试结对编程技术，你应该怎么办呢？这里建议你充当一名传教士，在你的同事中先对一种偶然地且不经意的实践来开始你的传教。做为一门职业，程序员的工作负担是相当重的--------你本人可能也是如此。要想说服同事们广泛接受一种新事物，你首先要有一个坚定的信念，因为你肯定不想因此而增加自己的工作负担，也肯定不希望为了这种“业余活动”而让自己加班加点。因此，建议你先替自己准备一个风险转移策略。从小处入手，在试图说服别人之前先要说服自己。
你得先从自己的团队里找出几个看起来对新事物特别感兴趣的人，把这些人当作候的尝试者,因为这些人是不会容忍那些半生不熟悉的东西。首先，你可以试首在午餐或工休的时间与这些人非正式地讨论一下结对编程技术。不过你一定要有的放矢地准备一份个人接触方案，一份专为某个候选尝试者而准备的关于结对编程技术将如何在工作上给他们带来好处。因为尝试者衡量这些好处的标准之一就是该项创新能给他节省多少时间和精力。

很多软件公司都拥有自己的知识库，有的还有自己的专门培训部门，有的甚至还花大价钱来聘请一些专家做技术培训（就像我去年12月份底到eshore里实习所见的一样）。但是它们在不久的将来会发现其效果并不是太理想，培训完之后，开发人员就要面临实际的项目，但他们还会是一片茫然。如果让他们与有经验的同事一起结对的话，则是在实际的项目中学习，而且具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起结对，你的经验和能力将可以得到空前快速的提高。

再谈结对编程的障碍-----沟通

 

沟通问题是一个项目成功最重要的因素之一。一个项目可能并没有什么正式的软件过程，但是只要团队成员能够进行有效的沟通，项目成功的可能性就很大，但是如果项目中缺乏有效的沟通渠道，再优秀与严谨的软件过程也没有用。优秀的软件方法学，总是会在沟通渠道的建立，推动在有效沟通上花费大量的精力，将会使项目获得更大的成功。我们分析RUP、XP等方法学，都会看到很多这样的实践。沟通对一个项目而言是重要的，对一个软件组织而言就更重要了。从长期来看，内部能够进行有效沟通的组织能够得到很好的发展，但是反过来，内部沟通不畅的组织将会出现很多的问题。

 

在软件开发过程存在的一个很大的问题就是沟通不畅的问题。事实上，这个问题并不仅仅在一个开发过程中存在，在整个软件组织内都将长期的存在，并成为阻碍软件组织发展的一大障碍。这样的说法可能过于理论化，但是我们只要想想，如果在的项目中，一个主力程序员离开的话，是否会给项目，甚至组织带来重大的影响，就能够理解这段话的含义了。造成这种现象的主要问题是程序是分散在各个程序员手中的，各个代码块就像是程序员们的私有财产一样，神圣不可侵犯。

<o:p>待续.........</o:p>

<o:p>

---

Blog:http://huangzh.iteye.com

E-Mail:huangzh@gsta.com,hzhui@126.com

</o:p>

楼上的,转贴最好说明