体验结对编程

体验结对编程一周多的时间，遇到诸多问题和大家分享一下。
两名程序员，
一名为编程老手，有丰富的开发经验经常可以提供一些非常好的想法，只是对业务不够熟悉。
另一个是个菜鸟，但进入团队时间较早对业务也相对熟悉。

两人形成互补型结对组。
故事：
由于老手（A）并不熟悉业务，而且时间箱规定时间紧迫，第一周由菜鸟程序员（B）进行主要的开发工作，
AB两人在会议室简单沟通需求和场景后，进入开发阶段。B希望可以一边开发一边让A尽快熟悉业务以及相关API，
B（菜鸟）在开发时遇到一些关键需求时总要停下来和A程序员交流，包括使用到以前定义好的类和业务上下文。
有时两人会因为过去的代码不够简洁而讨论新的方案。
直到周六的下午（时间箱规定周六交付一个可以使用的版本），程序员B突然拍着自己的脑门大叫一声：晕~！！忘了一个需求。而且是关键性需求。
这导致近3天的工作付诸东流。需要重新考虑。
周六下午。程序员B很是郁闷。在会议室里苦苦思索为什么会出现遗漏。。。。。。

原因分析：由于老手A并不熟悉业务上下文，不能参与前期准备。只有程序员B知道下一步应该做什么。而B在开发中经常与A交流关于业务上的事情，导致编程思路不流畅。经常需要分神去解释和讨论，经过一段时间之后又回到自己的代码上。
开发过程由原来的：测试——开发——重构——测试   
变成了：测试——开发——讲解——讨论——开发——重构——测试  两次开发之间经历了漫长的讨论与讲解。导致菜鸟程序员精力不够，甚至出现致命的遗留问题。

之后两个人在会议室里分析了问题的原因，由于此时已经经过了一周的结对开发，程序员A也对需求渐渐明朗起来。
此时两人都意识到这样的开发过程过于缓慢。原计划2天完成的任务干了3天还遗漏需求。经过商讨决定下周实行新办法：两人一起站在白板前探讨需求，程序员A不明确的地方由B在这个时候进行说明，以及两个人的讨论都在这个时间进行，开发回归  测试——开发——重构——测试 

评论

5 楼 魔力猫咪 2008-06-07  

慢慢摸索吧。人件里有一句话说得好，当你CMM已经到3的时候，你要做的就是接一个能让你CMM到2的项目，什么时候你这个项目也到3了，那么就是你的项目开发水平获得了极大提高。
尝试新技术的时候遇到一些混乱是正常的。老方法转向新方法的时候，首先是混乱，然后才是看到改进的效果。所以在太急的项目上用新技术新方法要小心。弄不好会起反效果。

4 楼 yh_private 2008-06-06  

非常感谢猫咪 的关注，你所说的问题正是我们下周准备改进的关键问题。
在开始编码前讨论部分需求，使程序员AB都充分了解需求，第一周我们没有故事没有卡片，完全是一个人在开发中途又加了很讨论的时间，分散了很多精力。可能是过多了，我并不是说要把所有问题全部都在会议室里讨论清楚，只是需求和过去的API，我希望可以在编码时B不需要向A讲述 本次编码内容以外的事情。保证精力集中在这次的代码上，可以是质量上的讨论，或者结构上的讨论，但不要过去API的讲解和过去为什么要这么做之类的事情。
我们会在下周加强故事卡片。

第一次很多事情都需要摸索，虽然书中提供了很多。。

3 楼 魔力猫咪 2008-06-06  

不过国内的结对和敏捷还是很少的，你们能勇于尝试这很好。推荐《结对编程技术》一书，你们按照上面的实践改进你们的结对，我觉得能够大大改善你们的效率。最后，欢迎到http://pair.group.iteye.com/。这是我开的一个结对编程圈子。

2 楼 魔力猫咪 2008-06-06  

敏捷开发、迭代、结对这些技术都是很不错的开发方式。不过我们要注意的是，你在采用这些方法前，是否已经做好了准备？我觉得如果团队连瀑布也不能保证的话，可以先用瀑布模型，在瀑布模型里尝试结对，然后再去尝试敏捷开发。我觉得你们这次的问题在于没学会爬就开始跑了，跌倒时意料之中的。需求应该是明确的说明书（敏捷里用一个个故事卡片），而不是只装在某个人的脑袋里，开始编码前应该有设计。如果公司举办个聚会或者你心里想着和女朋友看电影，是否也会把需求丢掉呢？

1 楼 魔力猫咪 2008-06-06  

虽然结对的初期因为磨合问题造成速度比两个人单独速度要低，但是代码的质量是可以保证的。虽然老程序员不熟悉业务，但是他在开发中可以避免新手编写出质量低劣的代码，而老手则通过结对可以比单独看需求能更快进入角色。我觉得你们这次写的代码的质量绝对比任何一个人单独写要好。无论是效率还是缺陷，应该都比你们单独低。
至于丢失需求，我觉得你们不能怪交流。你们没有需求的说明书吗？敏捷也有故事卡片的。你不能只用脑袋记录，那样丢了也不新鲜。还有，设计应该在开始编码前完成吧？如果你们在开始编码前完成设计，我觉得需求是不会丢的。敏捷不要求一次把所有的东西设计完，但是不是不要设计直接开干。
我觉得你们的问题在于没有严格遵循开发方式。敏捷是把一个大瀑布变成无数小瀑布，不是彻底不要。你们应该是把交流贯彻分析需求、建模、开发测试、编码、测试这所有过程。当迭代完成后再和用户交流，开始第二次迭代。
还有，在最后，如果你们把交流只局限于开发前，那么就不是结对了。很可惜，你们因为一个愚蠢的原因放弃了结对开发。其实你们应该再仔细看一下你们结对编写的代码，再和自己以前单独的代码好好比一比，除去那个被你们忘掉的需求，是不是比你们单独写要好得多呢？