文章目錄

• • 1.什么是敏捷開發(fā)？
  • 2.敏捷開發(fā)宣言
  • 3.站立會(huì)議的意義
  • 4.敏捷開發(fā)想解決什么問題？
  • 5.如果用敏捷的方式蓋房子
  • 6.敏捷開發(fā)和瀑布模型的差異
  • • （1）敏捷開發(fā)是怎么做需求分析的？
    • （2）敏捷開發(fā)是怎么做架構(gòu)設(shè)計(jì)的？
    • （3）敏捷開發(fā)怎么保證項(xiàng)目質(zhì)量的？
    • （4）敏捷開發(fā)是怎么發(fā)布部署的？
    • （5）敏捷開發(fā)的 Sprint 和迭代模型的迭代有什么區(qū)別？
  • 7.該不該選擇敏捷開發(fā)？
  • 8.總結(jié)

---

1.什么是敏捷開發(fā)？

• 敏捷開發(fā)，基于迭代的開發(fā)模型，它也強(qiáng)調(diào)快速交付，每次交付系統(tǒng)的部分功能，來保證客戶滿意度。在敏捷開發(fā)中，系統(tǒng)交付的周期稱之為·沖刺（Sprint）。
• • 敏捷開發(fā)，在每個(gè)迭代后，都應(yīng)該向客戶收集反饋，然后在后面的迭代中，酌情加入客戶反饋修改的內(nèi)容。
• 嚴(yán)格來說，敏捷開發(fā)并不算是一種開發(fā)模型，更像是框架或指南。有各種開發(fā)模型來實(shí)現(xiàn)敏捷開發(fā)，比如說·極限編程（Extreme programming），看板（Kanban）和 Scrum。

有人是這樣理解敏捷開發(fā)模型的：

• 敏捷開發(fā)就是 Scrum、極限編程；
• 敏捷開發(fā)就是每天站立會(huì)議、每?jī)芍芤粋€(gè) Sprint（字面意思是沖刺，可以理解為迭代）；
• 敏捷開發(fā)就是把需求變成故事，把故事寫在便簽上貼到白板，然后根據(jù)狀態(tài)移動(dòng)到不同的列；
• 敏捷開發(fā)就是用看板軟件來管理項(xiàng)目。

然而，這些是敏捷開發(fā)的真正含義嗎？

2.敏捷開發(fā)宣言

• 2001 初，17 位代表上述各種輕量級(jí)軟件開發(fā)過程流派的領(lǐng)軍人物聚集在一起，討論替代瀑布模型這種重量級(jí)軟件開發(fā)過程的新方法。
• 但是沒能達(dá)成一致，所以退而求其次，把大家都認(rèn)同的理念整理出來，也就是后來的敏捷宣言。這些人還一起成立了敏捷聯(lián)盟。
  
  我們?cè)倩仡^來看前面大家對(duì)敏捷的定義，其實(shí)都是在從方法論、工具等方面解釋敏捷開發(fā)。
• 敏捷宣言指出：

敏捷不是一種方法論，也不是一種軟件開發(fā)的具體方法，更不是一個(gè)框架或過程，而是一套價(jià)值觀和原則。
各種敏捷框架、方法論和工具，就像是“術(shù)”，告訴你敏捷開發(fā)的方式，而敏捷則是“道”，是一套價(jià)值觀和原則，指導(dǎo)你在軟件項(xiàng)目開發(fā)中做決策。

3.站立會(huì)議的意義

• 敏捷開發(fā)中流行的站立會(huì)議，主要目的是為了保證團(tuán)隊(duì)成員充分的溝通，遇到困難可以及時(shí)尋求幫助。但是如果每天的站立會(huì)議流于形式，并不能起到有效的目的，則應(yīng)該減少頻度，甚至取消換成其他方式。

• 要不要在你的項(xiàng)目開發(fā)中使用站立會(huì)議，判斷的依據(jù)就在于這樣做是不是符合敏捷的價(jià)值觀和原則。

• 也就是說，當(dāng)你開發(fā)做決策的時(shí)候，遵守了敏捷開發(fā)的價(jià)值觀和原則，不管你是不是用 Scrum 或者極限編程，那么都可以算是敏捷開發(fā)。

4.敏捷開發(fā)想解決什么問題？

• 瀑布模型的典型問題就是周期長(zhǎng)、發(fā)布煩、變更難，
• 敏捷開發(fā)就是快速迭代、持續(xù)集成、擁抱變化·

5.如果用敏捷的方式蓋房子

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

• 產(chǎn)品經(jīng)理和客戶進(jìn)行了初步的溝通，把用戶的需求寫成了一個(gè)個(gè)用戶故事（用簡(jiǎn)單的用戶故事代替繁重的需求文檔），例如：

作為一個(gè)上班族，我想要一個(gè)臥室，以便于休息；
作為一個(gè)家庭主婦，我想要一個(gè)廚房，以便于做飯。

• 施工人員根據(jù)用戶故事和客戶進(jìn)一步溝通（客戶合作高于合同談判），然后對(duì)用戶故事進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)；
• 每個(gè)用戶故事開發(fā)時(shí)，還要給一個(gè)測(cè)試機(jī)器人編寫測(cè)試腳本，讓機(jī)器人可以自動(dòng)測(cè)試（大量采用自動(dòng)化測(cè)試），并且做好的用戶故事可以隨時(shí)被測(cè)試驗(yàn)收（隨時(shí)發(fā)布，持續(xù)集成）；
• 每個(gè) Sprint 四個(gè)星期時(shí)間（時(shí)間盒子，迭代時(shí)間固定）；
• 第一個(gè) Sprint 搭了個(gè)草棚，一張床就是臥室，廁所就挖了一個(gè)坑，廚房還來不及搭建（每個(gè) Sprint 會(huì)選擇高優(yōu)先級(jí)的用戶故事），屋頂還在漏水（每個(gè) Sprint 會(huì)定期發(fā)布，客戶可以隨時(shí)看到可用版本，即使還不完整）；
• 第二個(gè) Sprint 有了簡(jiǎn)易廚房，同時(shí)修復(fù)了屋頂漏水的毛病（每個(gè) Sprint 不僅完成用戶故事，還會(huì)修復(fù) Bug）；
• 第三個(gè) Sprint 升級(jí)成了小木屋，但是忘記加上窗戶（敏捷推崇自動(dòng)化測(cè)試，但可能會(huì)測(cè)試不完備）；
• 第四個(gè) Sprint 升級(jí)成了磚瓦房，窗戶也開好了，客戶可以入住。但是這時(shí)候客戶發(fā)現(xiàn)一家三口的話，完全不夠用，需要擴(kuò)建到 3 個(gè)臥室。于是決定下個(gè)迭代改成 3 個(gè)臥室（響應(yīng)變化高于遵循計(jì)劃）；
• 第五個(gè) Sprint，升級(jí)成了 3 個(gè)臥室，升級(jí)過程中把廚房下水道弄壞了（迭代過程中可能會(huì)導(dǎo)致質(zhì)量不穩(wěn)定）；
• 第六個(gè) Sprint，修復(fù)了下水道的問題，房子也裝修好了（迭代中不斷完善）；
• 客戶驗(yàn)收使用（上線）。

用敏捷開發(fā)的方式，不再像瀑布模型那樣有嚴(yán)格的階段劃分，會(huì)在迭代中不斷完善；不再寫很多文檔，而是和客戶一起緊密合作；不再抵制需求變更，而是即時(shí)響應(yīng)變更；不再等到測(cè)試階段才發(fā)布，而是隨時(shí)發(fā)布，客戶隨時(shí)可以看到東西。

當(dāng)然，采用敏捷開發(fā)的模式也存在一些問題，例如全程需要客戶參與，由于測(cè)試相對(duì)少一些 ，問題也會(huì)相應(yīng)多一些。

6.敏捷開發(fā)和瀑布模型的差異

• 這些年敏捷開發(fā)，已經(jīng)逐步發(fā)展出一套 “Scrum + 極限編程 + 看板” 的最佳實(shí)踐，
• Scrum 主要用來管理·項(xiàng)目過程，
• 極限編程重點(diǎn)在工程實(shí)踐，
• 而看板將工作流可視化。

基于 ·Scrum 和極限編程的實(shí)踐，來對(duì)比一下敏捷開發(fā)模型和瀑布模型的差異

（1）敏捷開發(fā)是怎么做需求分析的？

瀑布模型的一個(gè)重要階段就是需求分析，要有嚴(yán)謹(jǐn)?shù)男枨蠓治?#xff0c;產(chǎn)生詳盡的需求分析文檔。而敏捷開發(fā)的需求，主要是來源于一個(gè)個(gè)小的用戶故事，用戶故事通常是寫在卡片上的一句話，在 Sprint 的開發(fā)中，再去確認(rèn)需求的細(xì)節(jié)。

比如一個(gè)用戶登錄網(wǎng)站的需求，在用戶故事里面就是一句話：
作為用戶，我想登錄網(wǎng)站，這樣可以方便瀏覽。

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

（2）敏捷開發(fā)是怎么做架構(gòu)設(shè)計(jì)的？

瀑布模型在需求分析完了以后，就需要根據(jù)需求做架構(gòu)設(shè)計(jì)。而在敏捷開發(fā)中，并不是基于完整的用戶需求開發(fā)，每個(gè) Sprint 只做一部分需求，所以是一種漸進(jìn)式的架構(gòu)設(shè)計(jì)，當(dāng)前 Sprint 只做適合當(dāng)前需求的架構(gòu)設(shè)計(jì)。

這種漸進(jìn)式的架構(gòu)設(shè)計(jì)，迭代次數(shù)一多，就會(huì)出現(xiàn)架構(gòu)滿足不了需求的現(xiàn)象，產(chǎn)生不少冗余代碼，通常我們叫它技術(shù)債務(wù)，需要定期對(duì)系統(tǒng)架構(gòu)進(jìn)行重構(gòu)。

（3）敏捷開發(fā)怎么保證項(xiàng)目質(zhì)量的？

瀑布模型在編碼完成后，會(huì)有專門的階段進(jìn)行測(cè)試，以保證質(zhì)量。在敏捷開發(fā)的 Sprint 中，并沒有專門的測(cè)試階段，這就依賴于開發(fā)功能的同時(shí)，要編寫單元測(cè)試和集成測(cè)試代碼，用自動(dòng)化的方式輔助完成測(cè)試。

相對(duì)來說，這種以自動(dòng)化測(cè)試為主的方式，質(zhì)量確實(shí)是要有些影響的。

微軟的 Windows 就是個(gè)很好的例子，在 Windows 10 之前，Windows 的開發(fā)模式是傳統(tǒng)的類瀑布模型，有很長(zhǎng)一段測(cè)試的時(shí)間，質(zhì)量有很好的保障，Windows 10 開始，采用的是敏捷開發(fā)的模式，每月發(fā)布更新，穩(wěn)定性要稍微差一些。

（4）敏捷開發(fā)是怎么發(fā)布部署的？

瀑布模型通常在編碼結(jié)束后，開始部署測(cè)試環(huán)境，然后在測(cè)試階段定期部署測(cè)試環(huán)境。測(cè)試驗(yàn)收通過后，發(fā)布部署到生產(chǎn)環(huán)境。

在敏捷開發(fā)中，這種持續(xù)構(gòu)建、持續(xù)發(fā)布的概念叫持續(xù)集成，因?yàn)檎麄€(gè)過程都是全自動(dòng)化的，每次完成一個(gè)任務(wù)，提交代碼后都可以觸發(fā)一次構(gòu)建部署操作，腳本會(huì)拿最新的代碼做一次全新的構(gòu)建，然后運(yùn)行所有的單元測(cè)試和集成測(cè)試代碼，測(cè)試通過后部署到測(cè)試環(huán)境。

持續(xù)集成是一個(gè)非常好的實(shí)踐，極大的縮短和簡(jiǎn)化了部署的流程，而且自動(dòng)化測(cè)試的加入也很好的保證了部署產(chǎn)品的質(zhì)量。前期搭建整個(gè)持續(xù)集成環(huán)境需要一定技術(shù)要求。

（5）敏捷開發(fā)的 Sprint 和迭代模型的迭代有什么區(qū)別？

我們假設(shè)有兩個(gè)團(tuán)隊(duì)，都要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的用戶系統(tǒng)，

• 一個(gè)團(tuán)隊(duì)用迭代模型，
• 一個(gè)團(tuán)隊(duì)用敏捷開發(fā)（Scrum），
• 一個(gè)迭代 /Sprint 的時(shí)間周期都是 2 周（10 個(gè)工作日）。

迭代模型所在的團(tuán)隊(duì)，產(chǎn)品經(jīng)理會(huì)先花 2 天時(shí)間去分析需求，寫成需求分析文檔，架構(gòu)師會(huì)花 3 天時(shí)間來做設(shè)計(jì)，程序員會(huì)花 3 天時(shí)間編碼，測(cè)試再花 2 天時(shí)間去測(cè)試，最后上線用戶系統(tǒng)。

再看敏捷開發(fā)的團(tuán)隊(duì)，Product Owner（類似于產(chǎn)品經(jīng)理）會(huì)把需求拆分成了幾個(gè)簡(jiǎn)單的用戶故事：用戶登錄、用戶注冊(cè)、找回密碼、修改資料，然后放到當(dāng)前 Sprint 的 Backlog（任務(wù)清單），Team（開發(fā)團(tuán)隊(duì)）成員開始從 Backlog 選擇用戶故事。

• 程序員 A 選了“用戶登錄”這個(gè)用戶故事，他會(huì)去找 Product Owner 確認(rèn)需求細(xì)節(jié)，之后動(dòng)手實(shí)現(xiàn)這個(gè)用戶故事。

• 功能完成后，同時(shí)程序員 A 還寫了單元測(cè)試代碼和集成測(cè)試代碼，對(duì)登錄的功能寫了自動(dòng)化測(cè)試。完成后，通過持續(xù)集成工具測(cè)試和部署到測(cè)試環(huán)境。部署完成后，用戶登錄功能就可以進(jìn)行使用了。

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

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

• 當(dāng)團(tuán)隊(duì)中第 1 個(gè)用戶故事部署完之后，測(cè)試人員就開始幫助測(cè)試，發(fā)現(xiàn)的 Bug 都提交到了 Backlog，程序員們?cè)谕瓿捎脩艄适潞?#xff0c;開始著手修復(fù)這些 Bug，正好在最后 2 天都修復(fù)完成。

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

• 所以像瀑布模型一樣，剛開始測(cè)試的時(shí)候是不穩(wěn)定的，到測(cè)試后期才逐步穩(wěn)定下來，一般迭代前期也會(huì)相對(duì)輕松一點(diǎn)，而后期測(cè)試階段可能會(huì)時(shí)間很緊張。

• 敏捷開發(fā)的 Sprint 中，沒有嚴(yán)格的階段劃分，每個(gè) Sprint 周期里面會(huì)完成多個(gè)用戶故事。在用戶故事的開發(fā)時(shí)，會(huì)針對(duì)用戶故事有編碼、自動(dòng)化測(cè)試編碼。當(dāng)一個(gè)用戶故事開發(fā)完成，即可通過持續(xù)集成自動(dòng)發(fā)布到測(cè)試環(huán)境。

• 相對(duì)來收，敏捷開發(fā)中，整個(gè) Sprint 的節(jié)奏是比較恒定，產(chǎn)品也是相對(duì)穩(wěn)定的，即使用戶故事沒有完成，也不影響版本的發(fā)布。

• 因此，敏捷開發(fā)更注重軟件開發(fā)中人的作用，需要團(tuán)隊(duì)成員以及客戶之間的緊密協(xié)作。

7.該不該選擇敏捷開發(fā)？

這些年，軟件工程中一些好的實(shí)踐，像持續(xù)集成、測(cè)試驅(qū)動(dòng)開發(fā)、結(jié)對(duì)編程、看板等都來自于敏捷開發(fā)。可以肯定，敏捷開發(fā)是一種非常好的軟件開發(fā)模式。

但在應(yīng)用上，也確實(shí)需要一些滿足一些條件才能用好，例如：

• 團(tuán)隊(duì)要小，人數(shù)超過一定規(guī)模就要分拆；
• 團(tuán)隊(duì)成員之間要緊密協(xié)作，客戶也要自始至終深度配合；
• 領(lǐng)導(dǎo)們得支持。敏捷需要扁平化的組織結(jié)構(gòu)，更少的控制，更多的發(fā)揮項(xiàng)目組成員的主動(dòng)性；
• 寫代碼時(shí)要有一定比例的自動(dòng)化測(cè)試代碼，要花時(shí)間搭建好源碼管理和持續(xù)集成環(huán)境。

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

因?yàn)椤っ艚蓍_發(fā)對(duì)項(xiàng)目成員綜合素質(zhì)要求更高，做計(jì)劃要相對(duì)難一些。如果團(tuán)隊(duì)大、客戶不配合、領(lǐng)導(dǎo)不支持，再好的敏捷方法也很難有效實(shí)踐起來。

如果你要實(shí)踐敏捷開發(fā)，建議先找個(gè)小項(xiàng)目進(jìn)行試點(diǎn)，能證明可行了，再進(jìn)一步推廣。有條件的話，可以和一些顧問公司合作，請(qǐng)人做專門的培訓(xùn)和指導(dǎo)。

如果不具備條件，應(yīng)該考慮先把其中一些好的實(shí)踐用起來，比如說持續(xù)集成、每日站會(huì)、自動(dòng)化測(cè)試等。

8.總結(jié)

瀑布模型面向的是過程，而敏捷開發(fā)面向的是人。敏捷開發(fā)要解決的，恰恰是瀑布模型中存在的一些問題。

最后，在要不要用敏捷開發(fā)這個(gè)問題上，不用過于糾結(jié)，看好敏捷開發(fā)，那就放心去用，覺得時(shí)機(jī)還不成熟、還不夠了解，就先試點(diǎn)或者只是先借鑒其好的實(shí)踐。

·軟件開發(fā)，最核心的是人，而不是用什么方法·，以前沒有敏捷開發(fā)只有瀑布模型的時(shí)候，也一樣誕生了大量偉大的軟件，像 Windows、Office。現(xiàn)在有敏捷開發(fā)，更多的是讓我們多了一些選擇。

附上一個(gè)鏈接補(bǔ)充：https://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ

參考：極客時(shí)間—軟件工程之美

總結(jié)

以上是生活随笔為你收集整理的105.敏捷开发模型的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。