白話敏捷軟件開發(fā)
最近有不少初學(xué)者問什么是敏捷軟件開發(fā)， 我發(fā)現(xiàn)一兩句話也說不清楚， 索性寫一篇文章。
敏捷的意思就是反應(yīng)迅速， 為什么要反應(yīng)迅速? 看看那么多996公司就知道了， 市場變化越來越快，客戶要求越來越高， 為了滿足用戶的需求， 人家一個(gè)星期發(fā)一個(gè)版本， 我們仨月才能憋出一個(gè)來 ， 那還不被打的滿地找牙?
問題是如何才能反應(yīng)迅速? 先來看一個(gè)場景：
一、殘酷的現(xiàn)實(shí)
軟件開發(fā)有一大難題就是客戶腦子中的需求難于描述出來， 我們通常的應(yīng)對(duì)方法是這樣：
先花上幾個(gè)月整理需求， 天天和客戶座談， 畫出幾百頁的流程圖， 寫出上千頁的文檔， 最后把客戶都快搞暈了。
然后是詳細(xì)設(shè)計(jì)， 開發(fā)， 測試， 我們強(qiáng)悍的技術(shù)團(tuán)隊(duì)開始發(fā)動(dòng)， 一切都嚴(yán)格按照計(jì)劃進(jìn)行， 一切看起來都很完美， 看來項(xiàng)目馬上成功結(jié)束了!
但是客戶的驗(yàn)收測試給了我們當(dāng)頭一棒： 這個(gè)界面怎么少了一個(gè)選項(xiàng) ? 那個(gè)界面怎么不能跳轉(zhuǎn) ， 那個(gè)功能需要給領(lǐng)導(dǎo)一個(gè)后門， 還有， 我的業(yè)務(wù)規(guī)則怎么不能改? 什么? 在代碼中寫死了? 唉，你們做的系統(tǒng)啊， 根本就不能用 !
每個(gè)人都很郁悶， 幾個(gè)月的辛苦開發(fā)看來要付諸東流了。
從這個(gè)場景中能看出的是， 我們從客戶那里得到的需求描述和需求文檔， 其實(shí)離客戶真正想要的軟件還差的很遠(yuǎn)。
在瀑布式的開發(fā)模式下，驗(yàn)收測試發(fā)現(xiàn)的問題，要想改正代價(jià)是非常高昂的。
二、改進(jìn)
一個(gè)想法自然而然就浮現(xiàn)出來： 為了避免到最后習(xí)慣性崩盤，能不能讓客戶經(jīng)常性的做驗(yàn)收測試?
讓他們經(jīng)常性的去使用一個(gè)可以工作的軟件， 從而告訴我們那些地方還有欠缺 ? 那些地方做錯(cuò)了? 這樣我們可以迅速的修改， 這樣我們就會(huì)輕松多了 !
我們可以把軟件開發(fā)劃分成一個(gè)個(gè)小的開發(fā)周期， 例如每個(gè)周期就兩三周時(shí)間， 在這兩周之內(nèi)我們完成一個(gè)或幾個(gè)功能， 然后就讓用戶去試用， 有問題立刻反饋，在下一個(gè)開發(fā)周期馬上改掉。 這樣就可以逐步逼近客戶的最終目標(biāo)。
這還帶來了一個(gè)額外的好處， 不用花費(fèi)巨長的時(shí)間來分析，整理冗長的需求文檔了。
聽起來很美是不是? 但是仔細(xì)想想這里邊的問題很多。
1. 拋棄了冗長的需求文檔， 但還是得描述需求啊
需要發(fā)明一個(gè)簡單的、主要用來促進(jìn)客戶和開發(fā)團(tuán)隊(duì)溝通的描述形式， 這個(gè)新的形式叫做用戶故事， 這里有個(gè)用戶故事的例子：
這是一個(gè)卡片， 背面還會(huì)記錄下針對(duì)需求的討論和驗(yàn)收標(biāo)準(zhǔn)。
用戶故事主要彰顯的是： 誰做了什么事， 帶來什么商業(yè)價(jià)值。
2. 怎么決定每個(gè)小開發(fā)周期(我們稱之為迭代吧)要開發(fā)的東西?
用戶故事得有估算， 得有大小， 太大了一個(gè)迭代開發(fā)不完 ， 還得拆分一下。
我們需要對(duì)需求按照優(yōu)先級(jí)進(jìn)行排序， 按照優(yōu)先級(jí)從高到低的原則來開發(fā)。
3. 不要架構(gòu)設(shè)計(jì)了嗎?
一上來就按優(yōu)先級(jí)選擇需求， 直接進(jìn)入迭代開發(fā)， 把架構(gòu)師撂在一邊，合適嗎?
架構(gòu)工作肯定還是需要的，在正式的迭代周期開始之前需要架構(gòu)設(shè)計(jì)， 但是和設(shè)計(jì)出面面俱到的架構(gòu)設(shè)計(jì)不同， 我們更需要演進(jìn)式的架構(gòu)， 隨著迭代的推進(jìn)而進(jìn)化。
4. 那詳細(xì)設(shè)計(jì)怎么辦?
在每個(gè)迭代開始的時(shí)候，團(tuán)隊(duì)在一起把這些用戶故事給拆分成一個(gè)個(gè)小的任務(wù)， 這個(gè)拆分的過程就相當(dāng)于詳細(xì)設(shè)計(jì)了。 對(duì)于一些特別復(fù)雜的，例如算法， 當(dāng)然可以寫文檔，幫助大家理解。
5. 由于是迭代式開發(fā)， 這個(gè)迭代周期修改上一個(gè)迭代周期的代碼在所難免， 怎么保證不破壞原有的功能? 總不能每次都手工重測一遍吧?
這個(gè)絕對(duì)是一大難點(diǎn)， 答案就是自動(dòng)化的回歸測試， 包括單元測試和功能測試。
開發(fā)人員寫代碼的同時(shí)，也要寫下自動(dòng)化的單元測試， 測試人員需要開發(fā)自動(dòng)化的功能測試， 這樣一旦有了代碼的修改，就可以運(yùn)行它們， 檢查現(xiàn)有功能有沒有被破壞。
像持續(xù)集成這樣的基礎(chǔ)設(shè)施是必不可少的， 每天，每小時(shí)，甚至每次代碼提交都會(huì)觸發(fā)編譯，打包、部署、測試這樣的過程。
6. 這么短的開發(fā)周期， 測試人員怎么測試啊?
開發(fā)和測試需要同步進(jìn)行， 當(dāng)開發(fā)在澄清需求的時(shí)候， 測試需要參與， 當(dāng)開發(fā)在編碼的時(shí)候， 測試人員在編寫測試用例，等到一個(gè)用戶故事開發(fā)完，馬上就可以投入測試。
7. 看來開發(fā)、測試之間需要緊密的協(xié)作， 它們之間怎么溝通?
肯定是面對(duì)面的溝通， 有問題就跑到對(duì)方的座位那里去問，大家的座位最好在一起， 扭頭就可以討論， 盡可能減少效率不高的電話、QQ/微信等工具的使用。
開發(fā)團(tuán)隊(duì)每天都開一個(gè)15分鐘左右的站會(huì)， 展示自己的進(jìn)展和計(jì)劃， 讓進(jìn)度保持透明， 及時(shí)暴露問題，解決問題。
8. 客戶什么時(shí)候可以做驗(yàn)收測試?
隨時(shí)歡迎， 但是我們更傾向于迭代結(jié)束以后， 這時(shí)候功能會(huì)穩(wěn)定下來， 我們會(huì)給客戶做一個(gè)演示， 告訴他這個(gè)迭代完成的工作， 邀請(qǐng)他也測試一下軟件， 給我們反饋。
當(dāng)然客戶可能會(huì)發(fā)現(xiàn)問題， 甚至提出新的需求， 我們表示歡迎， 我們要和客戶合作，而不是對(duì)抗。
除了給客戶演示之外，我們自己還會(huì)反思一下，看看有那些地方做的好，要繼續(xù)保持; 那些地方做的不好， 要持續(xù)改進(jìn)。
估計(jì)你也明白了，這種看起來很美的迭代化開發(fā)方法實(shí)施起來挺不容易的， 如果我們給它起個(gè)名字的話， 可以叫做：敏捷軟件開發(fā)。
【本文為51CTO專欄作者“徐磊”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)devopshub獲取授權(quán)】
