敏捷開發能解決什么問題？

一. 什么是敏捷開發

敏捷開發宣言

敏捷宣言指出：

敏捷不是一種方法論，也不是一種軟件開發的具體方法，更不是一個框架或過程，而是一套價值觀和原則。

就是說，當你開發決策的時候，遵守了敏捷開發的價值觀和原則，不管你是不是用Scrum或者極限編程，那么都算敏捷開發。

二.敏捷開發解決了什么。

敏捷開發就是想解決破布模型這樣的重型軟件開發存在的問題，用一種輕量的、敏捷的開發方式來概算甚至是替代它。

瀑布模型的典型問題就是周期長，發布煩，變更難。

敏捷開發就是快速迭代，持續集成，擁抱變化。

三.怎么使用敏捷開發項目。

使用敏捷開發的具體步驟模擬：

1.客戶想要蓋一棟房子（初步的想法）。

2.產品經理和客戶進行了初步的溝通，把用戶的需求寫成了一個個用戶故事（用簡單的用戶故事代替繁重的需求文檔），例如：

作為一個上班族，我想要一個臥室，以便于休息；

作為一個家庭主婦，我想要一個廚房，以便于做飯。

3.施工人員根據用戶故事和客戶進一步溝通（客戶合作高于合同談判），然后對用戶故事進行設計和實現；

4.每個用戶故事開發時，還要給一個測試機器人編寫測試腳本，讓機器人可以自動測試（大量采用自動化測試），并且做好的用戶故事可以隨時被測試驗收（隨時發布，持續集成）；

5,每個 Sprint 四個星期時間（時間盒子，迭代時間固定）；

6.第一個 Sprint 搭了個草棚，一張床就是臥室，廁所就挖了一個坑，廚房還來不及搭建（每個 Sprint 會選擇高優先級的用戶故事），屋頂還在漏水（每個 Sprint 會定期發布，客戶可以隨時看到可用版本，即使還不完整）；

7. 第二個 Sprint 有了簡易廚房，同時修復了屋頂漏水的毛病（每個 Sprint 不僅完成用戶故事，還會修復 Bug）；

8.第三個 Sprint 升級成了小木屋，但是忘記加上窗戶（敏捷推崇自動化測試，但可能會測試不完備）；

9.第四個 Sprint 升級成了磚瓦房，窗戶也開好了，客戶可以入住。但是這時候客戶發現一家三口的話，完全不夠用，需要擴建到 3 個臥室。于是決定下個迭代改成 3 個臥室（響應變化高于遵循計劃）；

10.第五個 Sprint，升級成了 3 個臥室，升級過程中把廚房下水道弄壞了（迭代過程中可能會導致質量不穩定）；

11.第六個 Sprint，修復了下水道的問題，房子也裝修好了（迭代中不斷完善）；

12.客戶驗收使用（上線）。

用敏捷開發的方式，不再像瀑布模型那樣有嚴格的階段劃分，火災迭代中不斷完善；不在寫很多文檔，而是和客戶一起緊密合作；不再地址需求變更，而是即使響應變更；不在乎等到測試階段才發布，而是隨時發布，何不隨時可以看到東西。

敏捷開發的問題很會讓你明顯：全程需要客戶參與，由于測試相對少一些，問題也會多一些。

四.敏捷開發和瀑布開發的差異。

1.敏捷開發需求分析。

瀑布模型的一個重要階段就是需求分析，要有嚴謹的需求分析，產生詳盡的需求分析文檔。

敏捷開發的需求，主要是來源于一個個小的用戶故事，用戶故事通常是寫在卡片上的一句話，在 Sprint 的開發中，再去確認需求的細節。

比如一個用戶登錄網站的需求，在用戶故事里面就是一句話：

作為用戶，我想登錄網站，這樣可以方便瀏覽。

好處是減少了大量需求文檔的撰寫，可以早些進入開發。但這個對開發人員在需求理解和溝通的能力上要求更高了。

2. 敏捷開發是怎么做架構設計的？

瀑布模型在需求分析完了以后，就需要根據需求做架構設計。而在敏捷開發中，并不是基于完整的用戶需求開發，每個 Sprint 只做一部分需求，所以是一種漸進式的架構設計，當前 Sprint 只做適合當前需求的架構設計。

這種漸進式的架構設計，迭代次數一多，就會出現架構滿足不了需求的現象，產生不少冗余代碼，通常我們叫它技術債務，需要定期對系統架構進行重構。

3. 敏捷開發怎么保證項目質量的？

瀑布模型在編碼完成后，會有專門的階段進行測試，以保證質量。

敏捷開發的 Sprint 中，并沒有專門的測試階段，這就依賴于開發功能的同時，要編寫單元測試和集成測試代碼，用自動化的方式輔助完成測試。

相對來說，這種以自動化測試為主的方式，質量確實是要有些影響的。

微軟的 Windows 就是個很好的例子，在 Windows 10 之前，Windows 的開發模式是傳統的類瀑布模型，有很長一段測試的時間，質量有很好的保障，Windows 10 開始，采用的是敏捷開發的模式，每月發布更新，穩定性要稍微差一些。

4. 敏捷開發是怎么發布部署的？

瀑布模型通常在編碼結束后，開始部署測試環境，然后在測試階段定期部署測試環境。測試驗收通過后，發布部署到生產環境。

敏捷開發中，這種持續構建、持續發布的概念叫持續集成，因為整個過程都是全自動化的，每次完成一個任務，提交代碼后都可以觸發一次構建部署操作，腳本會拿最新的代碼做一次全新的構建，然后運行所有的單元測試和集成測試代碼，測試通過后部署到測試環境。

持續集成是一個非常好的實踐，極大的縮短和簡化了部署的流程，而且自動化測試的加入也很好的保證了部署產品的質量。前期搭建整個持續集成環境需要一定技術要求。

5. 敏捷開發的 Sprint 和迭代模型的迭代有什么區別？

增量模型和迭代模型，這兩種也是一種快速迭代的方式，那么敏捷開發和迭代模型的區別是什么呢？

我們假設有兩個團隊，都要實現一個簡單的用戶系統，一個團隊用迭代模型，一個團隊用敏捷開發（Scrum），一個迭代 /Sprint 的時間周期都是 2 周（10 個工作日）。

迭代模型所在的團隊，產品經理會先花 2 天時間去分析需求，寫成需求分析文檔，架構師會花 3 天時間來做設計，程序員會花 3 天時間編碼，測試再花 2 天時間去測試，最后上線用戶系統。

敏捷開發的團隊，Product Owner（類似于產品經理）會把需求拆分成了幾個簡單的用戶故事：用戶登錄、用戶注冊、找回密碼、修改資料，然后放到當前 Sprint 的 Backlog（任務清單），Team（開發團隊）成員開始從 Backlog 選擇用戶故事。

程序員 A 選了“用戶登錄”這個用戶故事，他會去找 Product Owner 確認需求細節，之后動手實現這個用戶故事。

功能完成后，同時程序員 A 還寫了單元測試代碼和集成測試代碼，對登錄的功能寫了自動化測試。完成后，通過持續集成工具測試和部署到測試環境。部署完成后，用戶登錄功能就可以進行使用了。

這個過程，程序員 A 可能花了 4 天時間，做完“用戶登錄”這個用戶故事之后，他又開始繼續選取“找回密碼”的用戶故事來做，4 天時間也完成了。

其他程序員也和程序員 A 一樣，他們也會從 Backlog 選擇一些用戶故事來做。

當團隊中第 1 個用戶故事部署完之后，測試人員就開始幫助測試，發現的 Bug 都提交到了 Backlog，程序員們在完成用戶故事后，開始著手修復這些 Bug，正好在最后 2 天都修復完成。

從上面的例子，你可以看出，迭代模型本質上是一個小瀑布模型，所以在一個迭代里面，需要完整的經歷從需求分析，到設計、編碼、測試這幾個完整的階段。

所以像瀑布模型一樣，剛開始測試的時候是不穩定的，到測試后期才逐步穩定下來，一般迭代前期也會相對輕松一點，而后期測試階段可能會時間很緊張。

敏捷開發的 Sprint 中，沒有嚴格的階段劃分，每個 Sprint 周期里面會完成多個用戶故事。在用戶故事的開發時，會針對用戶故事有編碼、自動化測試編碼。當一個用戶故事開發完成，即可通過持續集成自動發布到測試環境。

相對來收，敏捷開發中，整個 Sprint 的節奏是比較恒定，產品也是相對穩定的，即使用戶故事沒有完成，也不影響版本的發布。

因此，敏捷開發更注重軟件開發中人的作用，需要團隊成員以及客戶之間的緊密協作。

五.怎么選擇開發模型。

在實際工作中選擇敏捷開發,還是有些條件的：

1.團隊要小，人數超過一定規模就要分拆；

2.團隊成員之間要緊密協作，客戶也要自始至終深度配合；

3.領導們得支持。敏捷需要扁平化的組織結構，更少的控制，更多的發揮項目組成員的主動性；

4.寫代碼時要有一定比例的自動化測試代碼，要花時間搭建好源碼管理和持續集成環境。

所以在選擇敏捷開發這個問題上，你先要參考上面這些條件。

敏捷開發，其實對項目組成員的綜合素質的要求更高，做計劃要相對難一些。如果團隊大、客戶不配合、領導不支持，再好的敏捷方法實施也有困難。

如果現在不具備這些條件，就可以考慮NBA其中一些好的東西先用起來。比如說：每日例會，持續集成、自動化測試等。

敏捷開發 自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。