組織模式 Introduction

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

在這裡，向大家推薦 james coplien 的 organizational patterns。它不是一套新的過程，一上來弄十幾個實踐，也不知道為什麼就開始結對開始 tdd 了。它也不是什麼大師思想，只有大師才能領會。它更像乙個中藥櫃，裡面列了許多藥方，更重要的是還告訴你了什麼時候用什麼藥，相關的藥有哪些，吃了藥有***的話用什麼藥去化解。

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

在他的主頁上有top 10 patterns：

本來有乙個wiki的，不過現在已經掛掉了。利用web.archive.org還可以找回來。

模式有很多。在我看來最重要的就兩個：

第乙個是要有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遊戲。這個遊戲讓你設計鋼鐵互相搭配的形狀，設計一座橋梁，然後讓汽車從上面通過。如果受壓大的鋼條就會變紅，超過負載就會斷掉。

組織模式 Introduction

關於軟體質量的思考 Introduction

機器學習系列筆記一 Introduction

領域邏輯的組織模式

組織模式 Introduction

關於軟體質量的思考 Introduction

機器學習系列筆記一 Introduction

領域邏輯的組織模式

相關推薦