AGILE方法是一種在整個(gè)項(xiàng)目的軟件開發(fā)生命周期中促進(jìn)開發(fā)和測試的連續(xù)迭代的實(shí)踐。 與Waterfall模型不同梢薪，開發(fā)和測試活動(dòng)都是并發(fā)的蹬铺。
敏捷軟件開發(fā)強(qiáng)調(diào)四個(gè)核心價(jià)值觀。
- 流程和工具之間的個(gè)人和團(tuán)隊(duì)互動(dòng)
- 綜合文檔
- 客戶協(xié)作
- 響應(yīng)遵循計(jì)劃的變更
敏捷和瀑布模型是軟件開發(fā)過程的兩種不同方法秉撇。 雖然它們的方法不同甜攀，但兩種方法有時(shí)都很有用，具體取決于項(xiàng)目的要求和類型琐馆。
| 敏捷模型 | 瀑布模型 |
|---|---|
| 敏捷方法提出了軟件設(shè)計(jì)的增量和迭代方法 | 軟件的開發(fā)從起點(diǎn)到終點(diǎn)順序進(jìn)行规阀。 |
| 敏捷過程分解為設(shè)計(jì)人員所處理的各個(gè)模型 | 設(shè)計(jì)過程不會(huì)分解為單個(gè)模型 |
| 客戶可以及早和頻繁地查看產(chǎn)品并對(duì)項(xiàng)目進(jìn)行決策和更改 | 客戶只能在項(xiàng)目結(jié)束時(shí)看到產(chǎn)品 |
| 與瀑布模型相比，敏捷模型被認(rèn)為是非結(jié)構(gòu)化的 | 瀑布模型更安全瘦麸，因?yàn)樗鼈兪侨绱说挠?jì)劃導(dǎo)向 |
| 小項(xiàng)目可以很快實(shí)施谁撼。 對(duì)于大型項(xiàng)目，很難估計(jì)開發(fā)時(shí)間滋饲。 | 各種項(xiàng)目都可以估算和完成厉碟。 |
| 可以在項(xiàng)目中間修復(fù)錯(cuò)誤喊巍。 | 只有在最后，整個(gè)產(chǎn)品才經(jīng)過測試墨榄。如果發(fā)現(xiàn)需求錯(cuò)誤或必須進(jìn)行任何更改玄糟，則項(xiàng)目必須從頭開始 |
| 開發(fā)過程是迭代的，項(xiàng)目在短（2-4）周的迭代中執(zhí)行袄秩。 規(guī)劃非常少阵翎。 | 開發(fā)過程是分階段的，階段比迭代大得多之剧。 每個(gè)階段都以下一階段的詳細(xì)描述結(jié)束郭卫。 |
| 文檔的優(yōu)先級(jí)低于軟件開發(fā) | 文檔是首要任務(wù)，甚至可以用于培訓(xùn)員工并與其他團(tuán)隊(duì)一起升級(jí)軟件 |
| 每次迭代都有自己的測試階段背稼。 它允許在每次釋放新函數(shù)或邏輯時(shí)執(zhí)行回歸測試贰军。 | 只有在開發(fā)階段之后，才會(huì)執(zhí)行測試階段蟹肘，因?yàn)閱为?dú)的部件不能完全正常工作词疼。 |
| 在迭代結(jié)束時(shí)進(jìn)行敏捷測試時(shí)，產(chǎn)品的可交付功能將交付給客戶帘腹。 新功能在發(fā)貨后即可使用贰盗。 當(dāng)您與客戶保持良好聯(lián)系時(shí)，它非常有用阳欲。 | 所有開發(fā)的功能都是在長期實(shí)施階段后立即交付的舵盈。 |
| 測試人員和開發(fā)人員一起工作 | 測試人員與開發(fā)人員分開工作 |
| 在每個(gè)sprint結(jié)束時(shí)，執(zhí)行用戶接受 | 用戶接受在項(xiàng)目結(jié)束時(shí)執(zhí)行球化。 |
| 它需要與開發(fā)人員密切溝通秽晚，共同分析需求和規(guī)劃 | 開發(fā)人員不參與需求和計(jì)劃過程。 通常筒愚，測試和編碼之間的時(shí)間延遲 |
SCRUM
SCRUM是一種敏捷開發(fā)方法赴蝇，專門用于如何在基于團(tuán)隊(duì)的開發(fā)環(huán)境中管理任務(wù)。 基本上巢掺，Scrum源自橄欖球比賽期間發(fā)生的活動(dòng)扯再。 Scrum相信授權(quán)開發(fā)團(tuán)隊(duì)和倡導(dǎo)者在小團(tuán)隊(duì)中工作（比如7到9名成員）。 它由三個(gè)角色組成址遇，其職責(zé)解釋如下
Scrum Master： 負(fù)責(zé)組建團(tuán)隊(duì)熄阻，沖刺會(huì)議并消除進(jìn)展障礙
產(chǎn)品負(fù)責(zé)人創(chuàng)建產(chǎn)品待辦事項(xiàng)，確定待辦事項(xiàng)的優(yōu)先級(jí)倔约，并負(fù)責(zé)在每次迭代時(shí)交付功能
Scrum團(tuán)隊(duì)：團(tuán)隊(duì)管理自己的工作并組織工作以完成sprint 或迭代秃殉。
- Scrum的每次迭代都稱為Sprint
- 產(chǎn)品待辦事項(xiàng)列表是輸入所有詳細(xì)信息以獲取最終產(chǎn)品的列表
- 在每個(gè)Sprint期間，選擇產(chǎn)品待辦事項(xiàng)的最高用戶故事并將其轉(zhuǎn)換為Sprint積壓
- 團(tuán)隊(duì)在定義的sprint backlog上工作
- 團(tuán)隊(duì)檢查日常工作
- 在sprint結(jié)束時(shí)，團(tuán)隊(duì)提供產(chǎn)品功能
極限編程（XP）
當(dāng)客戶不斷變化的需求或要求或者他們不確定系統(tǒng)的功能時(shí)钾军，極限編程技術(shù)非常有用鳄袍。 它主張?jiān)诙痰拈_發(fā)周期中頻繁“發(fā)布”產(chǎn)品，這本身就提高了系統(tǒng)的生產(chǎn)率吏恭，并且還引入了一個(gè)檢查點(diǎn)拗小，可以輕松實(shí)現(xiàn)任何客戶需求。 XP開發(fā)軟件使客戶保持目標(biāo)樱哼。
業(yè)務(wù)需求按故事收集哀九。 所有這些故事都存放在一個(gè)叫停車場的地方。
在這種類型的方法中搅幅，版本基于稱為迭代的較短周期阅束，跨度為14天的時(shí)間段。 每次迭代都包括編碼茄唐，單元測試和系統(tǒng)測試等階段息裸，在每個(gè)階段，將在應(yīng)用程序中構(gòu)建一些次要或主要功能沪编。
極限編程的階段：
Agile XP方法有6個(gè)階段呼盆，解釋如下：
規(guī)劃
確定利益相關(guān)者和贊助者
基礎(chǔ)設(shè)施要求
安全相關(guān)信息和收集
服務(wù)水平協(xié)議及其條件
分析
在停車場捕捉故事
優(yōu)先考慮停車場的故事
擦洗故事以供估算
定義迭代SPAN（時(shí)間）
開發(fā)和QA團(tuán)隊(duì)的資源規(guī)劃
設(shè)計(jì)
分解任務(wù)
測試每個(gè)任務(wù)的場景準(zhǔn)備
回歸自動(dòng)化框架
執(zhí)行
編碼
單元測試
執(zhí)行手動(dòng)測試場景
缺陷報(bào)告生成
將手動(dòng)轉(zhuǎn)換為自動(dòng)化回歸測試用例
中期迭代審查
迭代審核結(jié)束
Wrapping
小版本
回歸測試
演示和評(píng)論
根據(jù)需要開發(fā)新故事
基于迭代審核評(píng)論結(jié)束的流程改進(jìn)
關(guān)閉
試點(diǎn)發(fā)布
培訓(xùn)
生產(chǎn)發(fā)布
SLA擔(dān)保保證
查看SOA策略
生產(chǎn)支持
有兩個(gè)故事板可用于每天跟蹤工作，下面列出了這些故事板以供參考蚁廓。
-
故事紙板
- 這是一種傳統(tǒng)方式访圃，以便條形式收集董事會(huì)中的所有故事，以跟蹤每日XP活動(dòng)纳令。 由于此手動(dòng)活動(dòng)需要更多精力和時(shí)間，因此最好切換到在線表單克胳。
-
在線故事板
- 在線工具Storyboard可用于存儲(chǔ)故事平绩。 幾個(gè)團(tuán)隊(duì)可以將它用于不同的目的。
水晶方法論
Crystal Methodology基于三個(gè)概念
租船：此階段涉及的各種活動(dòng)包括創(chuàng)建開發(fā)團(tuán)隊(duì)漠另，執(zhí)行初步可行性分析捏雌，制定初始計(jì)劃和微調(diào)開發(fā)方法
-
循環(huán)交付：主要開發(fā)階段包括兩個(gè)或更多交付周期，在此期間
- 團(tuán)隊(duì)更新并優(yōu)化發(fā)布計(jì)劃
- 通過一個(gè)或多個(gè)程序測試集成迭代實(shí)現(xiàn)需求的子集
- 集成產(chǎn)品交付給真實(shí)用戶
- 審查項(xiàng)目計(jì)劃并采用發(fā)展方法
總結(jié)：在此階段執(zhí)行的活動(dòng)是部署到用戶環(huán)境中笆搓，執(zhí)行部署后審核和反射性湿。
動(dòng)態(tài)軟件開發(fā)方法（DSDM）
DSDM是一種用于軟件開發(fā)的快速應(yīng)用程序開發(fā)（RAD）方法，并提供靈活的項(xiàng)目交付框架满败。 DSDM的重要方面是要求用戶積極參與肤频，并且團(tuán)隊(duì)有權(quán)做出決策。 頻繁交付產(chǎn)品成為DSDM的主動(dòng)關(guān)注點(diǎn)算墨。 DSDM中使用的技術(shù)是
- 時(shí)間箱
- MoSCoW規(guī)則
- 原型
DSDM項(xiàng)目包括7個(gè)階段
- 前期項(xiàng)目
- 可行性研究
- 商業(yè)研究
- 功能模型迭代
- 設(shè)計(jì)和構(gòu)建迭代
- 實(shí)現(xiàn)
- 項(xiàng)目后處理
特征驅(qū)動(dòng)開發(fā)（FDD）
該方法主要圍繞“設(shè)計(jì)和構(gòu)建”特征宵荒。 與其他敏捷方法不同，F(xiàn)DD描述了必須按功能單獨(dú)完成的非常具體和短期的工作。 它包括領(lǐng)域演練报咳，設(shè)計(jì)檢查侠讯，促進(jìn)構(gòu)建，代碼檢查和設(shè)計(jì)暑刃。 FDD開發(fā)產(chǎn)品保持目標(biāo)中的事物
- 域?qū)ο蠼?/li>
- 按功能開發(fā)
- 組件/類所有權(quán)
- 特色團(tuán)隊(duì)
- 檢查
- 配置管理
- 定期構(gòu)建
- 進(jìn)展和結(jié)果的可見性
精益軟件開發(fā)
精益軟件開發(fā)方法基于“及時(shí)生產(chǎn)”原則厢漩。 它旨在提高軟件開發(fā)速度和降低成本。 精益開發(fā)可以歸納為七個(gè)步驟岩臣。
- 消除浪費(fèi)
- 擴(kuò)大學(xué)習(xí)
- 推遲承諾（盡可能晚決定）
- 提前交貨
- 賦予團(tuán)隊(duì)權(quán)力
- 建立誠信
- 優(yōu)化整體
看板
一張卡片包含了產(chǎn)品在每個(gè)階段完成所需的所有信息溜嗜。 該框架或方法在軟件測試方法中被廣泛采用，尤其是在敏捷測試中婿脸。
Scrum與看板
Scrum |看板
在scrum技術(shù)中粱胜，必須對(duì)測試進(jìn)行細(xì)分，以便在一個(gè)sprint中完成測試 | 沒有規(guī)定特定的項(xiàng)目大小
- 規(guī)定優(yōu)先產(chǎn)品隊(duì)列 | 優(yōu)先級(jí)是可選的
Scrum團(tuán)隊(duì)為迭代承諾了特定的工作量 | 承諾是可選的
Burndown圖表是規(guī)定的 | 沒有規(guī)定特定的項(xiàng)目大小
在每個(gè)sprint之間狐树，重置scrum板| 看板是持久的焙压。 它限制了工作流狀態(tài)中的項(xiàng)目數(shù)
它無法將項(xiàng)目添加到正在進(jìn)行的迭代中 | 只要容量可用，它就可以添加項(xiàng)目
WIP間接限制 | WIP直接限制
規(guī)定了時(shí)間盒迭代 | Timeboxed迭代可選
敏捷指標(biāo)：
可以收集以有效使用敏捷的度量標(biāo)準(zhǔn)是：
-
阻力因子
幾個(gè)小時(shí)的努力抑钟，這對(duì)沖刺目標(biāo)沒有貢獻(xiàn)
可以通過減少共享資源的數(shù)量來減少拖動(dòng)因子涯曲，從而減少非貢獻(xiàn)工作量
可以通過阻力系數(shù)的百分比來增加新的估計(jì)值 - 新估計(jì)值=（舊估計(jì)值+阻力系數(shù)）
-
速度
- 積壓（用戶故事）轉(zhuǎn)換為sprint的可發(fā)送功能的數(shù)量
沒有增加單元測試
完成每日構(gòu)建所需的時(shí)間間隔
在迭代或先前迭代中檢測到的錯(cuò)誤
生產(chǎn)缺陷泄漏
