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

?

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

在Oredev 2008上有一個相關(guān)的演講視頻（原視頻地址被墻，這是我放在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的，不過現(xiàn)在已經(jīng)掛掉了。利用web.archive.org還可以找回來。?
http://orgpatterns.wikispaces.com/?

?

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

?

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

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

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

?

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

總結(jié)

以上是生活随笔為你收集整理的组织模式 - Introduction的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。