周末去聽Hadoop大會，看見的都是玩兒開源項目的好手，突然就想起敏捷了。敏捷強調(diào)溝通,尤其是面對面的溝通，并且有每日例（立）會，iteration plan meeting, 還有retrospect meeting。突然就在想，開源項目常常聚集來自不同國家的人，他們很多時候根本互相不認(rèn)識，兩個不同公司不同時區(qū)不同國家的人咋面對面溝通?。空埤R開會?。咳思移綍r溝通全靠mail, 但是他們做大項目也能成功，人家是怎么做到的？我們搞敏捷，這么神奇的武器，開發(fā)過程仍然捉襟見肘，還不如開源項目有序，為什么？
猜想世界范圍的開源項目溝通成本高，所以他們必須千方百計降低溝通需要，通過一些手段可以做到，比如
一，清晰，自然的架構(gòu)。
二，高質(zhì)量代碼，代碼像文檔一樣流暢。
三，模塊化，面向接口。
四，務(wù)實的文檔。
五，自動化測試。
……
有些溝通是必然免不了的，比如需求的溝通，我覺得最復(fù)雜的需求溝通往往起因于程序員不了解行業(yè)領(lǐng)域知識，而開源項目往往是工具類，框架類的項目，絕大多數(shù)不涉及特定行業(yè)領(lǐng)域知識，了解“domain”的門檻不高，所以需求方面的溝通要求天生就相對較低。我們平時工作的很多溝通來自于技術(shù)問題的溝通，我絕不懷疑，技術(shù)手段能夠降低溝通技術(shù)問題的需求，而一個不那么倚重程序員溝通技術(shù)問題就能把技術(shù)做好的項目，才說明技術(shù)風(fēng)險低，技術(shù)好。一些事情，比如技術(shù)選型，的確需要Involve比較多的人討論。但是當(dāng)技術(shù)選型確定，模塊劃分清楚，接口清晰之后，技術(shù)溝通的需求就應(yīng)該比較低了。有的時候技術(shù)上會遇到一些dilemma,這樣寫程序不好，那樣寫也不對，有時候確實是因為技術(shù)本來也沒有完美的解決方案，總要trade off掉一些事情。但更多時候是因為架構(gòu)不好，才引發(fā)了隨后的種種麻煩。程序員之間扯皮什么事情該誰做，是不是因為模塊化做得不好？“xx,你給我講講某塊代碼實現(xiàn)吧，我懶得看了”，是程序員懶還是程序?qū)嵲谑且粓F漿糊，慘不忍睹？同一個問題A給B解答一邊，給C解答一邊，后面還有E,F,G….是不是早該寫好文檔？
coding的工作不神圣，但確實不同的人做出的設(shè)計可以大相徑庭，同一個功能背后的代碼也可以天差地遠(yuǎn)。做產(chǎn)品不是靠人堆出來的，三個臭皮匠頂不了一個諸葛亮，三個臭皮匠還不如一個臭皮匠，因為安排一個諸葛亮可以帶好一個臭皮匠，三個臭皮匠能把諸葛亮也熏臭了。開發(fā)團隊?wèi)?yīng)該是全高手陣營，人不必多，但要個頂個而的強。玩兒開源項目的人都是有熱情的程序員，往往都是高手，程序員用程序說話就好了，電話不用天天打也不耽誤溝通。
跑下題說team work. 最近在想，team work表面上看是相對于個人英雄主義來說的，仔細(xì)一想，其實個人英雄主義應(yīng)該是team work的前提。程序員就是要有這樣的本領(lǐng)，當(dāng)他把手放在鍵盤上的時候，就能源源不斷創(chuàng)造價值。一個人沒單打獨斗的能力，就沒資格談team work, 笨蛋當(dāng)然喜歡team work了，不然很容易暴露自己的無知和無能。