周末去聽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了，不然很容易暴露自己的無知和無能。