真正的敏捷團隊會說：敏捷開發(fā)，其實一點也不“敏捷”。
初讀張愛玲的《紅玫瑰和白玫瑰》是在初中，15歲少不更事只看得出作者對活在情欲里男女的奚落和諷刺。后來經(jīng)歷的多了，發(fā)覺生活的瑣事無不應(yīng)驗了張愛玲的話，娶了白玫瑰，最終成了桌上的米飯粒；娶了紅玫瑰，也逃不過化成蚊子血的無奈。
當(dāng)我拿到敏捷的命題，腦海中浮現(xiàn)出的第一個念頭便是如此。傳統(tǒng)開發(fā)團隊花一場2-3萬的價格請敏捷教練做著培訓(xùn)，真正的敏捷團隊則會搖搖頭說：敏捷開發(fā)，其實一點也不“敏捷”。
敏捷開發(fā)不是開發(fā)方法
敏捷開發(fā)誕生的標(biāo)志，是2001年2月，由Martin Fowler，Jim Highsmith等17位軟件開發(fā)專家起草的敏捷宣言發(fā)表，敏捷聯(lián)盟成立。
從這個配圖，這個形式，你想到了什么？
20世紀90年代，軟件開發(fā)過程日益變重，開發(fā)效率降低，響應(yīng)速度變慢；21世紀，為了應(yīng)對快速變化的需求，縮短交付周期，“敏捷開發(fā)”應(yīng)運而生。
敏捷開發(fā)，從本質(zhì)上來說是一種思想，和共產(chǎn)主義宣言一樣——我們認同同樣的價值觀，也決心將這樣的價值觀發(fā)揚光大。而價值觀本身，是不具備可操作性的。所以， 敏捷開發(fā)常會和XP、SCRUM等名詞一同出現(xiàn)，前者是指導(dǎo)思想和原則，后者則是實打?qū)嵉拈_發(fā)流程和方法。
SCRUM作為目前實踐敏捷開發(fā)過程中，操作性較強、效果較為明顯的開發(fā)方法，在國內(nèi)外受到了普遍的推崇。所以在今后的系列文章中，我們將選擇SCRUM作為敏捷開發(fā)的具體開發(fā)方法，進行介紹。畢竟，我們不能去圍繞著一個虛無的概念和價值觀去討論和學(xué)習(xí)。
敏捷開發(fā)，可能一點都不“敏捷”
前幾日，我的一個朋友向我咨詢敏捷開發(fā)，言語中透露出對目前研發(fā)團隊現(xiàn)狀的擔(dān)憂，希望敏捷開發(fā)能夠改善團隊中的種種問題，提升開發(fā)效率。像我這位朋友這樣的情況，在國內(nèi)的研發(fā)團隊中絕不是個例。
【敏捷開發(fā)】因為頂著“敏捷”兩個字，常被作為解決開發(fā)效率問題的靈藥，其實這應(yīng)該是一個翻譯的問題。敏捷開發(fā)中的敏捷，更多是“靈活”“靈敏”之意。指的是對“變化”更加敏捷地響應(yīng)，而不是針對開發(fā)效率。
客觀上說，當(dāng)你的團隊由傳統(tǒng)瀑布流轉(zhuǎn)向敏捷開發(fā)的懷抱之時，你們的開發(fā)效率可能會被降低。
原因如下：
- 更多的時間被花費在溝通上：敏捷開發(fā)強調(diào)溝通，溝通的頻率和時長都會增加，以SCRUM為例：每一個迭代周期開始之前，都要對本次迭代的需求進行充分討論，例如需求的規(guī)模、優(yōu)先級等，對于新手團隊，這個討論極有可能是漫長低效的。
- 學(xué)習(xí)成本更高：敏捷開發(fā)團隊的內(nèi)部，并不做非常詳細的職責(zé)劃分。與之前的分層開發(fā)中各司其職的情況相比，對成員的綜合素質(zhì)要求更高，即所謂“全棧工程師”。（當(dāng)然，實際執(zhí)行的過程中會有所變通，不會真的要求每個人都是全棧工程師）但是相比之前，必然會帶來更多的學(xué)習(xí)成本，間接導(dǎo)致開發(fā)效率的下降。
- 收集數(shù)據(jù)花費更多的精力：敏捷開發(fā)的成熟度越高，要求的數(shù)據(jù)越多，數(shù)據(jù)的收集會帶來精力的消耗。假如工程師不能理解數(shù)據(jù)的意義，就會覺得自己在做無用功。
那我們還有必要去嘗試敏捷開發(fā)嗎？
方法本身是沒有對和錯的，紅玫瑰白玫瑰各有各的綻放。萬種風(fēng)情的佳人不見得能天長地久，時間久了怕只剩下“中年女人的艷俗”。男人陰影里沒有任何光澤的白玫瑰，也能在和裁縫的關(guān)系里綻放光彩。
要判斷敏捷開發(fā)是否合適，你得明白要用敏捷開發(fā)解決什么問題。很多企業(yè)想轉(zhuǎn)型敏捷開發(fā)的原因是“開發(fā)人員的效率低下，這么多人還完不成老板要開發(fā)的功能和速度”。就像我前文提到的朋友說他們也是出于這個目，想提高開發(fā)人員的效率，更快地更多地開發(fā)出功能。
我當(dāng)時就給這個朋友潑了涼水，因為敏捷開發(fā)不是用來解決所謂的“開發(fā)效率”問題的，提升開發(fā)效率可以從人的技能培養(yǎng)、流程優(yōu)化、工具改進等方面來提升，而跟敏捷開發(fā)本身沒太大關(guān)系。
開發(fā)團隊向敏捷轉(zhuǎn)型，本質(zhì)上屬于管理轉(zhuǎn)型的一部分。它不是提升團隊的工作效率，而是將整個研發(fā)體系，轉(zhuǎn)變成能夠更好響應(yīng)市場快速變化的模式。它解決的是企業(yè)效益最大化的問題。絕不可從開發(fā)人員完成功能數(shù)量和速度的層面來評價。
下面我們來看一個敏捷培訓(xùn)中常常出現(xiàn)的翻銅板游戲，這會幫助你理解敏捷開發(fā)：https://v.qq.com/iframe/player.html?vid=f0318pmtfnf&tiny=0&auto=0
敏捷開發(fā)并不能提升每個人的開發(fā)效率（翻銅板的速度），但是快速交付能夠避免一定的資源浪費，這能帶來一定程度的變快。而最大的區(qū)別，還是在于這種開發(fā)方式對于變化的響應(yīng)能力。
一個敏捷團隊，相比于傳統(tǒng)軟件開發(fā)團隊，最大的區(qū)別在于：
- 擁抱變化。傳統(tǒng)瀑布流開發(fā)方式，強調(diào)計劃。而計劃是死的，人是活的。計劃執(zhí)行過程中，有人休假、有人離開都會打破計劃的執(zhí)行，最終的結(jié)果就是delay。而敏捷開發(fā)的快速交付，可以擁抱這種變化。
- 快速響應(yīng)。市場環(huán)境的變化，越來越要求產(chǎn)品、服務(wù)的響應(yīng)及時。比如按照傳統(tǒng)方式，規(guī)劃半年一個版本，一旦需要調(diào)整需求，后面所有的計劃都得改變，會為項目管理帶來極大的挑戰(zhàn)，變化的成本奇高，多數(shù)情況下會因為多數(shù)人的反對而不了了之。
- 快速將功能推向市場變現(xiàn)。前幾年所有人口中的互聯(lián)網(wǎng)思維都離不開八個字“小步快跑，快速迭代”，而這幾個字的出處正是敏捷開發(fā)。我們不追求一次性推出大而全的產(chǎn)品，因為這讓試錯和調(diào)整的空間趨近于零。敏捷要做的，就是不停的推出產(chǎn)品，不停的調(diào)整。
- 在有限的資源條件下，做最值得做的事。因為Backlog的每一項都具有按唯一優(yōu)先級順序，都是已經(jīng)排好序了，敏捷要求逐項完成用戶故事，而不是全面開花。因為其評價結(jié)果是二值的，做完就是1，做不完就是0，沒有75%一說，因為做完了才能交付，做完了才能投向市場變現(xiàn)。什么事最值得做，什么事就優(yōu)先級最高，需要一個復(fù)雜的評定過程，在之后的文章我們會詳細說明。
最后
寫了這么多，想必各位看官已經(jīng)對敏捷開發(fā)的概念有了一定的理解。在之后的文章里，我們將會帶您全面地走進敏捷開發(fā)的世界，我們拒絕掉書袋，一切以實踐和可操作性為主。敏捷開發(fā)究竟是蚊子血還是朱砂痣，待你真正理解之時自會有答案。
同時，如果您對敏捷有何疑惑或者是獨到見解，我們也歡迎您在文章下方留言。
關(guān)于敏捷開發(fā)的問題將會邀請Worktile首席架構(gòu)師徐子巖，在系列結(jié)束之時為大家一一回答，敬請期待。
