​CSM|在企業中推行敏捷，這些常見的問題你遇到過嗎？

無論你的公司是在做敏捷轉型還是一開始就使用敏捷，在推進敏捷的過程中往往都碰到了很多的問題。下面列舉四個常見的問題，看看你是否有遇到過？

團隊成員能力不足

敏捷團隊，小而精，精幹，才能保證小，每一個團隊成員所掌握的技術技能能夠確保他們承接任何任務需求，即敏捷團隊成員需要全棧工程師。

在敏捷團隊中分配任務時，是以需求為單位，而不是專業技能來分工，這就要求開發人員具備實現某個需求的所有技能，包括後端的開發、介面設計、資料庫的設計、單元測試等等，而是不是需要多個崗位支援協同才能夠完成一個需求。
 

 

敏捷團隊中應該包含了完成目標範圍內所有技能的人員，這樣的團隊才能最大限度的降低溝通成本，充分溝通、理解需求，而不是因為人為的原因而增加溝通成本。全棧工程師、跨職能團隊是我們的理想，可現實因為種種原因往往很難組建出一個這樣的團隊，比如：

開發人員的個人技能比較低，程式錯誤低，適配性差；

開發人員做單元測試時，不會編寫完備的測試程式；

承諾的工時往往無法兌現，開發過程出現一些意料之外的難題；

產品負責人對需求的陳述、描述不清，造成溝通不暢，團隊成員對需求理解不一致；

測試人員對需求理解不透徹，漏測的現象比較多；

Scrum Master水平較低，不能根據專案特徵制定合理工作流程和工作方法。

犧牲質量追求速度

質量和效率，是一對好兄弟啊。有質量才有效率，保證了交付質量，再談效率的提升才有意義！

在實施敏捷轉型過程中，發現很多管理者、團隊成員都沒有意識到在實施敏捷，一味求快，而忽略了質量問題，先快速交付，出現問題，再返工修復，這不是真正的敏捷，而是典型假敏捷。
 

 

典型的情況比如有：

追求程式碼完成需求，不關注程式碼質量，後期難以修改，別人無法看懂；

不捨得花費時間做單元測試，認為單元測試耽誤了專案工期；

發現缺陷，不及時修改；

遇到臨時變更或者加塞需求，不對原迭代需求列表進行重新梳理，導致迭代容量過大；

諸如此類，不勝列舉。

資源匱乏

敏捷不是萬能良藥，企業經營策略的問題，不是靠敏捷開發能夠解決的。

這一點在中小型公司尤為常見，公司為了短期經營目標，拼命承接專案，明知人員不足，也要倒排工期，勉強承諾，不砍專案，不砍需求，多個專案並行，一個人同時做很多個專案，團隊天天加班，996工作制，即使採用敏捷也無濟於事，最終就會為了速度而犧牲質量。
 

 

敏捷方法是基於團隊自己的估算來平衡團隊的能力與專案的需求，如果不顧團隊的開發能力，在資源絕對匱乏時實施敏捷，團隊疲於奔命，總不能兌現自己的承諾，就會形成惡性迴圈，不可能敏捷起來。

組織缺乏敏捷價值觀與環境

企業組織在採用敏捷時，先從一個專案開始嘗試敏捷方法，試圖在單專案內成功了，再推廣到其他專案。這種初衷是好的，但往往事與願違，為什麼呢？

因為缺乏組織級的敏捷環境，敏捷的價值觀並沒有在組織內得到從上到下的認可，尤其是領導對敏捷的誤解。
 

 

是領導首先提出來要採用敏捷，在推行中也往往是領導先破壞了敏捷原則。比如：

在專案進展過程中隨意抽調專案組成員做其他非目標範圍內的任務；

強加給專案組不合理的工期；

要求專案組為了工期犧牲質量；

不能保證Product owner的參與實踐，對需求有決策權的人員不能全程參與專案；

不能為敏捷團隊提供所需的集中辦公環境、缺少足夠的白板等；

要求專案填寫一些沒有產生直接價值的記錄以便於給領導彙報工作；

因此，要建立敏捷的價值觀與環境，需要先從領導做起，需要領導認可敏捷的價值觀、踐行敏捷的價值觀，為敏捷團隊配備好資源、環境、提供好服務。