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