周末去听Hadoop大会，看见的都是玩儿开源项目的好手，突然就想起敏捷了。敏捷强调沟通,尤其是面对面的沟通，并且有每日例（立）会，iteration plan meeting, 还有retrospect meeting。突然就在想，开源项目常常聚集来自不同国家的人，他们很多时候根本互相不认识，两个不同公司不同时区不同国家的人咋面对面沟通啊？咋聚齐开会啊？人家平时沟通全靠mail, 但是他们做大项目也能成功，人家是怎么做到的？我们搞敏捷，这么神奇的武器，开发过程仍然捉襟见肘，还不如开源项目有序，为什么？
猜想世界范围的开源项目沟通成本高，所以他们必须千方百计降低沟通需要，通过一些手段可以做到，比如
一，清晰，自然的架构。
二，高质量代码，代码像文档一样流畅。
三，模块化，面向接口。
四，务实的文档。
五，自动化测试。
……
有些沟通是必然免不了的，比如需求的沟通，我觉得最复杂的需求沟通往往起因于程序员不了解行业领域知识，而开源项目往往是工具类，框架类的项目，绝大多数不涉及特定行业领域知识，了解“domain”的门槛不高，所以需求方面的沟通要求天生就相对较低。我们平时工作的很多沟通来自于技术问题的沟通，我绝不怀疑，技术手段能够降低沟通技术问题的需求，而一个不那么倚重程序员沟通技术问题就能把技术做好的项目，才说明技术风险低，技术好。一些事情，比如技术选型，的确需要Involve比较多的人讨论。但是当技术选型确定，模块划分清楚，接口清晰之后，技术沟通的需求就应该比较低了。有的时候技术上会遇到一些dilemma,这样写程序不好，那样写也不对，有时候确实是因为技术本来也没有完美的解决方案，总要trade off掉一些事情。但更多时候是因为架构不好，才引发了随后的种种麻烦。程序员之间扯皮什么事情该谁做，是不是因为模块化做得不好？“xx,你给我讲讲某块代码实现吧，我懒得看了”，是程序员懒还是程序实在是一团浆糊，惨不忍睹？同一个问题A给B解答一边，给C解答一边，后面还有E,F,G….是不是早该写好文档？
coding的工作不神圣，但确实不同的人做出的设计可以大相径庭，同一个功能背后的代码也可以天差地远。做产品不是靠人堆出来的，三个臭皮匠顶不了一个诸葛亮，三个臭皮匠还不如一个臭皮匠，因为安排一个诸葛亮可以带好一个臭皮匠，三个臭皮匠能把诸葛亮也熏臭了。开发团队应该是全高手阵营，人不必多，但要个顶个而的强。玩儿开源项目的人都是有热情的程序员，往往都是高手，程序员用程序说话就好了，电话不用天天打也不耽误沟通。
跑下题说team work. 最近在想，team work表面上看是相对于个人英雄主义来说的，仔细一想，其实个人英雄主义应该是team work的前提。程序员就是要有这样的本领，当他把手放在键盘上的时候，就能源源不断创造价值。一个人没单打独斗的能力，就没资格谈team work, 笨蛋当然喜欢team work了，不然很容易暴露自己的无知和无能。