敏捷方法與模型

什麼是敏捷方法？

術語“敏捷方法”指的是在專案軟體開發生命週期中鼓勵持續開發和測試的過程。與瀑布模型不同，在敏捷軟體測試風格下，開發和測試操作是同時進行的。

敏捷方法與傳統軟體開發

將公司需求願景轉化為軟體解決方案的最簡單、最成功的方法之一是使用敏捷軟體開發方法。持續規劃、學習、改進、團隊協作、演化開發和早期交付都是用於定義敏捷軟體開發方法的術語。它增強了面對變化時的適應能力。

強調了敏捷軟體開發的四個基本價值觀。

  • 個人與團隊之間的互動勝過流程和工具。

  • 可工作的軟體勝過面面俱到的文件。

  • 客戶合作勝過合同談判。

  • 響應變化勝過遵循計劃。

本敏捷專案管理教程將教你如何 -

  • 什麼是敏捷方法，它是如何工作的？

  • 瀑布模型與敏捷模型

  • Scrum

  • 產品積壓

  • Scrum 方法

  • Scrum 方法流程

  • 極限程式設計 (XP) 是一種程式設計型別 (XP)

  • 極限程式設計階段 -

  • 水晶方法

  • 動態軟體開發方法 (DSDM)

  • 面向特徵的開發 (FDD)

  • 精益軟體開發

  • 看板

  • 靈活的指標

瀑布模型與敏捷模型

敏捷和瀑布模型是兩種不同的軟體開發方法。儘管它們的方法不同，但根據需求和專案型別，這兩種方法在某些時候都可能有效。

敏捷模型瀑布模型
敏捷方法的定義：敏捷方法提倡採用增量和迭代的方式進行軟體開發。瀑布模型 - 軟體開發以從頭到尾的邏輯順序進行。
在軟體工程中，敏捷過程被分解成開發人員工作的離散模型。設計過程未被分成多個模型。
為客戶提供儘早和定期檢查產品並做出決策和調整專案的機會。產品僅在專案結束後才向客戶可見。
產品僅在專案結束後才向客戶可見。與瀑布模型相比，敏捷模型被認為是非結構化的。
由於瀑布模型非常注重計劃，因此它們更安全。可以在短時間內完成小型專案。對於大型專案，很難預測開發時間。
可以估計和完成各種專案。可以在專案期間更正錯誤。
整個產品僅在最後進行測試。如果發現需求錯誤或需要進行更改，則必須從頭開始重新啟動專案。開發方法是迭代的，專案在短迭代（2-4 周）中完成。幾乎沒有計劃。
開發過程被劃分為多個階段，每個階段都比迭代大得多。每個階段都以對下一階段的完整摘要結束。軟體開發優先於文件。
文件是一項高度責任，它可以用來培訓員工並藉助另一個團隊更新軟體。每個迭代都有一個測試步驟。它允許在部署新功能或邏輯時實現迴歸測試。
在漫長的實施期後，所有設計的特性都會一次性提供。開發人員和測試人員協作。
測試人員與開發人員分開。在每次衝刺後完成使用者驗收。
在每次衝刺後完成使用者驗收。在專案結束時完成專案的使用者驗收。
需要與開發人員進行強有力的協作，以及對需求和計劃的聯合分析。開發人員不參與需求或計劃階段。通常，測試和編碼之間存在時間差距。

敏捷過程

敏捷測試採用多種敏捷方法，如下所述 -

Scrum

SCRUM 是一種敏捷開發方法，專注於基於團隊的開發環境中的任務管理。Scrum 來自橄欖球比賽中發生的行動。Scrum 提倡以小團隊的形式工作，並相信賦予開發團隊權力（例如 7 到 9 名成員）。敏捷和 Scrum 中有三個角色，其職責如下 -

  • Scrum Master

    • Master 負責組織團隊、主持衝刺會議以及消除開發障礙。

  • 產品負責人

    • 產品負責人負責建立產品積壓工作、對其進行優先順序排序並確保在每次迭代中交付功能。

  • Scrum 團隊

    • 團隊監督和組織他們的工作以完成衝刺或週期。

產品積壓

這是一個跟蹤需求的儲存庫，包括每個版本必須滿足的需求數量（使用者故事）。產品負責人應該跟蹤它並對其進行優先順序排序，並且應該將其提供給 scrum 團隊。團隊也可以請求包含、修改或刪除新需求。

Scrum 方法流程

以下是 scrum 測試流程 -

  • 衝刺是 scrum 的迭代。

  • 產品積壓工作是一個包含建立最終產品所需所有資訊的列表。

  • 在每個衝刺期間，從產品積壓工作中選擇最重要的使用者故事並將其轉換為衝刺積壓工作。

  • 團隊致力於已建立的衝刺積壓工作。

  • 團隊每天都會複查工作。

  • 團隊在衝刺結束後提供產品功能。

極限程式設計 (XP)

當客戶的需求或規範不斷變化，或者他們不確定系統如何工作時，極限程式設計方法會派上用場。它鼓勵在短開發週期中進行產品的多次“釋出”，從而提高系統的效率並提供一個檢查點，以便可以快速合併任何客戶需求。XP 以客戶為中心建立軟體。

使用故事來收集業務需求。停車場是所有這些故事的存放地。

釋出基於稱為迭代的較短週期，在這種方法下，迭代覆蓋 14 天的時間範圍。每次迭代都包括開發、單元測試和系統測試等步驟，每個步驟都會向程式新增小或大的功能。

極限程式設計階段

在敏捷 XP 方法中，定義了以下六個階段 -

計劃

  • 利益相關者和贊助商識別

  • 基礎設施需求

  • 資訊收集和安全相關資訊

  • 服務等級協議 (SLA) 及其條款

分析

  • 停車場裡的講故事

  • 在停車場中，對故事進行優先順序排序。

  • 透過擦洗估算故事

  • 迭代跨度是指一個人（時間）的次數

  • 開發和質量保證團隊都需要安排其資源。

設計

  • 任務分解

  • 為每個任務準備測試用例。

  • 迴歸自動化框架

執行

  • 編碼

  • 單元級測試

  • 執行手動測試用例。

  • 生成缺陷報告

  • 將回歸測試用例從手動轉換為自動。

  • 第二次迭代審查

  • 每次迭代結束時的審查

包裝

  • 小批次釋出

  • 迴歸測試

  • 演示和評估

  • 根據需求建立新故事。

  • 根據每次迭代後收到的反饋改進流程

結束

  • 試點計劃啟動

  • 培訓

  • 生產啟動

  • 保證服務水平協議

  • 檢查你的 SOA 方法。

  • 生產協助

有兩個故事板可用於每天監控工作，為了方便起見，它們列在下面。

  • 紙板故事

    • 這是一種常見的方法，用於以便利貼的形式將所有故事儲存在板上，以跟蹤日常 XP 活動。最好切換到線上形式，因為此手動過程需要更多工作和時間。

  • 線上故事板

    • 可以使用線上應用程式 Storyboard 儲存故事。它可以被多個團隊用於不同的目的。

水晶方法

三個原則支撐著水晶方法。

  • 制定階段包括建立開發團隊、進行初步可行性研究、生成初始策略以及微調開發技術。

  • 迴圈交付 - 在主要開發期間，產品將經歷兩個或多個交付週期進行開發。

    • 團隊更新和完善釋出策略。

    • 透過一個或多個程式測試集成周期來實現部分需求。

    • 將完全整合的產品提供給實際使用者。

    • 審查專案策略和使用的開發技術

  • 收尾 - 此階段包括將產品部署到使用者環境、部署後評估和反思等活動。

動態軟體開發方法 (DSDM)

DSDM 是一種敏捷專案交付方法，基於快速應用開發 (RAD) 的軟體開發方法。DSDM 的關鍵特徵是使用者必須積極參與，並且團隊擁有決策權。使用 DSDM，積極的重點轉向定期交付產品。DSDM 採用多種策略。

  • 時間盒

  • MoSCoW 規則

  • 原型設計

DSDM 專案有七個階段。

  • 專案前

  • 可行性研究

  • 業務調研

  • 功能模型迭代

  • 設計和構建迭代

  • 實施

  • 專案後

面向特徵的開發 (FDD)

此策略側重於“開發和構建”功能。與其他敏捷軟體工程方法不同，FDD 概述了必須針對每個功能獨立完成的非常精確和簡短的工作階段。它包括領域演練、設計檢查、提升到構建、程式碼檢查和設計。FDD 在考慮以下標準的情況下建立產品。

  • 領域物件建模

  • 基於功能的開發

  • 元件和類的所有權

  • 觀察團隊

  • 檢查

  • 配置管理

  • 定期結構

  • 顯示進度和結果。

精益軟體開發

精益軟體開發流程以“準時制生產”的理念為基礎。它的目標是加快軟體開發速度並降低成本。精益開發過程可以分為七個部分。

  • 減少浪費

  • 增強學習

  • 延遲承諾（儘可能晚地做出決定）

  • 準時交付

  • 提高團隊的自主性

  • 提高完整性

  • 最佳化整個流程。

看板

看板是一個日語詞，指的是一張卡片，其中包含完成產品在通往完成的每個步驟中所需的所有資訊。此框架或方法廣泛應用於軟體測試，尤其是在敏捷方法中。

看板與Scrum

下表突出顯示了看板和 Scrum 之間的主要區別 -

Scrum看板
在 Scrum 方法中，必須將測試分解，以便可以在一個衝刺中完成。不需要特定專案大小。
規定了按優先順序排序的產品待辦事項列表。不需要優先順序。
對於每次迭代，Scrum 團隊都會承諾完成一定量的工作。承諾是一種選擇。
需要使用燃盡圖。不需要特定專案大小。
每個衝刺後都會重置 Scrum 看板。看板是持久的。它限制了可以在工作流程狀態下進行的操作的數量。
無法向正在進行的迭代新增內容。可以根據容量新增專案。
間接限制 WIP。WIP 受到嚴格限制。
需要具有固定時間限制的迭代。具有時間限制的迭代是一種選擇。

敏捷指標

以下是一些可以收集的指標，以確保有效地使用敏捷 -

  • 阻力因子

    • 不有助於衝刺目標的工時

    • 減少共享資源的數量和非貢獻活動的數量以改善阻力因子。

    • 新估計可以透過阻力因子的百分比來改進，如下所示：新估計 =（舊估計 + 阻力因子）

  • 速度

    • 已轉換為衝刺就緒功能的積壓工作項（使用者故事）的數量。

  • 已引入的單元測試數量有所增加。

  • 完成每日構建所需的時間

  • 在先前版本或早期迭代中發現的錯誤

  • 生產缺陷洩漏

哪些敏捷專案管理工具最有效？

敏捷專案管理需要一個通用的解決方案，使您能夠使用看板和燃盡圖來衡量進度，同時還能管理任務和溝通訊息。因此，我們建議以下知名敏捷工具 -

  • Wrike

  • Monday.com

  • ClickUp

更新於： 2021年11月29日

2K+ 瀏覽量

啟動您的職業生涯

透過完成課程獲得認證

開始
廣告

© . All rights reserved.