我所在的项目有两组人同时在为一个问题寻找不同的解决方案。一开始我担心这两组人会各自为政，最后会让事情陷入僵局，白费时间。但最终却取得良好的效果，这有点出乎意料。切入点越多，意味着解决问题方式的多样化，比起单一的工作方式，我们可以从中学到更多。多样化的工作方式可以减少思维上的交叉影响。
最近，我开始对两组人的工作结果进行汇总，但要把他们各种不同的想法都保留下来确实是件让人头疼的事情。我发现我总是试图在发散性思维和聚合性思维之间找到一个平衡点。这两种思维方式各有长处，而我尝试着让多样化工作方式的发散性特质最大化。
人们推崇团队合作，个人行为所能取得的成效容易被忽视。所以到最后，协同工作的方式总是占上风。一般我们会把这视为团队协作与个人行为之间的博弈，不过也可以引申到小团队与大团队。
为什么这个问题值得深思？
在一起工作的人容易往相同的方向思考，这在某些情况下很管用，比如在取得一致性结论的时候。但要在一组人中间进行头脑风暴，群体思考就是一种灾难。当然，你也可以尝试在小组里消除发散性思考，但这样做其实很难，它要求小组具备一定的智慧和技能来打开一个更开阔的视野。
与之对比鲜明的是独立的工作方式，它更倾向于发散性思考。可能是因为每个人不知道其他人在做什么，所以无法在他们之间建立起联系。独立得越久，发散得就越明显。
以上提到的各种倾向性，解释了为什么把一群人关到房间里进行头脑风暴经常是达不到预期效果的，因为大多数想法走的是同一条主线。
结对
我一直觉得用群体工作的方式应对分散的项目是有风险的。在过去的五年里，我时不时地听到有人称赞，甚至要求在开发中强制执行结对编程。对有些人来说，结对编程已经成为事实上的标准。更有甚者，有人声称他们只用结对编程进行开发。从这些人嘴里听到的都是对结对编程的溢美之词，几乎没有提到任何缺点。
对此我反而有所迟疑。我坚信事情的对错自有其道理。Alistair Cockbum和Laurie Williams一起写了一篇题为《结对编程的投入和产出》的文章，这篇文章不仅没有劝人们避免使用结对编程，反而极力暗示结对编程应该成为一种强制执行的标准。当然，文章并没有直白地说出这个观点。但文章的概要部分对结对编程的不足只字不提，列的都是它的好处，对此我应该做何感想？
人们声称结对编程的好处：
- 更少的缺陷
- 更多的创新
- 更好的设计
- 更融洽的团队合作
- 知识共享
- 更高的反馈接受度
接下来让我们来说说这些好处。
毫无疑问，人们在一起工作会促进知识的共享，越是紧密的合作，对反馈的接受度越高。但我们不要忘了还有其它很多种方式也可以达到同样的效果。
更好的设计和创新
两个脑袋总比一个好使，我们很容易掉入这样的陷阱。在之前的那篇文章里，作者通过所谓的科学调查得出一个结论:
结对编程的人们不仅能交付更高质量的代码，而且总能用更少的代码完成相同的功能，这意味着结对能带来更好的代码设计。
事实上，代码编译器可以在不改变设计的情况下把任何一段代码进行优化从而减少行数，所以不能用代码行数的多少来衡量代码的质量。设计上的创新是没办法被量化的，设计的好坏基本上要从品质方面对其进行评估。
如果有人坚持认为两个人一起干活比一个人好，我可以举很多相反的例子证明一个人比两个人要好，或者说两个人单独干比在一起干好。如果你一定要让人们在一起工作，要注意合作的方式是否会对创新能力产生不良的影响。
群体思考
群体思考容易掉入先入为主的陷阱，思考会形成定势，发散性思考会被抑制。个体独立工作也是一样，思考最后会聚焦到一个点上，阻碍新想法的产生。
假设你在跟一个团队合作，建造一条通向山顶的小路，这事之前从来没有人做过。如果在每一个关键的连接点上，你都按照先给出想法的人的主意去做，那么这跟一个人按照他先入为主的想法行动有什么两样！
害怕表达
个人担心自己的言行会危害到集体，从而选择保持沉默。工作上总会有一些无形的力量让人们不便于表达，比如那些有家庭负担的人，他们选择沉默可能只是为了保住工作，而这些你都无从知晓。
观点分享
人们在一起工作得越久，观点越容易发生同化。当有挑战出现，他们会提出相似的应对方案，因为他们受相同的思维定势影响。创新来源于人们能够从不同的角度看待问题。建造道路的团队越是往上建，他们之间形成了越多的共识。这意味着个体的观点容易被同化，因为他们的经历都是一样的。
打个比方，如果这个团队不幸碰到了很深的水流，最后决定借助木头穿过去，那么如果他们再次碰到水流，他们同样会想到要借助木头。但如果他们去试探一下水流的深度，可能发现其实水浅到可以直接走过去。
创造性取决于解决问题的人是怎么想的，而不是解决问题的人有多少个。
减少缺陷
之前的文章提到，通过结对编程可以让缺陷的数量减少15%。但是他们的结论是基于对寥寥的20个参与者进行实验得出的，而这20个人之前对编程并不熟练。这种实验不具备科学说服力，他们这么说只不过是想让更多人接受他们的观点而已。
如果把这个结论应用到那些编程老手身上，跟要禁止医生单独进行手术差不多，因为医学院的学生们通过结对的方式可以做得更好。
说实话，对于结对编程是否能够减少缺陷的争论，跟结对编程是否能够提升开发效能的争论一样，都是个笑话。
缺陷跟创新一样，都是无法被量化的。之前的实验把测试用例跟缺陷挂钩，但实际上测试用例跟缺陷之间并没有必然联系。测试用例可以用来衡量软件质量是否符合某种规范，但在规范之外，因为缺少沟通仍然会产生很多缺陷。当然，人们并不总是遵循规范，比如之前的那个实验。如果不遵循规范，沿着错误的方向不可能得到正确的结果。根据我的经验，大部分缺陷都是因此而产生的。
在关于缺陷的争论背后，是缺陷反馈的及时性问题，之前的实验似乎一直在暗示这个。从别人那里快速得到反馈是结对编程的好处之一。我们之所以要结对编程，就是希望从对方那里得到反馈，或者寻求对方的帮助。
结对编程能立即从对方那里取得反馈。即时的反馈有一定用处，但其实反馈得是否及时更为重要。举个简单的例子，如果现在跟你提及一年前犯的一个错，就毫无意义。
及时并不一定要求是即时的，而且即时的反馈可能存在以下问题：
给反馈的人可能在说出想法之前没有经过仔细的思考。如果基于这样的反馈草草行动，会降低开发效率。所以在他人进行检视时，要给他们足够的空间。
检视者可能会为之前说出的不成熟的想法感到后悔。
简单的错误容易被检视出来，但如果检视者本身也是被检视的对象，那么他们给出的反馈会有局限性。
被检视的人可能不知道如何对反馈做出适当的响应。就算他们再淡定，如果不懂得区分哪些是有益哪些是有害的反馈，他们最后都会抓狂的。
毫无疑问，如果你认为反馈的价值只是在于它的即时性，那么你就错了。反馈的价值在于它反映的是检视者与被检视者之间发散思维的碰撞，在我看来，这比是否即时更重要。
我无法从跟我差不多的人那里学到太多，除非我能跳出自己的思维定势。有价值的反馈来自思考方式跟我不一样的人。
降低士气
协同工作说到底就是团队协作。但如果强制要求人们结对工作，有可能会形成低估个人贡献的不良风气。就算只要求在写代码时才需要结对，也仍然存在这个问题。
所有代码被要求在结对的情况下编写，这似乎暗示着个人无法独立写出有价值的代码。这样导致的直接后果就是个人开始怀疑自己的能力，然后这种怀疑就会在以后的工作中或者生活的其它领域变成事实。
人们把自信建立在对他人依赖的基础上，而一旦这些外在的依赖没有了，他们也会跟着垮掉。试想当你想换一份工作，或者因为某些原因你决定不再使用结对编程。
再说了，为什么单独一个人就写不好代码，换成两个人就可以？两个一起开车的人睡着了仍然会引发事故。自信过头的两个人不会比一个人更高效。
对症下药
强制结对编程跟强制单独工作都是愚蠢的行为。人们知道什么时候该与其他人一起协作才是有意义的。他们可能不会一直使用结对的方式，但他们知道什么时候该使用它。
结对是事关效率的。一开始我们就要搞清楚自己想要什么，看看有没有其它可替代的方案，而不是一味盲目地被牵着鼻子走。
结对也许可以帮你应对缺陷，但记住，你真正需要的是反馈。测试，代码检视，代码分析，用户响应都可以帮你取得反馈。
说到反馈，如果编写的代码不经过检视，那它跟结对编程并不具有可比性。要比较，就要把编码跟代码检视一起作比较。当然，我并不是说就不能让个人单独工作了。如果你的团队在协作和沟通上存在问题，结对并不是唯一的解决办法，还可以试试知识分享等手段。
如果你写的代码对创造性没有太多要求，那就没必要结对。比如说你要修改报告的格式，如果不需要代码检视，那结对就是在浪费时间。
但如果对创造性有要求，那么记住，结对也会破坏创造性。创造性跟人们在想什么有关系，跟有多少人在想没有关系。一个持中立态度的人可以从多个角度看待问题，比起两个相互认同的人，更具有创造性。
你最好教人们如何避开创意的陷阱，而不是鼓吹践行结对方法能给创意的产生带来多大好处。比如：
- 情商低下的人结成对子，会减小创意产生的可能性。
- 效率低下会传染
- 群体思考会抑制发散的点子的产生
- 创意的产生需要知道何时该展开视野，何时该深究
- 识别一个人的偏见可以帮助他发现新的观点
如果你觉得创意是势在必行的，可以让更多的人参与进来一起工作。这些人需要深谙创意的陷阱，避免踩坑。如果你真要这么做，最好先想想该采取什么方式。比如：
- 可以结对。
- 团队可以由三个及以上的人组成
- 可以让其中一个人些代码，另外一个检视
- 可以让两个人各自工作，然后汇总工作成果
- 可以让两个结对的小组各自工作，然候汇总工作结果
- 可以引入第三方到以上任意一个场景中
你应该还能列出其它选项。说到底，最关键的是发散思维，要做到这点，方法很多。如果真要挑出一种方法，还要看使用它的人是怎么想的。如果用它的人不知道为什么要这么做，那么任何一种方法都不会产生效果。
扫一扫
1078
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
