你掉進過“偽敏捷”的陷阱嗎?

敏捷開發社群發表於2020-10-13

《2020年敏捷狀態報告》中顯示,現今許多組織還在學習如何實施敏捷。受訪者中也有大約50%的人表示,他們的團隊中只有不到一半的人在使用敏捷,而其中仍有高達84%的人承認他們的組織沒有達到高水平的能力。


一部分公司或團隊在踐行敏捷後取得了巨大的成功,讓更多的人趨之若鶩,紛紛轉型敏捷。但轉型敏捷絕非易事,在這一過程中,最常見的問題就是團隊並未真正理解敏捷原則及核心價值觀,而是一味地照貓畫虎。自然,照貓畫虎最終還是失敗了,這時候經過這一系列變動的團隊或成員就開始大肆宣揚“ 敏捷無用論 ”:搞那麼多虛頭巴腦的招式,只會浪費更多的人力物力財力,增加時間成本,到頭來沒有什麼實質性的用處。但是,真的是敏捷無用嗎?還是你用錯了敏捷?


敏捷宣言的主要內容是:

  • 個體和互動高於流程和工具;
  • 工作的軟體高於詳盡的文件;
  • 客戶合作高於合同談判;
  • 響應變化高於遵循計劃。

但在很多公司中,團隊打著“敏捷”的旗號,實際行動卻嚴重偏離敏捷宣言及價值觀,最後往往“欲速則不達”。敏捷宣言合著者Robert C. Martin接受採訪說, 任何工具或者流程如果讓人們在自己的工作環境中感到舉步維艱,那它就不能被稱為敏捷。因此,這些僅披著一層“敏捷”外殼的團隊,只能稱之為“偽敏捷”。

當團隊或者公司踏入“偽敏捷”的怪圈時,如何發現這一問題,就是我們要去解決的問題了。

什麼是偽敏捷?

1.極端的敏捷

1)“敏捷”並不是一味的“快”

談到敏捷,作為一種輕量級方法,很多人誤認為敏捷就是“快”:快速反應、快速交付。因此整個團隊只顧追求速度,認為“時間緊任務重”,以致於為了追求速度而不得不放棄質量。這種以快速交付為重心的產品無法滿足客戶的需求,甚至無法透過測試的質量鑑定。

2)“敏捷”並不是一味的“簡潔”

敏捷十二原則中第10條為“ 以簡潔為本,極力減少不必要工作量的藝術”。有的人就會說了,既然要提倡簡潔,那麼就把不必要的流程簡化吧:每日站會太浪費時間了,減掉;回顧會議毫無意義,減掉;準備文件太複雜了,減掉;敏捷提倡響應變化,所以不需要計劃會議了,減掉……絕對主義者往往會覺得既然要簡化就簡化的徹底一些,就要進行大刀闊斧的改革。然而在一通亂裁之後,真正有價值的東西被“淘汰”了,留下一群摸不著頭腦的程式設計師在重複繁瑣的任務中繼續敲程式碼。

2.僵化的敏捷

1)站立會議

每日站會是敏捷團隊進行工作互通的橋樑。每日站會不需要團隊成員對自己的工作內容作出詳盡而清晰的報告,只需要用兩分鐘的時間進行一個簡單的陳述,總時長一般在15分鐘左右。這裡的15分鐘只是一個大概的時間,具體時間會根據每個團隊的成員數量以及工作性質而變。在敏捷的實踐過程中,一些團隊將站立會議的概念混淆,只是死板地遵循15分鐘會議時間的規定,不論團隊成員數量多少,要求必須在15分鐘內結束。

一旦會議時間被刻板化,這會給團隊成員增加很大壓力,促使他們不得已找些零零碎碎的任務來敷衍會議,因此也就無法達到每日站會促進團隊內部交流的目的。

2)看板

敏捷團隊中通常應用看板幫助團隊實現任務視覺化、工作狀態透明化,激勵團隊成員工作、提高工作專注力及效率。但是在設定看板後,也會一個很大的缺陷:看板處於半閒置狀態,無法得到及時更新,團隊成員無法從看板中獲取響應的資訊。這樣的結果就是:看板成為了一個代表敏捷的擺設。負責人在彙報工作的時候,一指牆上的看板:看,我們團隊在轉型敏捷。但實際上,敏捷的觀念有沒有深入貫徹,除了團隊內部成員,其他誰也不知道。

3.傳統型領導的敏捷

之前寫過一篇關於 的文章,文中強調了在團隊轉型規模化敏捷之前,首先需要領導者轉型敏捷。同樣,在傳統團隊轉型敏捷的過程中,也需要領導者率先轉型敏捷,具備精益敏捷思維。只有精益敏捷的領導者才能透過挖掘、利用團隊和個人的長處推動團隊的敏捷化。


我曾瞭解過這樣一家公司,領導者思維延續著傳統的瀑布式開發模式。當整個團隊開始轉型敏捷的時候,領導仍在提倡開發流程的前後延續關係,導致團隊在實施敏捷開發的小週期迭代時遇到很大的阻力,整個團隊呈現出一種“高不成低不就”的狀態。如果公司內部都沒有達成統一的敏捷轉型態度,這時的敏捷團隊就會舉步維艱。

因此,要想打破敏捷轉型效果不佳的“詛咒”,就要勇於衝破團隊現行模式的桎梏,識破團隊中的“偽敏捷”現象,根據團隊的實際情況適當改變策略,真正做到讓敏捷“活”起來。


更多敏捷相關諮詢請點選下方連結:


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982050/viewspace-2726527/,如需轉載,請註明出處,否則將追究法律責任。

相關文章