敏捷不是反管理，而是更加激進！

譯者：nikijv

審校：bob jiang

英文原文

敏捷軟體開發仍然比當今的認知更激進，相當的不幸，包括大部分品牌和方法，在我這個有點老的男人對雲觀點大喊大叫的時候，也被大多數較小的"敏捷"**商所採用。

敏捷軟體開發正如我們所定義的那樣，對於業務與開發間的日常協作較為頻繁，以維持增量的可工作軟體。這樣團隊稱為自組織團隊，尤其要說明的是：最好的架構、需求、設計來自這些自組織團隊。

原則上很清楚，軟體、架構、設計等一切工作都源自於團隊，從團隊中湧現。

例如，需求不來自於一些業務單元，而是通過**委員會進行傳遞，然後傳遞到一些傳統部門或專案部門直到它落在一些程式設計師的辦公桌上。

這不是"反"管理。這根本不涉及解決類似於預算工作、人員補償、評估效能或者其他"管理"關心的主題。

當然，敏捷軟體開發提出了乙個新的、不同於軟體產品製作的管理。尤其通過基於工作軟體的可持續生產使用的自組織、增量、速度技術，是解決軟體開發應該被管理的新方式。

敏捷是反管理的麼？我不這麼認為，敏捷明確反泰勒式的管理，而支援推動管理。

同樣，像所有好人一樣，我們更樂於好的富有成效的管理，強烈反對貧瘠、無效、有害的管理。

但是我想建議這個底線是：

一、scrum在發光

考慮到scrum的構想，最流行的敏捷方法如果不是最有效的，那什麼是？

scrum稱為自組織的團隊，包括產品負責人，被授權於全部權利和責任，負責大型組織團隊的投資回報率。scrum團隊中scrum開發者的開發團隊，必須包含交付產品增量的"全部必要技能"，乙個被整合、測試過的、可工作軟體包括團隊迄今為止產生的所有價值元素。

scrum承認scrum團隊是嵌入式的，以某種方式，在乙個組織中，組織提供了資金（投資），干係人關心scrum團隊做了什麼。敏捷團隊通過每個衝刺向干係人展示他們已完成的工作，邀請並聽取干係人的意見。scrum團隊與全權負責的產品負責人決定下乙個衝刺做什麼以及怎麼做。

衝刺審查是scrum團隊及其嵌入組織之間的完整介面。

關於scrum仍然有些問題沒有解答，同樣這些問題在上面twitter的帖子中也涉及到了。scrum不會告訴你如何預算，如何決定補償，如何評估效能等等。

在scrum課程中，人們經常詢問各種管理職能。有個經典實踐可以回應，課程上小組在便利貼上寫下他們能想到的所有管理職能。他們可以把這些便利貼放到下面4個位置：開發團隊，產品負責人，scrum教練以及其他。

將會有兩件事發生。首先，許多傳統管理職能轉移到乙個或多個scrum團隊元素。由團隊分配任務，由產品負責人決定要構建什麼，由scrum教練支撐和引導等等。有趣的一點是，總有些管理職能被貼到其他堆中。scrum甚至不會建議如何做這些：這已經超出了scrum的範圍。

然而，很明顯，scrum打算不管這些超出範圍的管理職能是什麼，它們與團隊的首要介面，可能只通過衝刺審查。尤其是除了產品負責人，沒有人可以要求團隊做任何事情，scrum對"經理"在scrum團隊執行時可以做什麼做了非常具體的限制。

二、敏捷軟體開發是反管理麼

敏捷軟體開發需要一種新的管理方式，在團隊規模上，團隊內部擁有對產品的所有權利和責任，而且最主要的介面是檢查實際演變的產品。

不一定是"反管理"，但一定與某些型別的管理背道而馳，尤其是源自於泰勒主義更具有侵入性的形式------福特主義，將工作視為機器，工人幾乎沒有權利或仲裁。儘管敏捷軟體開發肯定要求從團隊內部而不是外部應用這些概念，但與戴明和統計過程控制等概念的對立程度要小得多。

但我覺得主要的概念已經相當清楚：敏捷軟體開發是一種完全不同的管理方法，盡可能的把權利和責任下放給團隊。這種管理方法對於如何走得更遠沒有設定上限，但它設定了乙個相當嚴格的下線，這個下線是嵌入在團隊內部的產品做什麼以及如何做。

三、這些想法的限制是什麼

這很難說。我們通過敏捷團隊的成長能力去決定誰在團隊誰不在團隊，這對薪酬和評估有很大影響。我們開始聽到團隊中的誰直接與客戶合作，客戶有時基於固定**安排，或者更常見的基於執行速率為產品提供資金。

今天，更多的限制是被組織強加的------試圖做"敏捷"，這些限制中有很多是明顯錯誤的。有時組織沒有從戰略上很好地理解最好的管理是如何的。我通常認為,個人管理結構應在敏捷之前就位：不同的團隊成員"屬於"乙個或另乙個經理,而該經理則繼續嘗試對團隊成員的行為進行控制。

坦白講，自組織團隊被授權，而這導致衝突、混亂以及很多時候應該做敏捷組織主要**走向黑暗敏捷。這個觀點是正確的。

底線，敏捷軟體開發提倡不同的管理方式，很可能與一些過時的管理觀念不相容，不幸的是，這些觀念在今天仍然相當普遍。

反對的？不。完全不同？是的。