小白科普：敏捷軟體開發（skycto JEEditor）

轉自：碼農翻身（微訊號：coderising）

敏捷的意思就是反應迅速，為什麼要反應迅速？看看那麼多996公司就知道了，市場變化越來越快，客戶要求越來越高，為了滿足使用者的需求，人家一個星期發一個版本，我們仨月才能憋出一個來，那還不被打的滿地找牙？

問題是如何才能反應迅速？  先來看一個場景：

1、殘酷的現實

軟體開發有一大難題就是 客戶腦子中的需求難於描述出來， 我們通常的應對方法是這樣：

先花上幾個月整理需求， 天天和客戶座談， 畫出幾百頁的流程圖， 寫出上千頁的文件， 最後把客戶都快搞暈了。

然後是詳細設計， 開發， 測試，我們強悍的技術團隊開始發動， 一切都嚴格按照計劃進行， 一切看起來都很完美， 看來專案馬上成功結束了！

但是客戶的驗收測試給了我們當頭一棒：
這個介面怎麼少了一個選項 ？
那個介面怎麼不能跳轉，那個功能需要給領導一個後門，還有，我的業務規則怎麼不能改？
什麼？ 在程式碼中寫死了？唉，你們做的系統啊，根本就不能用！

每個人都很鬱悶，幾個月的辛苦開發看來要付諸東流了。

從這個場景中能看出的是， 我們從客戶那裡得到的需求描述和需求文件， 其實離客戶真正想要的軟體還差的很遠。

在瀑布式的開發模式下，驗收測試發現的問題，要想改正代價是非常高昂的。

2、改進

一個想法自然而然就浮現出來： 為了避免到最後習慣性崩盤，能不能讓客戶經常性的做驗收測試？

讓他們經常性的去使用一個可以工作的軟體， 從而告訴我們那些地方還有欠缺 ？ 那些地方做錯了？  這樣我們可以迅速的修改， 這樣我們就會輕鬆多了 ！

我們可以把軟體開發劃分成一個個小的開發週期， 例如每個週期就兩三週時間， 在這兩週之內我們完成一個或幾個功能， 然後就讓使用者去試用， 有問題立刻反饋，在下一個開發週期馬上改掉。 這樣就可以逐步逼近客戶的最終目標。

這還帶來了一個額外的好處， 不用花費巨長的時間來分析，整理冗長的需求文件了。

聽起來很美是不是？  但是仔細想想這裡邊的問題很多。

1.  拋棄了冗長的需求文件， 但還是得描述需求啊

需要發明一個簡單的、主要用來促進客戶和開發團隊溝通的描述形式，  這個新的形式叫做 使用者故事， 這裡有個使用者故事的例子：

這是一個卡片， 背面還會記錄下針對需求的討論和驗收標準。

使用者故事主要彰顯的是： 誰做了什麼事， 帶來什麼商業價值。

2.  怎麼決定每個小開發週期（我們稱之為迭代吧）要開發的東西？

使用者故事得有估算， 得有大小， 太大了一個迭代開發不完 ， 還得拆分一下。
我們需要對需求按照優先順序進行排序， 按照優先順序從高到低的原則來開發。

3. 不要架構設計了嗎？

一上來就按優先順序選擇需求， 直接進入迭代開發， 把架構師撂在一邊，合適嗎？

架構工作肯定還是需要的，在正式的迭代週期開始之前需要架構設計， 但是和設計出面面俱到的架構設計不同， 我們更需要演進式的架構， 隨著迭代的推進而進化。

4. 那詳細設計怎麼辦？

在每個迭代開始的時候，團隊在一起把這些使用者故事給拆分成一個個小的任務， 這個拆分的過程就相當於詳細設計了。  對於一些特別複雜的，例如演算法， 當然可以寫文件，幫助大家理解。

5. 由於是迭代式開發， 這個迭代週期修改上一個迭代週期的程式碼在所難免， 怎麼保證不破壞原有的功能？ 總不能每次都手工重測一遍吧？

這個絕對是一大難點， 答案就是自動化的迴歸測試， 包括單元測試和功能測試。

開發人員寫程式碼的同時，也要寫下自動化的單元測試，   測試人員需要開發自動化的功能測試， 這樣一旦有了程式碼的修改，就可以執行它們， 檢查現有功能有沒有被破壞。

像持續整合這樣的基礎設施是必不可少的，每天，每小時，甚至每次程式碼提交都會觸發編譯，打包、部署、測試這樣的過程。

6.  這麼短的開發週期， 測試人員怎麼測試啊？

開發和測試需要同步進行， 當開發在澄清需求的時候， 測試需要參與， 當開發在編碼的時候， 測試人員在編寫測試用例，等到一個使用者故事開發完，馬上就可以投入測試。

7. 看來開發、測試之間需要緊密的協作， 它們之間怎麼溝通？

肯定是面對面的溝通， 有問題就跑到對方的座位那裡去問，大家的座位最好在一起， 扭頭就可以討論，   儘可能減少效率不高的電話、QQ/微信等工具的使用。

開發團隊每天都開一個15分鐘左右的站會， 展示自己的進展和計劃， 讓進度保持透明，  及時暴露問題，解決問題。

8. 客戶什麼時候可以做驗收測試？

隨時歡迎， 但是我們更傾向於迭代結束以後， 這時候功能會穩定下來， 我們會給客戶做一個演示， 告訴他這個迭代完成的工作， 邀請他也測試一下軟體， 給我們反饋。

當然客戶可能會發現問題， 甚至提出新的需求， 我們表示歡迎， 我們要和客戶合作，而不是對抗。

除了給客戶演示之外，我們自己還會反思一下，看看有那些地方做的好，要繼續保持；  那些地方做的不好， 要持續改進。

估計你也明白了，這種看起來很美的迭代化開發方法實施起來挺不容易的， 如果我們給它起個名字的話， 可以叫做：敏捷軟體開發。