“搞死”敏捷的10種方法 | IDCF
來源：老鄧聊開發(fā) 作者：鄧等登燈?
敏捷已經(jīng)從“只適合小團(tuán)隊小項目”的污蔑中走出來，成為了“顯學(xué)”。人人都希望自己更加敏捷，沒有人敢說自己不敏捷，很多人都聲稱自己敏捷了。但敏捷真的帶來了價值嗎？我們今天就從另一個角度來談?wù)勅绾巍案闼馈泵艚荨?/span>
1、敏捷僅僅發(fā)生在開發(fā)團(tuán)隊
敏捷實踐僅僅在開發(fā)團(tuán)隊發(fā)生。業(yè)務(wù)團(tuán)隊還是把需求寫好后，扔到開發(fā)團(tuán)隊來，并命令開發(fā)團(tuán)隊必須在某個Deadline之前完成。在這種情況下，開發(fā)團(tuán)隊不直接對業(yè)務(wù)目標(biāo)負(fù)責(zé)，變成了工具人。這樣的開發(fā)團(tuán)隊和業(yè)務(wù)之間很少會有交流，更別說談判。他們只是按照業(yè)務(wù)團(tuán)隊命令行事，至于業(yè)務(wù)團(tuán)隊丟過來的需求是否合理，同樣的業(yè)務(wù)目標(biāo)下有無更好的解決方案，就不是開發(fā)團(tuán)隊考慮的事兒了。
這樣的軟件，實際上大部分成了并不懂開發(fā)技術(shù)的“產(chǎn)品經(jīng)理”設(shè)計出來的產(chǎn)物，開發(fā)人員只是負(fù)責(zé)填上代碼讓機(jī)器能夠工作。開發(fā)團(tuán)隊脫離業(yè)務(wù)，也無法建立更適合業(yè)務(wù)的模型。最后產(chǎn)品變?yōu)橐粋€畸形怪，缺乏合理的抽象、設(shè)計。最后越來越僵化。
2、沒有或很少自動化測試
自動化測試，特別是TDD（測試驅(qū)動開發(fā)）的作用，被IT行業(yè)嚴(yán)重低估了。自動化測試是可維護(hù)、高質(zhì)量軟件的基石，甚至可以說比生產(chǎn)代碼還要重要。目前我們行業(yè)整體上對于自動化測試極其缺乏，大多數(shù)團(tuán)隊都不具備自動化測試能力，或者有一定能力但以時間緊為借口拒絕自動化測試。
失去了自動化測試的保護(hù)，我們就缺乏勇氣對爛代碼進(jìn)行持續(xù)重構(gòu)，因為誰也無法預(yù)料改幾行代碼會不會帶來新的Bug。沒有了持續(xù)重構(gòu)，我們就會欠下越來越多的技術(shù)債，這會不斷降低我們對業(yè)務(wù)的響應(yīng)能力。沒有自動化測試，我們?nèi)巳饣貧w測試速度變得讓人難以忍受，我們要不舍棄部分外在質(zhì)量，僅僅測試“改動”部分（這實際上很難）；要不就拉長回歸測試時間。過長的回歸測試時間又會讓我們傾向于批量進(jìn)行測試，以減少回歸測試次數(shù)。這樣就降低了我們的敏捷性，把持續(xù)交付變成了批量交付，敏捷變成了瀑布。
實現(xiàn)自動化測試的關(guān)鍵在于開發(fā)者測試，而不是雇傭更多測試人員編寫腳本。因為測試人員編寫的測試運行速度慢、對程序員反饋慢。而提高代碼質(zhì)量我們需要的是對程序的快速反饋，自動化測試寫得越早、運行速度越快，越有利于程序員及時獲得反饋。最早編寫自動化測試的方式就是TDD：在寫生產(chǎn)代碼之前編寫。最快運行自動化測試的方式是單元測試。
3、不注重代碼質(zhì)量
經(jīng)常有人會說：我們現(xiàn)在時間很緊，先做出來再說，先不管質(zhì)量。很多人認(rèn)為質(zhì)量是可以犧牲的，但其實不是。你寫出來低質(zhì)量的代碼是因為你只會寫出這種質(zhì)量的，給你多的時間你也無法提高。要提高代碼質(zhì)量只能是提高人的技能。而絕大多數(shù)人（別看別人，說的就是你，也包括我）都無法一次性寫出高質(zhì)量的代碼。因此我們要不斷重構(gòu)，而要支持重構(gòu)，又必須有足夠快的自動化測試。
另外，低質(zhì)量的代碼并不會帶來高效能。除非你程序簡單到只有幾行代碼，否則隨著代碼復(fù)雜度提升，低質(zhì)量代碼遲早就會拖你的后腿。我們行業(yè)中很多人稱呼別人的爛代碼是“屎山”，但其實大多數(shù)人自己也是這個屎山的貢獻(xiàn)者。
軟件之所以稱為“軟”件，是因為我們期望它容易改變。對于不大會改變的，我們會把它做成“硬”件。對于低質(zhì)量的代碼，我們會越來越難以對其進(jìn)行改變。一個小小的改動可能導(dǎo)致大量Bug產(chǎn)生，找到需要改變的地方就頗為耗費人力，更別提改變后還需要大量人肉回歸測試了。在這種軟件質(zhì)量下，我們還能敏捷起來嗎？
4、不注重需求質(zhì)量
俗話說“Garbage in Garbage out”。軟件需求是軟件的輸入，沒有良好的需求，必然產(chǎn)生不了良好的軟件。而我們這個行業(yè)，優(yōu)秀的產(chǎn)品經(jīng)理比優(yōu)秀的程序員更加稀缺。畢竟，程序員編寫的東西再爛，它也有個基本原則：可以跑。而大多產(chǎn)品經(jīng)理，編寫的垃圾還沒有個標(biāo)準(zhǔn)去衡量。
有些產(chǎn)品經(jīng)理醉心于設(shè)計方案，而忽略用戶價值，導(dǎo)致設(shè)計一堆白象功能（耗費巨大卻沒有用）；有些產(chǎn)品經(jīng)理對需求分析不完整，考慮場景不全面，導(dǎo)致產(chǎn)品Bug層出不窮；有些產(chǎn)品經(jīng)理不分輕重緩急，導(dǎo)致團(tuán)隊浪費大量時間在價值不高的事項上。有些產(chǎn)品經(jīng)理只會講大故事，無法把需求拆分到足夠小，這樣交付批量就大，降低敏捷性。
5、以事兒來定人
以事兒來定人的典型就是項目制。人都是從屬于某個技術(shù)團(tuán)隊，比如Android組、iOS組、后臺組之類的。等有了項目，你張三、李四、王五過來，你們做。到了中間覺得趕不上了，再加趙六什么的。項目團(tuán)隊里，人員變化頻繁，磨合成本高。而敏捷里面的很多實踐，都是基于團(tuán)隊的。比如團(tuán)隊速率、回顧改進(jìn)、人員流動。對于頻繁變化的團(tuán)隊，很多實踐就很難持續(xù)下去，即使做出了一些成績，也很快面臨項目結(jié)束，團(tuán)隊解散，導(dǎo)致知識丟失。
以事兒來定人的好處是節(jié)約了人力成本，所以外包團(tuán)隊都傾向于使用，特別是人頭外包的。這樣可以最大化企業(yè)收益。但對于企業(yè)IT或者互聯(lián)網(wǎng)，一般來說對業(yè)務(wù)的響應(yīng)才是第一優(yōu)先級要考慮的。不能對業(yè)務(wù)進(jìn)行響應(yīng)，再低的成本也沒有意義。
敏捷的實踐基本上都圍繞團(tuán)隊、圍繞人進(jìn)行。以事兒為目標(biāo)設(shè)人，就違背了敏捷的原則，最后必然是導(dǎo)致不敏捷。
6、不注重提高人的能力
很多IT企業(yè)不注重對人的培養(yǎng)。不少人會說，我辛辛苦苦培養(yǎng)好了，轉(zhuǎn)頭就讓別的企業(yè)挖走了。如果出現(xiàn)這種情況，企業(yè)應(yīng)該反思：為何優(yōu)秀的人才我都留不?。侩y道你只配使用劣質(zhì)人力？其實就像程序員抱怨寫不出高質(zhì)量代碼是因為時間緊，企業(yè)抱怨培養(yǎng)人會被挖走本質(zhì)是自己不知道如何培養(yǎng)人。
企業(yè)把員工看作是隨時可替換的螺絲釘，表面上說員工是最大財富?？蓪嶋H上卻對人進(jìn)行工具化。軟件開發(fā)是一個設(shè)計過程，面臨的是不確定的、易變的。不是搬磚頭。開發(fā)者不是生產(chǎn)者，而是設(shè)計者。對于設(shè)計者，替換成本比較高。
我們行業(yè)996讓員工沒有時間學(xué)習(xí)，35歲退休實際上就是壓榨了員工10來年的本能。大家全憑本能干活，缺乏優(yōu)秀的實踐。實際上就是在低水平地不斷重復(fù)。缺乏人的能力的提高，敏捷不過是空中樓閣。
7、敏捷就是工具
有些企業(yè)把敏捷轉(zhuǎn)型簡單定義為工具平臺的使用。用了看板、開了站會就是敏捷了。使用了CI/CD工具就是DevOps了。買了個自動化測試平臺就是自動化測試了。敏捷宣言第一條：“個體和互動勝于流程和工具”。流程和工具可以幫助我們更快更好完成任務(wù)，但更重要的是個體和互動。僅僅購買一堆工具就宣稱自己敏捷了，這是舍本逐末。
8、人員復(fù)用
IT人員不好找這是行業(yè)難題，當(dāng)然這個難題也是行業(yè)自己整出來的（不注重培養(yǎng)）。在這種情況下，不少企業(yè)就搞矩陣式結(jié)構(gòu)。橫向是產(chǎn)品或者項目，縱向是職能團(tuán)隊。很多人員在不同的產(chǎn)品和項目里共用。
這樣的結(jié)果是看起來員工工作很飽和。但由于員工在多個產(chǎn)品中復(fù)用，必然導(dǎo)致他有多個代辦事項列表，而每個待辦事項列表的優(yōu)先級并不一致。這樣他就必須在多個事項之間不斷切換，從而導(dǎo)致了他效率的損失。還有因為他有多個事項要處理，實際上又會造成其他人員對他的等待。所以人員復(fù)用實際上是用降低業(yè)務(wù)響應(yīng)換取了人員成本效率。
9、模塊復(fù)用
當(dāng)企業(yè)增長到一定程度，有了多個產(chǎn)品線、業(yè)務(wù)線，就會自然發(fā)現(xiàn)有些業(yè)務(wù)似乎是類似的。本能地出于成本考慮，就會想把這部分抽出來，交給一個專門的團(tuán)隊維護(hù)，讓用到這個模塊/服務(wù)的業(yè)務(wù)調(diào)用他們。這樣聽起來很不錯，多個業(yè)務(wù)/產(chǎn)品線不用考慮某一個模塊/服務(wù)的使用，只管調(diào)用就是了。但實際上由于這樣抽出來的模塊/服務(wù)往往并不穩(wěn)定，并不能滿足未來其他業(yè)務(wù)的需求。
因此在以后的開發(fā)過程中，很多產(chǎn)品/業(yè)務(wù)線都需要對這個共享模塊進(jìn)行修改以滿足自身需求。而由于對共享模塊的維護(hù)已經(jīng)交給了獨立團(tuán)隊，那么在價值流的交接中，就會出現(xiàn)了團(tuán)隊之間的交接，這種交接成本要大很多。這就降低了產(chǎn)品/業(yè)務(wù)線的響應(yīng)性。
10、團(tuán)隊內(nèi)嚴(yán)格職能劃分
團(tuán)隊內(nèi)分成若干職能：Android開發(fā)、iOS開發(fā)、測試、后端開發(fā)、數(shù)據(jù)庫、運維、架構(gòu)設(shè)計、BA、安全。恨不得一個蘿卜一個坑。導(dǎo)致的結(jié)果就是在從需求到交付的流程中，產(chǎn)生多次工作交接。我們知道，交接就會導(dǎo)致等待，等待就是浪費。
因此，為保持團(tuán)隊敏捷性，應(yīng)該減少交接。另外，職能的嚴(yán)格劃分會導(dǎo)致工作量嚴(yán)重不均衡，相互之間不能補位。當(dāng)某個環(huán)節(jié)產(chǎn)生堆積的時候，其他人也只能干看，甚至不斷生產(chǎn)讓其堆積更加嚴(yán)重。
