敏捷開發在業內流傳已久，自其思想進入國內以來還會時不時傳出一些新的概念，很多概念如今聽起來可能已經背離了初衷，就像Bullet Id Inc. 的 CTO，James Williams 所說的一樣，敏捷開發已經逐漸地異化了。
近些年來，由於一些特定的需求，越來越多的軟件團隊開始採用敏捷開發模式，但是在開發過程中卻對其思想認識不足，例如，有些敏捷開發團隊甚至不設管理人員，只有一個向產品經理彙報的scrum master，職責不比祕書強到哪裏去。產品經理繼續向上彙報，直到市場或銷售總監，這種開發簡直就是胡鬧不是嘛。
排除軟件公司，在很多常規企業中，敏捷開發很多已經異化爲無人管理、無人負責的開發流程：產品經理、銷售、CEO拍腦袋加功能、改需求，然後開發團隊就趕快“敏捷”去吧。需求調研？設計？反饋？代碼評審？測試？統統不需要。說好聽點這叫敏捷開發，說不好聽點，這就是技術大雜燴，能做到哪一步算哪一步，完全忽略了敏捷開發的實質，唯一的好處可能是說出去好聽罷了。
這個問題延伸到HR也問題重重，在如此的需求下，HR的招聘可能就沒有那麼大的壓力了，對面試者的經驗做下簡單篩選，簡歷上在丟一點不明覺厲的英文縮寫，經驗裏寫個“敏捷開發”，就可以招進來了，你們不是要敏捷開發者嘛，這人很合適啊。
當然了，骨灰級玩家的方式更勝一籌：上網隨便找個敏捷開發的海外外包團隊不就得了嘛。管他說的是什麼話，會不會看書能不能讀報聽不聽廣播匣子，報價低就成了嘛。那麼怎麼管理外包團隊？當然是管不了嘛。不用規劃、沒有進度、不設期限，否則還得爲這個團隊配個真正的經理，當然這經理是肯定沒有的。
每到會議，scrum master可能都要聽到“進度完不成”這句老話，然後產品經理再插上一腳，丟點新需求進來，優先級不用說了，客戶急等着要。最終結果當然是需求變得稀奇古怪，進度早就不存在了。
而實際上，敏捷開發並不是這樣來的，迭代的核心在於軟件的超前規劃，如果沒有軟件開發經理，所有人都在盲人摸象，造出來的全是垃圾-- 時間超限、預算超支、充斥着各種拍腦袋的奇思妙想、根本不管需求是不是合乎邏輯。客戶肯定各種抱怨，需要產品支持怎麼辦？那就從一線開發抽人去維護嘛，結果是最好的碼農一天被工單打斷八百次。
一線人員每天花8 個小時擦屁股，雖然如果管理流程良好這些問題根本不會出現；開發時間如果不夠，那就 996 或者 9127。碼農就是用來加班的。
產品延期了怎麼辦？告訴scrum master 們（這些人身上經常掛個敏捷專家的標籤，哪怕四體不勤五穀不分），需求變啦。有點能力的程序員肯定氣的直接拉勾領英走起了，HR再招一羣新兵蛋子進來。項目歷史？遺留問題？設計思路？早就丟了。正好，推倒重來吧，周而復始。
這種惡習會侵蝕軟件開發流程，除非讓真正有能力、有經驗的軟件管理人員領導開發。裝作“敏捷”，哪怕是軟件開發的基礎設施也會毀於一旦。
很多時候，對於優秀開發者，他們離職不是因爲公司如何，是因爲管理者糟糕。讓人痛心疾首的是，很多公司放棄了井井有條的管理而選擇了所謂的敏捷。
所以，管理不規範的企業，不建議以敏捷開發的名頭進行企業的信息化建設，本身會做成四不像。以目前正在使用的力軟敏捷開發框架來說，其母公司是專門進行軟件開發的企業，自從進入敏捷開發以來，已經對產品進行了9年的升級，每一次升級都需要經過多次超前的規劃和論證，一個專業的開發公司尚且如此，普通企業就更不用說了。想要根據所謂產品經理的建議，再弄幾個程序員就搞出一個合格的敏捷產品，無異於異想天開。
而敏捷開發除了要具備完善的功能，還要有較高的靈活性，與其費力的做出一個未知的產品，不如老老實實按照規矩來，這樣可能纔是對企業是最有利方式。
一路走來數個年頭，感謝力軟敏捷開發框架的支持者與使用者，大家可以通過下面網址來了解詳情。
力軟敏捷開發框架官方網站：www.learun.cn
力軟敏捷開發框架官方免費體驗網站：http://www.learun.cn/Home/VerificationForm