你們眼中的敏捷：是“靈藥”還是“毒藥”？如何用敏捷提升/搞垮一個團隊？

原創(chuàng)2024-04-08小艾老師

Scrum Master敏捷專家認證（CSM）知識體系考證須知證書含金量培訓(xùn)大綱 3分鐘小視頻我要提問

Scrum Master 認證是針對 Scrum Master（敏捷項目管理中的角色）的專業(yè)認證。Scrum 是一種敏捷開發(fā)方法，Scrum Master 則是負責(zé)指導(dǎo)和推動 Scrum 團隊的角色。獲得 Scrum Master 認證可以證明個人在敏捷項目管理方面具備一定的知識和技能，并且對Scrum方法有深入的理解和實踐經(jīng)驗。這對于在敏捷環(huán)境中工作的項目經(jīng)理、團隊領(lǐng)導(dǎo)或相關(guān)專業(yè)人士來說，可能有助于提升他們在職場上的競爭力和專業(yè)認可度。

中文名Scrum Master敏捷專家認證（CSM）
英文名Certified Scrum Master
英文簡稱CSM
頒證機構(gòu)Scrum Alliance（Scrum敏捷聯(lián)盟）
證書類別敏捷
同類認證ACP、ITIL4 HVIT、DevOps

在當(dāng)今的高速發(fā)展的商業(yè)環(huán)境中，敏捷，既能成為提升團隊的靈藥，也可能變成摧毀團隊的毒藥。它究竟是何種面貌，取決于我們?nèi)绾芜\用它。

01_是“靈藥”還是“毒藥”？你們眼中的敏捷，到底是什么樣子的？

普通程序員眼中的敏捷是什么樣子的？曾經(jīng)有學(xué)員跟小艾老師這樣分（tu）析（cao）過：

1、很多公司老板之所以用敏捷，就是想讓產(chǎn)品早點上線。以前瀑布式開發(fā)模式，一個項目起碼一個季度，可敏捷模式一般 2 周就1個迭代。有時產(chǎn)品還沒什么頭緒，就要先做出能交付的_小版本。這就導(dǎo)致產(chǎn)品上線/產(chǎn)品迭代的節(jié)奏太快，程序員像是一直被上緊了發(fā)條。

2、對于程序員來說，如果完不成當(dāng)天的工作，就只能加班。因為敏捷的站會是要當(dāng)著同事們的面，說為什么沒有完成，這很“丟人”，也很“不好受”。他推斷現(xiàn)在一些互聯(lián)網(wǎng)公司推行的996工作模式，敏捷可能也是一個重要的原因。

小艾老師覺得，不管怎么說，關(guān)于敏捷有三個事實，似乎不用爭議：

作為一個標(biāo)簽，敏捷是勝利者，因為沒有人希望被稱為“非敏捷”。
但在實踐上，雖然大家都說自己“敏捷”，其實可能并不是。團隊容易陷入“假敏捷”的陷阱。
雖然我們極力提倡敏捷（尤其是很多公司的老板...），但敏捷并不是_的，敏捷也有不適用的情況。

“敏捷開發(fā)”因為頂著“敏捷”兩個字，常被作為解決“效率”問題的“靈藥”，其實呢，敏捷開發(fā)中的敏捷，更多是“靈活”“靈敏”之意。指的是對“變化”能快速響應(yīng)，而不是針對“效率”的?？陀^上來說，當(dāng)你的團隊擁抱敏捷，使用那些敏捷方法之后，你的團隊的工作效率可能會提升，但也可能被降低。

敏捷的精髓在于擁抱變化以及快速響應(yīng)的能力，它真正的核心是敏捷思想及原則，而不是啥工具、方法或者流程，更不是看板或者每日站會啥的。敏捷的價值在于把不確定的產(chǎn)品需求給落地，幫著用戶搞清楚產(chǎn)品價值，交付_小能用的產(chǎn)品，然后在這個基礎(chǔ)上小步快跑，快速迭代。所以，敏捷_適合那種“還不確定、還不完善、還沒想清楚的產(chǎn)品需求”。要是那些目標(biāo)、商業(yè)模式、需求都非常明確的項目，可能就不太適合敏捷了。

02_“真敏捷”還是“假敏捷”？如何用敏捷“搞垮”一個團隊？

真敏捷，意味著團隊能夠快速適應(yīng)變化，不斷交付價值，提高客戶滿意度。它強調(diào)的是靈活性、協(xié)作和持續(xù)改進。真敏捷的團隊具有以下特點：

緊密的協(xié)作：成員之間溝通順暢，能夠高效地合作。
快速決策：能夠迅速做出決策，避免繁瑣的流程。
持續(xù)學(xué)習(xí)：不斷學(xué)習(xí)新的知識和技能，以更好地應(yīng)對變化。
客戶導(dǎo)向：始終以滿足客戶需求為首要任務(wù)。

然而，有些團隊可能只是表面上采用了敏捷的形式，而并未真正理解其內(nèi)涵，這就是假敏捷。假敏捷的表現(xiàn)包括：

形式主義：僅僅遵循敏捷的流程，而忽略了其精神。
缺乏溝通：團隊成員之間溝通不暢，導(dǎo)致信息傳遞延誤。
不注重質(zhì)量：為了追求速度而犧牲了質(zhì)量。
無法適應(yīng)變化：面對變化時反應(yīng)遲鈍。

敏捷方法，既能成為提升團隊的利器，也可能成為搞垮團隊的隱患。如何運用敏捷，是決定團隊成敗的關(guān)鍵。用之得當(dāng)，即真敏捷，它可提升團隊的協(xié)作、創(chuàng)新與響應(yīng)能力；反之，若誤解或錯誤應(yīng)用，可能導(dǎo)致混亂、沖突和效率低下。

小艾老師整理了幾種“用敏捷搞垮一個團隊”的例子：

1、老板和團隊都不了解敏捷

很多公司老板/領(lǐng)導(dǎo)為了產(chǎn)品早點上線，光想著“更快、更好、更省成本”，但他們沒明白，敏捷開發(fā)中的敏捷兩字，更多是指對“變化”能快速響應(yīng)，敏捷并不是“高效”的同義詞。

2、只有技術(shù)團隊敏捷，其他人不敏捷

技術(shù)開發(fā)團隊可以實現(xiàn)快速迭代和反饋，但其他團隊的工作節(jié)奏和溝通方式與之不匹配，導(dǎo)致協(xié)作困難和項目推進緩慢。

3、團隊將敏捷視為一種潮流或時尚，而不是真正理解其原則和目的。

團隊可能會隨意選擇敏捷實踐并試圖快速實施，而不考慮其是否適用于團隊的具體情況。這種表面上的敏捷實踐可能會導(dǎo)致混亂和不良結(jié)果。

4、團隊試圖用敏捷解決技術(shù)上的困難或挑戰(zhàn)，而不是將其用于項目管理和團隊協(xié)作。

團隊可能會誤解敏捷方法的適用范圍，試圖通過迭代開發(fā)來解決技術(shù)架構(gòu)或設(shè)計上的問題，而忽視了團隊協(xié)作、客戶反饋等方面的重要性。

5、團隊錯誤地認為敏捷不需要文檔，導(dǎo)致溝通和知識共享的困難。

團隊可能會忽視編寫文檔，導(dǎo)致項目信息不透明，溝通困難。缺乏文檔也會使得新成員加入團隊時難以理解項目和歷史決策，影響團隊的可持續(xù)性和成長。

6、團隊技術(shù)能力較弱，無法有效地執(zhí)行敏捷

團隊可能會遇到頻繁的技術(shù)障礙，無法按時交付工作成果。缺乏技術(shù)能力的團隊成員也會導(dǎo)致無法有效地進行團隊內(nèi)部的知識共享和技術(shù)支持。

03_重新認識敏捷與Scrum,如何用敏捷“提升”一個團隊？

敏捷方法有很多，比如：極限編程XP、Scrum、DSDM、自適應(yīng)軟件開發(fā)、Crystal、FDD、SAFe等等。很多其他體系也都融入了自己的敏捷，比如PMP（敏捷項目管理）、比如ITIL（高速IT）、比如TOGAF（敏捷架構(gòu)）、比如CBAP（敏捷業(yè)務(wù)分析）等等…

但_重要的敏捷方法，莫過于Scrum。Scrum是目前_為成功的敏捷方法。

Scrum是用于開發(fā)、交付和持續(xù)支持復(fù)雜產(chǎn)品的一個框架，是一個增量的、迭代的開發(fā)過程。