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