最佳的架構、需求和設計出自于自組織的團隊。蜂巢中的工蜂們看似忙碌，但其工作卻是有序而有效，歸根結底就是它們的組織架構其實是自我組織的。在自我組織的團隊中，團隊是一個整體，沒有角色之分、職位之分、也沒有高下之分。團隊成員的任務不是項目經理強加于身，而是根據自己的愿望和能力對任務進行合理評估，并主動進行領取。被動與主動所產生的驅動力顯然不可同日而語。

自我組織的團隊是一個平行的組織，由于沒有管理與被管理之間的關系，因而氛圍更加和諧，組織更加開放，管理更加松散，這種自由化的組織方式更容易讓團隊成員體現自我價值，對團隊會產生一種認同感，促發他們的開發熱情，從而提高開發效率。平等的關系會促進團隊成員的有效溝通，自由的管理有助于發揮團隊成員的技術特長，開放的平臺則能夠保證協作的效率。一個卓越的團隊應該是目標一致，團結協作，同時又能各司其職，有條不紊。

自我組織的團隊建立在團隊個人能力的基礎之上。它其實是一把雙刃劍。如果團隊成員個人能力有限，或者自我約束能力較差，而管理人員又無法把握松散管理的度，就很可能出現一些問題。例如：
1、團隊人員無所適從，不知道該做什么。很多開發人員對敏捷方法不能適應，他們已經習慣了聽從命令與安排的方式；
2、任務安排不平衡，團隊成員在開發過程中偷工減料。耽于安逸的開發人員或許會利用管理的漏洞或管理人員對他的信任，胡亂估計任務的工作量，或者夸大任務實現的難度；
3、自由失去節制，無論是技術方案的討論和評審，還是任務工作量的評估，因為沒有絕對權威，很容易失去控制，因糾纏于細節而讓大量的討論浪費時間。

如何解決這三個問題？對于第一個問題，基本無解，除非你有足夠的煽動力或超凡的演講能力，改變這些開發人員的思想，乃至于開發習慣。最佳方式是循序漸進，并對自我組織的方式進行改進，例如和傳統的管理方式結合起來。或者就放棄敏捷的管理方式吧。如果說敏捷是魚，只能在水中生活，你怎么能讓它上岸呢？

對于第二個問題，需要動用團隊的力量。例如對任務的評估，我們可以利用計劃游戲，或者設計計劃紙牌對任務工作量進行估算。總之，我們應盡量讓團隊對任務工作量的估算不要出現太大的偏差，使任務的開發在可控的范圍內。此外，及時召開回顧會議，也是杜絕這類問題的一件利器。

第三個問題需要團隊的管理者建立某些準則，例如對技術問題的討論設定時間的限制。一旦超出該時間，就應該把問題放在一邊，或者由管理者利用自己的權威和經驗下定結論，而不能無限制的爭執下去。

自我組織的團隊管理者需要因時因人而置宜。Larry L. Constantine在《人件集》中提到：“對于開放型的團隊來說，最好的領導應該表現得像他們中的一個同事一樣，能夠參與所有的技術問題討論，包括分析、設計和系統構建。”例如在Scrum中，團隊角色就是一個自我組織的團隊，由團隊來確定每個Sprint的工作內容。而Scrum Master就不再是控制者，而是指導者；不是上司，而是教練。他必須理解自組織團隊的重要性。

自我組織是敏捷管理的精髓，也是敏捷管理成敗的關鍵！

it知識庫：敏捷開發思想之自我組織，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。