當Agile已經變成一個貶義詞的時候，我們是要把Lean變成下一個貶義詞嗎？還是腳踏實地去做一些改進？

當Agile已經變成一個貶義詞的時候，我們是要把Lean變成下一個貶義詞嗎？還是腳踏實地去做一些改進？ 

 

在這里，向大家推薦 James Coplien 的 Organizational Patterns。它不是一套新的過程，一上來弄十幾個實踐，也不知道為什么就開始結對開始 TDD 了。它也不是什么大師思想，只有大師才能領會。它更像一個中藥柜，里面列了許多藥方，更重要的是還告訴你了什么時候用什么藥，相關的藥有哪些，吃了藥有副作用的話用什么藥去化解。 

在Oredev 2008上有一個相關的演講視頻（原視頻地址被墻，這是我放在Youku里的）： 
http://v.youku.com/v_show/id_XMTUxNzgyOTI0.html 

這本書在電驢上有。國外的朋友可以去買紙版的： 

http://www.amazon.com/Organizational-Patterns-Agile-Software-Development/dp/0131467409 
在他的主頁上有Top 10 Patterns： 

http://users.rcn.com/jcoplien/Patterns/Top10OrgPatterns.html 

本來有一個wiki的，不過現在已經掛掉了。利用web.archive.org還可以找回來。 
http://orgpatterns.wikispaces.com/ 

 

模式有很多。在我看來最重要的就兩個： 
第一個是要有Unity of Purpose，大家必須要朝一個方向努力。另外一個是Distribute Work Evenly，工作必須在所有組員之間平均分擔。不過最重要的也是最無用的，因為只要達到了這兩個狀態，基本上也沒有項目管理問題了。所以我把其他的模式都看成達到Unity of Purpose & Distribute Work Evently的手段。 
關于Distribute Work Evently這個模式特別有意思。Coplien用CRC卡記錄了組員的角色，職責以及互相溝通的頻率。然后標以紅黃綠的顏色表示連接強度。這個非常有意思。讓我想其了包之間的依賴。讓我想起了玩Bridge游戲時鋼鐵受力圖。也許協作問題根本要解決的就是如何平均分攤受力吧？ 

 

Cope總結得非常好，他說軟件開發組織有多高效，主要就是取決于溝通的強度。上面那張圖就很形象地標榜出了什么是高強度，健康的溝通。健康的人際關系網絡，就是沒有瓶頸的網絡。信息能夠及時地傳達到需要的人的手上。在上面的圖我看到的是平衡負載的人際關系，沒有人是Overloaded的。 

在這張圖里，我們就明顯的可以發現有人是Overloaded的。在你的團隊里有這樣人嗎？很多項目里的項目經理，不但要管項目，管需求還要管技術，顯然是會Overloaded。有的項目專門有人負責“溝通”，就是他去和客戶溝通，然后回來和程序員溝通，然后和QA溝通。很快，溝通就變成他的全職工作，那么他的附加值是什么呢？只要團隊內有這樣的Overloaded的角色，他們就會變成薄弱點。一旦團隊的規模變大，外部的壓力變大，就會整體垮掉。所以，平均負載是關鍵。 

有一個非常形象的類比。就是Bridge游戲。這個游戲讓你設計鋼鐵互相搭配的形狀，設計一座橋梁，然后讓汽車從上面通過。如果受壓大的鋼條就會變紅，超過負載就會斷掉。 

 

但是這個是模式嗎？James Coplien認為這個是，這個模式叫Distribute Work Evenly。但是我覺得這個不是常規意義上的模式。至少我理解的模式是為了解決特定問題在特定上下文中的特定解決方案。而Distribute Work Evenly只能說是一個愿望，并沒有具體可實際操作的解決方案。我有一個想法是“如果不能輕易地想出一個不適用的場合，那么這個模式就不是一個模式”。按照這個想法，我把組織模式的四個Pattern Language幾十個模式做了一些整理。下一篇，我們就來看看，組織模式都包含哪些內容。