前言

說到敏捷管理，很多程序員或者軟件開發公司的管理人員第一反應就是“小步快跑，頻繁發布”。這令公司決策層（老板）覺得敏捷能解決一切問題，想啥時候上線就啥時候上線。

其實這只是一種表象。

要深刻理解敏捷的本質和內涵，必須先了解一下它的前輩：科學管理。

什么是科學管理

科學管理的代表產物就是“流水線分工生產”，根據它的提出者，又叫“泰勒式科學管理”。

科學管理的產生背景是在第二次工業革命期間。之前依靠經驗的作坊式生產，已經被工廠和機器生產代替，但工人工作習慣依然受傳統經驗式生產影響，沒有合作、分工的機制。對于生產效率的追求，促使人們開始研究生產活動中的勞動時間和工作方法。

其中，泰勒通過三個實驗，奠定了其科學管理的理論基礎。

• 金屬切削實驗

從1881年在米德韋爾公司，為了解決工人的怠工問題，泰勒進行了金屬切削試驗。他自己具備一些金屬切削的作業知識，于是他對車床的效率問題進行了研究。在用車床、鉆床、刨床等工作時，要決定用什么樣的刀具、多大的速度等來獲得最佳的加工效率。金屬切削試驗前后共花了26個月的時間，實驗三萬多次，耗費80萬噸鋼材和15萬美元。

• 搬鐵塊實驗

1898年，弗雷德里克·溫斯洛·泰勒從伯利恒鋼鐵廠開始他的實驗。這個工廠的原材料是由一組記日工搬運的，工人每天掙1.15美元，這在當時是標準工資，每天搬運的鐵塊重量有12～13噸，對工人的獎勵和懲罰的方法就是找工人談話或者開除，有時也可以選拔一些較好的工人到車間里做等級工，并且可得到略高的工資。后來泰勒觀察研究了75名工人，從中挑出了四個，又對這四個人進行了研究，調查了他們的背景、習慣和抱負，最后挑了一個叫施密特的人，這個人非常愛財并且很小氣。泰勒要求這個人按照新的要求工作，每天給他1.85美元的報酬。通過仔細地研究，使其轉換各種工作因素，來觀察他們對生產效率的影響。例如，有時工人彎腰搬運，有時他們又直腰搬運，后來他又觀察了行走的速度，持握的位置和其他的變量。通過長時間的觀察試驗，并把勞動時間和休息時間很好地搭配起來，工人每天的工作量可以提高到47噸，同時并不會感到太疲勞。他也采用了計件工資制，工人每天搬運量達到47噸后，工資也升到1.85美元。這樣施密特開始工作后，第一天很早就搬完了47.5噸，拿到了1.85美元的工資。于是其他工人也漸漸按照這種方法來搬運了，勞動生產率提高了很多。

• 鐵鍬實驗

鐵鍬試驗是被稱為科學管理之父的弗雷德里克·溫斯洛·泰勒所進行研究的三大試驗之一,也稱鐵砂和煤炭的挖掘實驗。它是指系統地研究鏟上負載后，研究各種材料能夠達到標準負載的鍬的形狀、規格，以及各種原料裝鍬的最好方法的問題。
他對每一套動作的精確時間作了研究，從而得出了一個“一流工人”每天應該完成的工作量。這一研究的結果是非常杰出的，堆料場的勞動力從400－ 600人減少為140人，平均每人每天的操作量從16噸提高到59噸，每個工人的日工資從1.15美元提高到1.88美元。
泰勒因這項實驗提出了新的構想：將實驗的手段引進經營管理領域。計劃和執行分離。標準化管理。人盡其才，物盡其用，這是提高效率的最好辦法。

泰勒對于生產活動中涉及生產的所有要素以接近實驗科學的方式進行定量分析和改進，提出了一系列劃時代的管理思想：工作定額原理、挑選頭等工人、標準化原理、計件工資制、勞資雙方的密切合作、建立專門的計劃層、職能工長制等等，最終其出版的《科學管理原理》迎來了一個全新的管理時代。

福特汽車公司之所以取得今天的巨大成就，與福特汽車公司創始人亨利·福特推行科學管理是分不開的。1910年，福特開始在高地公園新廠進行工廠自動化實驗。他率領一群高效率的專家，檢討裝配線上的每一個環節，試驗各種方法，以求提高生產力。而他最重要的突破就是利用甘特圖表進行計劃控制.創造了世界第一條汽車裝配流水線，實現了機械化的大工業，大幅度提高了勞動生產率，出現了高效率、低成本、高工資和高利潤的局面。

樹型組織結構和科學管理

泰勒對于生產活動的定量分析并大幅提高生產效率令人印象深刻，但實際上都是針對工廠管理生產活動的，并未涉及大型企業的組織治理問題。而對于敏捷管理來說，通常還會強調一個組織形式問題。討論敏捷組織的時候，我們往往拿樹型組織結構來類比（敏捷團隊是自組織的，更像網狀），但實際上樹型組織結構比科學管理出現的更早。

有史可考的第一張組織結構圖很可能晚至1854年才問世，它的編制者是紐約鐵路公司的總裁丹尼爾·麥卡倫（Daniel McCallum）。
當時，麥卡倫的公司正負責建筑一條從澤西城到大湖區、貫穿賓州與紐約、全長近500英里的鐵路。麥卡倫認為，在其他條件均等的情況下，這條鐵路的每英里建筑成本應該低于那些短程鐵路。
然而，事實上這些其他條件卻很難等同，修一條長500英里的鐵路，牽涉的方方面面工作肯定要比修50英里鐵路復雜得多。若無高效組織，這條鐵路的每英里建筑成本很可能要比那些短程鐵路不降反貴。
為此，麥卡倫編制了一張組織結構圖。根據亨利·瓦盧姆·普爾（Henry Varnum Poor）的記載，這是一張樹型結構的圖表， 其根部代表鐵路公司的總裁和高管層， 枝干代表公司的5個職能部門和客運、貨運部門，樹葉則分別代表地方票務代理、貨運代理、工段長及其他員工，等等。
歷史上，組織結構圖的誕生被認為是西方工業社會從自然的人治向企業化管理轉變的一個重要標志。經此轉變，組織能力逐漸成為企業生存競爭的先決條件。

而之后泰勒的科學管理開始將計劃與執行分離，將管理人員和生產人員的職能分開。而對大型企業組織按功能性進行劃分和科學管理的人員專職化思路，兩者正好契合，就攜手發展成了現代的企業組織和管理模式。

科學管理的小結

科學管理是“傳統管理”么？在今天看來可能算是一種“傳統管理”。但實際上，我們可以看到科學管理出現的年代，“傳統管理”是指作坊式經驗式管理。就是，依賴每個人自己的經驗和想法去組織和管理生產活動。十年經驗的老師傅必然生產效率比兩年經驗剛入門的工人要高，但再高也難有數量級的差異。而科學管理通過分解生產流程，工人專職化，通過設計整個流程，每個環節上的工人盡量做最標準化、最簡單、最容易培訓的事項，通過分工，實現流水線生產，從而整體上達成生產效率數量級的提升。

我們可以看到科學管理的巨大成功，但同時也可以看到它的一些特點：

• 要生產的產品必然是標準化的，確定的，有固定的設計圖或者配方

• 生產的流程是可以分解的，步驟化的，可度量的，每個環節要處理的事項是標準化和明確的，或者培訓成本不高的

• 生產效率的提升核心是做設計規劃的人，執行者只需要挑出夠用或簡單培訓后即可上崗的工人，以及根據個人產出（計件）的度量引入競爭機制和激勵機制來對執行者進行優勝劣汰

• 對工人的要求，從工作時間到休息時間，甚至每個動作，用的工具都可以提出規范性的要求（對人工的需求也是標準化的，可替代性非常強）

• 產能規模的擴大只需要復制一條又一條“流水線”，包括機器、夠勝任的工人和車間主管。只要資金足夠，水平擴展非常容易。

敏捷管理的來源

那么，敏捷管理的思想又源自何處？

在軟件開發行業，一開始的軟件工程項目的實施過程和流水線是非常像的，我們稱之為“瀑布式開發”。按需求,設計,開發,測試，逐一執行。只有前一環節完成了，再進行后續環節。

• 需求階段，要把需求調研清楚，需求文檔完全確定下來，然后進入設計階段；

• 設計把實現方案完全考慮清楚，設計文檔完全確定下來，然后進入開發階段；

• 開發進行編程編碼，封版，然后進入測試階段；

• 測試按需求文檔和設計文檔，進行非常周全的測試，修復缺陷，最后出具測試報告。

最后一個軟件就開發完成了。

看起來很合理，制造業的流水線在軟件開發項目中好像也行得通，而且在早期這種模式確實是可行的，因為早期軟件項目都是大項目，要解決的是非常專業領域內的問題，比如航天軟件、操作系統，編程開發有極高的門檻，使用計算機也有極高的門檻，對于一個需要采購計算機的企業，硬件都是一筆巨款，軟件研發經歷幾年都是很正常的。

而隨著PC作為企業辦公硬件的普及，以及后來互聯網信息化時代的到來，世界瞬息萬變，需要開發軟件的企業越來越多，而企業發現自己的軟件項目還在編碼開發的時候，突然原先理解的業務發生變化了，等軟件開發完成，可能已經不適用了。從90年代開始，軟件行業就顯現出了交付危機。

在2001年，隨著一群敏捷先驅針對行業項目管理和交付困境的討論，以及各自的實踐經驗總結，敏捷宣言誕生，一種新的軟件項目管理思想和眾多實踐方案開始推廣。（實際上是先有Scrum、XP等敏捷實踐方案，后有的敏捷宣言，這一事實是不是也挺違反直覺的呢）

敏捷軟件開發宣言

我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個體和互動高于流程和工具

• 可工作的軟件高于詳盡的文檔

• 客戶合作高于合同談判

• 響應變化高于遵循計劃

也就是說，盡管右項有其價值，我們更重視左項的價值。

敏捷宣言遵循的原則：

我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。

業務人員和開發人員必須相互合作，項目中的每一天都不例外。

激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

可工作的軟件是進度的首要度量標準。

敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

以簡潔為本，它是極力減少不必要工作量的藝術。

最好的架構、需求和設計出自自組織團隊。

團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

敏捷管理的小結

和泰勒近乎實驗科學式地定量分析生產活動一樣，敏捷宣言是對軟件開發活動的觀察和經驗總結。

敏捷宣言的目標是解決瀑布式軟件項目管理的長周期和應變不足導致交付災難的問題，通過溝通進行協商來應對變化。

從敏捷宣言的內容我們可以發現敏捷倡導的是：

• 主動溝通，積極反饋，不僅是團隊內的溝通，還指所有干系人包括客戶

• 通過協商來應對變化，交付的是價值

• 用交付可工作的軟件來說明軟件自身的功能以及實際研發進度

• 團隊持續學習，團隊基于信任自組織化

這里我不展開Scrum的具體做法（不打算在本文繼續展開具體的敏捷實踐方法論了），敏捷具體實踐中一般都有迭代/沖刺概念，即倡導在一個固定的較短實踐周期內去增量的交付軟件項目的功能特性。

即使敏捷宣言的每個字我們都認識，我們可能還是無法掌握敏捷的精神；即使我們一遍遍的培訓Scrum的343或者Scrum的5個價值，我們在具體落地的時候依然會遇到各式各樣的問題。

從個人所經歷的多年軟件項目敏捷實踐經驗，我得出的結論是必須對你想搭建的敏捷團隊的每一個成員解釋清楚為什么需要敏捷，以及敏捷是一種什么樣的工作模式。這個過程實際上是打造團隊文化的過程，但這真的不是一件容易的事。

敏捷團隊文化

鋪墊了這么多，要開始扣題了。

制造業流水線的目的是為了規模化生產，提高生產效率，生產目標是標品；而軟件開發的目的是為了滿足各種各樣的定制需求以及研發過程中可能出現的需求變化，生產目標是非標品（如果是完全一樣的需求，軟件系統的自身的復制幾乎是毫無成本的）。

科學管理的目標是希望生產過程如流水線一般一切都可控可度量，精確到不會因為任何一個不可控因素而導致生產效率受到影響。科學管理把人分成不同職能，安排好不同職能的人的分工，并且在分工上是有序的，各司其職，各做各的，不需要關心整體流程，只要做好自己那一環，整體的流程由另一群人設計。它的本質（做一個不太恰當的比方）是整個生產過程的機械化，包括生產工具和參與生產的“人”。“人”在滿足基本技能要求的情況下，也是和工具一樣可替換性越強越好。

而敏捷管理正好相反，敏捷團隊中雖然也會有分工，不同職能的人形成一個團隊進行工作，但其實對團隊中的每一個人，都有很強的全局意識要求。因為團隊工作核心在于持續交付和應對變化，每個人都必須清楚知道自己以及和自己配合的人，是否在做正確的事，是否按預期在推進。任何理解上的不一致，都有可能對團隊目標造成影響。

所以敏捷對于個體的主動性要求是非常高的。

而即便有了主動性，也還是不夠的。主動性只能保證溝通是及時的，卻無法保證信息傳遞的正確性和完整性。敏捷團隊實踐中最困難和最具挑戰性的是達成集體共識，這指的是對需求的理解一致，對當前團隊要完成的目標，要實施的方案以及各自分工要完成的任務的理解一致。

由此敏捷對于溝通中的語言和表達方式的一致性也是有要求的。團隊成員必須在同一個層面上，以相同的形式進行溝通。不同職能的人會有不同的專業技能，不同的專業技能可能會在表達中摻雜各自的專業術語，這種溝通方式就是不合適的。對于軟件開發來說，所有的溝通術語都應當是團隊所面對的業務術語，而溝通方式，我這里強烈推薦以UserStory為基準，貫穿所有職能和整個研發路徑。UserStory描述的是用戶以什么身份、為了什么目的、如何使用軟件的。這個表述方式可以直接和用戶/客戶討論（獲得客戶的反饋是至關重要的），無需任何專業背景就可以理解，當然也適合團隊中不同職能的成員。試想在一個需求討論會議中，幾個開發人員在講設計模式，討論數據結構，此時旁聽（甚至插不上話）的產品經理如何確定大家理解是一致的？

科學管理要打造一個有序世界，并且不停思考如何優化以提高效率；
而敏捷面對的是一個混沌世界，要考慮的是如何在不確定性和復雜性中圍繞團隊的目標摸索出一條能持續前進的道路。

很多講敏捷的書都會特別強調這里的“復雜”是指“錯綜復雜”，即各種各樣的因素，互相之間也會有影響，有連鎖反應。在軟件開發中，一方面指的是業務的復雜性（問題域），另一方面指的是系統的復雜性（解決方案域）。為了應對這兩方面的復雜性，對于敏捷團隊來說，又會需要一種持續學習的特質。只有不斷學習業務領域的知識，不斷學習可能要用到的專業知識，才能有更好的敏捷能力去達成團隊目標。（對于持續學習業務知識這件事，很多高級開發可能受領域驅動設計理論影響認為項目里必須要有一個領域專家，但實際上在大多數中小項目中，這是可遇不可求的。比較好的情況是能在實際用戶群體中找到那么一個對業務非常了解的人，那么一定要珍惜向對方學習業務知識的機會）

最后，縮短反饋周期，以交付可工作系統為進度，就需要固定的Timebox和穩定的增量交付節奏。這自然而然又會引導團隊工作是價值導向的。而到底什么工作是對客戶有價值的，實際上是由團隊中不同職能的成員一起決定的。

總的看下來，會有一種感覺：其實敏捷團隊自始至終都是在“一邊學習了解要解決的問題，一邊增量式的交付，一邊驗證并反思積累經驗再應對下一步”。好像和科學管理比起來，敏捷團隊做事情不那么專業和靠譜的樣子，甚至很多客戶會覺得你區區乙方還拉上我甲方，教我做事？

強調個體互動，強調溝通和共識，強調持續學習，允許團隊自身決定工作安排。我突然領悟到，敏捷團隊實際上是把一群不同職能的人當成一個人來用，實際上是在科學管理出現之前的依靠老師傅經驗的作坊式生產的回歸（現在的敏捷培訓必不可少的環節就是工作坊演練）。

所以，敏捷的團隊文化，就是主動、共識、信任、成長以及凝聚力。這些措辭并不是一句空話，而是真正能跑順敏捷的關鍵。“成功的團隊”最終會如同“一個人”。

至此，對于敏捷實踐中如何打造一個團隊的文化的關鍵點，你是否Get到了呢?

總結

以上是生活随笔為你收集整理的论敏捷管理与团队文化的契合度的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。