AGILE方法是一種在整個項目的軟件開發(fā)生命周期中促進開發(fā)和測試的連續(xù)迭代的實踐。 與Waterfall模型不同，開發(fā)和測試活動都是并發(fā)的。
敏捷軟件開發(fā)強調(diào)四個核心價值觀。
- 流程和工具之間的個人和團隊互動
- 綜合文檔
- 客戶協(xié)作
- 響應(yīng)遵循計劃的變更
敏捷和瀑布模型是軟件開發(fā)過程的兩種不同方法。 雖然它們的方法不同，但兩種方法有時都很有用，具體取決于項目的要求和類型。
| 敏捷模型 | 瀑布模型 |
|---|---|
| 敏捷方法提出了軟件設(shè)計的增量和迭代方法 | 軟件的開發(fā)從起點到終點順序進行。 |
| 敏捷過程分解為設(shè)計人員所處理的各個模型 | 設(shè)計過程不會分解為單個模型 |
| 客戶可以及早和頻繁地查看產(chǎn)品并對項目進行決策和更改 | 客戶只能在項目結(jié)束時看到產(chǎn)品 |
| 與瀑布模型相比，敏捷模型被認為是非結(jié)構(gòu)化的 | 瀑布模型更安全，因為它們是如此的計劃導(dǎo)向 |
| 小項目可以很快實施。 對于大型項目，很難估計開發(fā)時間。 | 各種項目都可以估算和完成。 |
| 可以在項目中間修復(fù)錯誤。 | 只有在最后，整個產(chǎn)品才經(jīng)過測試。如果發(fā)現(xiàn)需求錯誤或必須進行任何更改，則項目必須從頭開始 |
| 開發(fā)過程是迭代的，項目在短（2-4）周的迭代中執(zhí)行。 規(guī)劃非常少。 | 開發(fā)過程是分階段的，階段比迭代大得多。 每個階段都以下一階段的詳細描述結(jié)束。 |
| 文檔的優(yōu)先級低于軟件開發(fā) | 文檔是首要任務(wù)，甚至可以用于培訓(xùn)員工并與其他團隊一起升級軟件 |
| 每次迭代都有自己的測試階段。 它允許在每次釋放新函數(shù)或邏輯時執(zhí)行回歸測試。 | 只有在開發(fā)階段之后，才會執(zhí)行測試階段，因為單獨的部件不能完全正常工作。 |
| 在迭代結(jié)束時進行敏捷測試時，產(chǎn)品的可交付功能將交付給客戶。 新功能在發(fā)貨后即可使用。 當(dāng)您與客戶保持良好聯(lián)系時，它非常有用。 | 所有開發(fā)的功能都是在長期實施階段后立即交付的。 |
| 測試人員和開發(fā)人員一起工作 | 測試人員與開發(fā)人員分開工作 |
| 在每個sprint結(jié)束時，執(zhí)行用戶接受 | 用戶接受在項目結(jié)束時執(zhí)行。 |
| 它需要與開發(fā)人員密切溝通，共同分析需求和規(guī)劃 | 開發(fā)人員不參與需求和計劃過程。 通常，測試和編碼之間的時間延遲 |
SCRUM
SCRUM是一種敏捷開發(fā)方法，專門用于如何在基于團隊的開發(fā)環(huán)境中管理任務(wù)。 基本上，Scrum源自橄欖球比賽期間發(fā)生的活動。 Scrum相信授權(quán)開發(fā)團隊和倡導(dǎo)者在小團隊中工作（比如7到9名成員）。 它由三個角色組成，其職責(zé)解釋如下
Scrum Master： 負責(zé)組建團隊，沖刺會議并消除進展障礙
產(chǎn)品負責(zé)人創(chuàng)建產(chǎn)品待辦事項，確定待辦事項的優(yōu)先級，并負責(zé)在每次迭代時交付功能
Scrum團隊：團隊管理自己的工作并組織工作以完成sprint 或迭代。
- Scrum的每次迭代都稱為Sprint
- 產(chǎn)品待辦事項列表是輸入所有詳細信息以獲取最終產(chǎn)品的列表
- 在每個Sprint期間，選擇產(chǎn)品待辦事項的最高用戶故事并將其轉(zhuǎn)換為Sprint積壓
- 團隊在定義的sprint backlog上工作
- 團隊檢查日常工作
- 在sprint結(jié)束時，團隊提供產(chǎn)品功能
極限編程（XP）
當(dāng)客戶不斷變化的需求或要求或者他們不確定系統(tǒng)的功能時，極限編程技術(shù)非常有用。 它主張在短的開發(fā)周期中頻繁“發(fā)布”產(chǎn)品，這本身就提高了系統(tǒng)的生產(chǎn)率，并且還引入了一個檢查點，可以輕松實現(xiàn)任何客戶需求。 XP開發(fā)軟件使客戶保持目標(biāo)。
業(yè)務(wù)需求按故事收集。 所有這些故事都存放在一個叫停車場的地方。
在這種類型的方法中，版本基于稱為迭代的較短周期，跨度為14天的時間段。 每次迭代都包括編碼，單元測試和系統(tǒng)測試等階段，在每個階段，將在應(yīng)用程序中構(gòu)建一些次要或主要功能。
極限編程的階段：
Agile XP方法有6個階段，解釋如下：
規(guī)劃
確定利益相關(guān)者和贊助者
基礎(chǔ)設(shè)施要求
安全相關(guān)信息和收集
服務(wù)水平協(xié)議及其條件
分析
在停車場捕捉故事
優(yōu)先考慮停車場的故事
擦洗故事以供估算
定義迭代SPAN（時間）
開發(fā)和QA團隊的資源規(guī)劃
設(shè)計
分解任務(wù)
測試每個任務(wù)的場景準(zhǔn)備
回歸自動化框架
執(zhí)行
編碼
單元測試
執(zhí)行手動測試場景
缺陷報告生成
將手動轉(zhuǎn)換為自動化回歸測試用例
中期迭代審查
迭代審核結(jié)束
Wrapping
小版本
回歸測試
演示和評論
根據(jù)需要開發(fā)新故事
基于迭代審核評論結(jié)束的流程改進
關(guān)閉
試點發(fā)布
培訓(xùn)
生產(chǎn)發(fā)布
SLA擔(dān)保保證
查看SOA策略
生產(chǎn)支持
有兩個故事板可用于每天跟蹤工作，下面列出了這些故事板以供參考。
-
故事紙板
- 這是一種傳統(tǒng)方式，以便條形式收集董事會中的所有故事，以跟蹤每日XP活動。 由于此手動活動需要更多精力和時間，因此最好切換到在線表單。
-
在線故事板
- 在線工具Storyboard可用于存儲故事。 幾個團隊可以將它用于不同的目的。
水晶方法論
Crystal Methodology基于三個概念
租船：此階段涉及的各種活動包括創(chuàng)建開發(fā)團隊，執(zhí)行初步可行性分析，制定初始計劃和微調(diào)開發(fā)方法
-
循環(huán)交付：主要開發(fā)階段包括兩個或更多交付周期，在此期間
- 團隊更新并優(yōu)化發(fā)布計劃
- 通過一個或多個程序測試集成迭代實現(xiàn)需求的子集
- 集成產(chǎn)品交付給真實用戶
- 審查項目計劃并采用發(fā)展方法
總結(jié)：在此階段執(zhí)行的活動是部署到用戶環(huán)境中，執(zhí)行部署后審核和反射。
動態(tài)軟件開發(fā)方法（DSDM）
DSDM是一種用于軟件開發(fā)的快速應(yīng)用程序開發(fā)（RAD）方法，并提供靈活的項目交付框架。 DSDM的重要方面是要求用戶積極參與，并且團隊有權(quán)做出決策。 頻繁交付產(chǎn)品成為DSDM的主動關(guān)注點。 DSDM中使用的技術(shù)是
- 時間箱
- MoSCoW規(guī)則
- 原型
DSDM項目包括7個階段
- 前期項目
- 可行性研究
- 商業(yè)研究
- 功能模型迭代
- 設(shè)計和構(gòu)建迭代
- 實現(xiàn)
- 項目后處理
特征驅(qū)動開發(fā)（FDD）
該方法主要圍繞“設(shè)計和構(gòu)建”特征。 與其他敏捷方法不同，F(xiàn)DD描述了必須按功能單獨完成的非常具體和短期的工作。 它包括領(lǐng)域演練，設(shè)計檢查，促進構(gòu)建，代碼檢查和設(shè)計。 FDD開發(fā)產(chǎn)品保持目標(biāo)中的事物
- 域?qū)ο蠼?/li>
- 按功能開發(fā)
- 組件/類所有權(quán)
- 特色團隊
- 檢查
- 配置管理
- 定期構(gòu)建
- 進展和結(jié)果的可見性
精益軟件開發(fā)
精益軟件開發(fā)方法基于“及時生產(chǎn)”原則。 它旨在提高軟件開發(fā)速度和降低成本。 精益開發(fā)可以歸納為七個步驟。
- 消除浪費
- 擴大學(xué)習(xí)
- 推遲承諾（盡可能晚決定）
- 提前交貨
- 賦予團隊權(quán)力
- 建立誠信
- 優(yōu)化整體
看板
一張卡片包含了產(chǎn)品在每個階段完成所需的所有信息。 該框架或方法在軟件測試方法中被廣泛采用，尤其是在敏捷測試中。
Scrum與看板
Scrum |看板
在scrum技術(shù)中，必須對測試進行細分，以便在一個sprint中完成測試 | 沒有規(guī)定特定的項目大小
- 規(guī)定優(yōu)先產(chǎn)品隊列 | 優(yōu)先級是可選的
Scrum團隊為迭代承諾了特定的工作量 | 承諾是可選的
Burndown圖表是規(guī)定的 | 沒有規(guī)定特定的項目大小
在每個sprint之間，重置scrum板| 看板是持久的。 它限制了工作流狀態(tài)中的項目數(shù)
它無法將項目添加到正在進行的迭代中 | 只要容量可用，它就可以添加項目
WIP間接限制 | WIP直接限制
規(guī)定了時間盒迭代 | Timeboxed迭代可選
敏捷指標(biāo)：
可以收集以有效使用敏捷的度量標(biāo)準(zhǔn)是：
-
阻力因子
幾個小時的努力，這對沖刺目標(biāo)沒有貢獻
可以通過減少共享資源的數(shù)量來減少拖動因子，從而減少非貢獻工作量
可以通過阻力系數(shù)的百分比來增加新的估計值 - 新估計值=（舊估計值+阻力系數(shù)）
-
速度
- 積壓（用戶故事）轉(zhuǎn)換為sprint的可發(fā)送功能的數(shù)量
沒有增加單元測試
完成每日構(gòu)建所需的時間間隔
在迭代或先前迭代中檢測到的錯誤
生產(chǎn)缺陷泄漏
