自適應軟體開發 - 快速指南

什麼是敏捷？

從文學角度來看，“敏捷”一詞指的是能夠快速輕鬆地行動的人，或者能夠快速清晰地思考和行動的人。在商業領域，“敏捷”用於描述計劃和開展工作的方式，在這種方式中，人們理解到根據需要進行更改是工作的重要組成部分。商業“敏捷性”意味著公司始終能夠應對市場變化。

在軟體開發中，“敏捷”一詞被用來表示“能夠應對變化——來自需求、技術和人員的變化”。

敏捷宣言

敏捷宣言由一個軟體開發團隊於 2001 年釋出，強調了開發團隊的重要性、適應不斷變化的需求和客戶參與。

敏捷宣言是：

我們正在透過實踐和幫助他人實踐來發現更好的軟體開發方法。透過這項工作，我們開始重視：

個體和互動高於流程和工具。
可工作的軟體高於詳盡的文件。
客戶合作高於合同談判。
響應變化高於遵循計劃。

也就是說，雖然右邊的專案也有其價值，但我們更重視左邊的專案。

敏捷的特性

以下是敏捷的特性：

敏捷軟體開發中的敏捷性關注於整個團隊的文化，擁有賦能的、自組織的多學科、跨職能團隊。
它促進共享責任和問責制。
促進有效的溝通和持續的協作。
全團隊方法避免了延誤和等待時間。
頻繁和持續的交付確保了快速的反饋，反過來又使團隊能夠與需求保持一致。
協作有助於及時結合不同的視角來進行實施、缺陷修復和適應變化。
進度是持續的、可持續的和可預測的，強調透明度。

敏捷方法

敏捷方法的早期實現包括 Rational 統一過程、Scrum、Crystal Clear、極限程式設計、自適應軟體開發、特性驅動開發和動態系統開發方法 (DSDM)。在 2001 年敏捷宣言釋出後，這些方法現在統稱為敏捷方法。

在本教程中，我們將學習敏捷方法——**自適應軟體開發**。

什麼是自適應軟體開發？

自適應軟體開發是向自適應實踐轉變的舉動，它放棄了複雜系統和複雜環境中的確定性實踐。自適應軟體開發專注於協作和學習作為構建複雜系統的技術。它從快速應用開發 (RAD) 和演化生命週期的最佳實踐中發展而來。自適應軟體開發隨後擴充套件到包括用於管理的自適應方法，用推測代替了規劃。

Jim Highsmith 於 2000 年出版了一本關於自適應軟體開發的書。用 Highsmith 的話說：

“自適應軟體開發像演化模型一樣是迴圈的，其階段名稱‘推測、協作、學習’反映了日益複雜的系統的不可預測領域。自適應開發在其演化遺產的基礎上進一步發展，主要體現在兩個方面：首先，它明確地用湧現取代了確定性；其次，它超越了生命週期的變化，實現了管理風格的更深層次的變化。”

SDLC 模型 - 演變

軟體開發生命週期 (SDLC) 模型是一個框架，它描述了在軟體開發專案的每個階段執行的活動。

在軟體開發生命週期中，活動分為五個階段：

**需求收集** - 收集要開發的軟體的需求。這些需求將使用客戶/使用者能夠理解的語言來表達。建議使用特定領域的術語。
**分析** - 從實現的角度分析收集到的需求，並編寫軟體規格說明以涵蓋功能需求和非功能需求。
**設計** - 此階段涉及根據選擇的開發技術確定軟體架構和實現細節。
**構建** - 在此階段，開發程式碼、進行單元測試、整合、整合測試並生成構建。
**測試** - 在此階段對構建的軟體進行功能測試。這還包括對非功能需求的測試。

執行這些活動有兩種方法：

**規定性** - SDLC 模型將為您提供以框架定義的規定方式執行活動的方法。
**自適應性** - SDLC 模型將使您能夠靈活地執行活動，同時需要遵循某些規則。敏捷方法大多遵循這種方法，每種方法都有其規則。但是，採用自適應或敏捷方法並不意味著軟體開發是在不遵循任何紀律的情況下進行的。這會導致混亂。

您需要理解，我們不能說某個特定的 SDLC 模型好或壞。它們各有優缺點，因此適用於某些特定環境。

為專案選擇 SDLC 模型時，您需要了解：

您的組織環境
您的技術環境
您的團隊構成
您的客戶環境

例如，如果軟體開發是可預測的，則可以使用規定性方法。另一方面，如果軟體開發是不可預測的，即需求並非完全已知，或者開發團隊先前沒有接觸過當前領域或技術等，那麼自適應方法是最佳選擇。

在以下部分，您將瞭解在整個行業軟體開發專案執行過程中發展起來的、最普遍的 SDLC 模型。您還將瞭解每個模型的優缺點以及它們適用的環境。

SDLC - 瀑布模型

瀑布模型是一個廣為人知、易於理解且常用的一種經典 SDLC 模型。它由 Royce 於 1970 年提出，至今仍在業內各個組織中作為一種通用的軟體開發方法。

在瀑布模型中，每個生命週期階段只有在前面生命週期階段完成後才能開始。因此，它是一個沒有反饋迴圈的線性模型。

瀑布模型 - 優點

瀑布模型的優點是：

易於理解，易於使用。
為缺乏經驗的開發團隊提供結構。
里程碑清晰易懂。
設定需求穩定性。
非常適合管理控制（計劃、監控、報告）。
當質量比成本或進度更重要時效果很好。

瀑布模型 - 缺點

瀑布模型的缺點或不足之處是：

理想化 - 它與現實並不完全匹配。
不切實際 - 無法期望在專案早期獲得準確的需求。
無法反映更常見的探索性開發的迭代特性。
難以且代價高昂地進行更改。
軟體只在專案結束時交付。因此：
- 延遲發現嚴重缺陷。
- 可能交付過時的需求。
管理開銷很大，對於小型團隊和專案來說可能代價高昂。
每個階段都需要經驗豐富的資源 - 分析師、設計師、開發人員、測試人員。
測試只在開發完成後才開始，測試人員不參與任何早期階段。
跨職能團隊的專業知識未被共享，因為每個階段都是獨立執行的。

何時使用瀑布模型？

如果滿足以下條件，可以使用瀑布模型：

需求非常明確。
產品定義穩定。
技術易於理解。
現有產品的全新版本。
將現有產品移植到新平臺。
擁有結構化跨職能團隊的大型組織。
組織內部以及與客戶之間的溝通渠道已經建立。

演化原型模型

在使用演化原型模型的軟體開發中，開發人員在需求階段構建原型。然後，終端使用者評估原型並提供反饋。反饋可以是對原型的更正或附加功能。根據反饋，開發人員進一步完善原型。

因此，產品透過原型→反饋→改進的原型迴圈不斷發展，因此得名演化原型。當用戶對產品的功能和工作方式滿意時，原型程式碼將提升到最終產品交付所需的標準。

演化原型模型 - 優點

演化原型模型的優點或優勢是：

客戶/終端使用者可以根據收集到的需求檢視原型，從而視覺化系統需求。
開發人員從客戶那裡學習，因此不存在關於領域或生產環境的歧義。
允許靈活的設計和開發。
與原型的互動會激發人們對額外需要功能的意識。
意外的需求和需求變更很容易適應。
產生穩定和可見的進展跡象。
交付準確且可維護的最終產品。

演化原型模型 - 缺點

演化原型模型的缺點或不足之處如下：

傾向於在程式碼和修復開發中放棄結構化開發，儘管這並非模型規定的內容。
該模型因其快速簡便的方法而聲名狼藉。
整體可維護性可能被忽略。
客戶可能會要求交付原型作為最終產品，而不給開發人員機會執行最後一步，即標準化最終產品。
專案可能會無限期地持續下去（不斷出現範圍蔓延），管理層可能不會接受。

何時使用演化原型模型？

您可以使用演化原型模型：

當需求不穩定或需要澄清時
作為瀑布模型的需求澄清階段
開發使用者介面
進行短期演示
進行新的或原創開發
實施新技術

SDLC - 迭代增量模型

在迭代增量模型中，最初構建的是整個系統的部分實現，以便它處於可交付狀態。然後新增增強的功能。修復先前交付中存在的任何缺陷，並交付可工作的產品。重複此過程，直到完成整個產品開發。這些過程的重複稱為迭代。在每次迭代結束時，都會交付產品增量。

迭代增量模型 - 優點

迭代增量模型的優點或優勢是：

您可以首先開發優先順序最高的需求。
初始產品交付速度更快。
客戶可以儘早獲得重要的功能。
降低初始交付成本。
每次釋出都是產品增量，因此客戶始終擁有可用的工作產品。
客戶可以對每個產品增量提供反饋，從而避免在開發結束時出現意外。
可以輕鬆適應需求變化。

迭代增量模型——缺點

迭代增量模型的缺點如下：

需要有效規劃迭代。
需要高效的設計，以確保包含所需的功能併為以後的更改提供準備。
需要預先定義一個完整且功能齊全的系統，以便定義增量。
需要定義良好的模組介面，因為有些模組的開發時間遠早於其他模組。
完整系統的總成本並不降低。

何時使用迭代增量模型？

可以在以下情況下使用迭代增量模型：

大多數需求在一開始就已知曉，但預計會隨著時間的推移而發展。
需求已按優先順序排序。
需要快速交付基本功能。
專案具有漫長的開發週期。
專案採用新技術。
團隊對該領域不熟悉。

SDLC - 快速應用開發模型

快速應用開發 (RAD) 模型具有以下階段：

需求規劃階段——在需求規劃階段，需要進行研討會以結構化方式討論業務問題。
使用者描述階段——在使用者描述階段，使用自動化工具從使用者那裡捕獲資訊。
構建階段——在構建階段，在時間盒內使用程式碼生成器、螢幕生成器等生產力工具，採用“做完為止”的方法。
切換階段——在切換階段，執行系統安裝、使用者驗收測試和使用者培訓。

快速應用開發模型——優點

快速應用開發模型的優點如下：

減少週期時間和提高生產力，團隊成員減少意味著成本降低。
客戶在整個週期中的參與最大限度地降低了無法實現客戶滿意度和業務價值的風險。
重點轉向所見即所得 (WYSIWYG) 模式下的程式碼。這使得對正在構建的內容是否正確有了清晰的瞭解。
使用建模概念來捕獲有關業務、資料和流程的資訊。

快速應用開發模型——缺點

快速應用開發模型的缺點如下：

加速的開發過程必須快速響應使用者。
可能永遠無法完成的風險。
難以與遺留系統一起使用。
開發人員和客戶必須致力於在縮短的時間範圍內進行快速活動。

何時使用快速應用開發模型？

可以在以下情況下使用快速應用開發模型：

使用者可以參與整個生命週期。
專案可以限定時間。
功能可以增量交付。

儘管快速應用開發模型的優點得到了認可，但在行業中很少使用。

SDLC - 螺旋模型

螺旋模型在瀑布模型中添加了風險分析和 RAD 原型設計。每個週期都包含與瀑布模型相同的步驟序列。

螺旋模型有四個象限。讓我們詳細討論一下。

象限 1 - 確定目標、備選方案和約束條件

目標——功能、效能、硬體/軟體介面、關鍵成功因素等。
備選方案——構建、重用、購買、分包等。
約束條件——成本、進度、介面等。

象限 2 - 評估備選方案，識別和解決風險

根據確定的目標和約束條件研究備選方案。
識別風險，例如缺乏經驗、新技術、時間緊迫等。
透過評估風險對專案的影響，確定所需的緩解和應急計劃並實施這些計劃來解決已識別的風險。始終需要監控風險。

象限 3 - 開發下一級產品

典型活動包括：

建立設計
審查設計
開發程式碼
檢查程式碼
測試產品

象限 4 - 規劃下一階段

典型活動包括：

制定專案計劃
制定配置管理計劃
制定測試計劃
制定安裝計劃

螺旋模型——優點

螺旋方法的優點如下：

在不涉及太多成本的情況下，儘早指示風險。
由於使用了快速原型工具，使用者可以儘早檢視系統。
首先開發關鍵的高風險功能。
設計不必完美。
使用者可以密切參與所有生命週期步驟。
及早且頻繁地獲得使用者的反饋。
經常評估累積成本。

螺旋模型——缺點

螺旋方法的缺點如下：

可能難以定義目標，可驗證的里程碑表明已準備好繼續進行下一次迭代。
在規劃、重置目標、進行風險分析和原型設計上花費的時間可能是額外開銷。
對於小型或低風險專案，評估風險所花費的時間可能過長。
對於新團隊成員來說，螺旋模型難以理解。
需要風險評估專業知識。
螺旋可能無限期地繼續。
開發人員必須在非開發階段活動期間重新分配。

何時使用螺旋模型？

可以在以下情況下使用螺旋模型：

建立原型是合適的。
風險評估很重要。
專案屬於中高風險。
使用者不確定他們的需求。
需求複雜。
產品線是新的。
預計在探索過程中會發生重大變化。
由於潛在的業務變化，長期專案承諾不明智。

SDLC - 敏捷方法

敏捷方法基於敏捷宣言，本質上是自適應的。敏捷方法確保：

團隊協作。
客戶協作。
持續不斷的溝通。
響應變化。
可執行產品的準備就緒。

出現了多種敏捷方法，促進了具有時間盒迭代的迭代和增量開發。儘管敏捷方法是自適應的，但不能繞過特定方法的規則，因此需要有條不紊地實施。

敏捷方法——優點

敏捷方法的優點如下：

儘早且頻繁地釋出。
適應不斷變化的需求。
客戶和開發人員之間的日常溝通。
圍繞積極進取的個人構建專案。
自組織團隊。
簡潔性，專注於當前所需。
不為未來構建或使程式碼負擔過重。
定期反思以調整行為以提高效率。

敏捷方法——缺點

螺旋方法的缺點如下：

可能無法獲得客戶。
團隊應該有經驗才能遵循方法的規則。
需要適當的規劃才能快速確定需要在迭代中交付的功能。
團隊應具備估算能力和談判能力。
團隊應具備有效的溝通能力。
新團隊可能無法自行組織。
需要紀律才能在時間盒迭代中開發和交付。
設計需要保持簡單易維護，因此需要有效的技能設計。

何時使用敏捷方法？

可以在以下情況下使用敏捷方法：

應用程式對時間要求很高。
範圍有限且不太正式（正在進行將敏捷方法擴充套件到更大專案的嘗試，其中對一些敏捷方法進行了一定的擴充套件）。
組織採用有條不紊的方法。

自適應軟體開發 - 演變

早期的 SDLC 模型更側重於穩定性、可預測性和遞減收益的實踐。網際網路平臺等行業一直在轉向提高回報率的環境、不可預測的、非線性的和快速的方法。

自適應軟體開發 (ASD) 已經發展起來以解決這些問題。它側重於將湧現作為管理層最重要的因素，以增強管理產品開發的能力。

用 Jim Highsmith 的話說，“自適應軟體開發框架是基於多年使用傳統軟體開發方法的經驗，在快速應用開發 (RAD) 技術的諮詢、實踐和撰寫以及與高科技軟體公司合作管理其產品開發實踐的基礎上建立的”。

瀑布模型的特點是線性化和可預測性，反饋很少。它可以看作是計劃→構建→實施的序列。

螺旋模型等演化生命週期模型將確定性方法轉向自適應方法，採用計劃→構建→修改週期。

然而，從業者的思維方式仍然是確定性的，長期可預測性轉向短期可預測性。RAD 等演化生命週期模型的實踐被發現不太確定性。

自適應生命週期

自適應模型是從不同的角度構建的。雖然像演化模型一樣是迴圈的，但階段的名稱反映了日益複雜的系統的不可預測性。

自適應開發在其演化遺產的基礎上進一步發展，主要有兩個方面：

它明確地用湧現代替了確定性。
它超越了生命週期的變化，對管理風格進行了更深層次的改變。

自適應軟體開發生命週期中的三個階段是：

推測——推測取代了確定性的計劃，產品規範的規劃或專案管理任務的規劃。
協作——協作代表在以下方面取得平衡：
- 以傳統專案管理的意義進行管理，以及
- 建立和維護湧現所需的協作環境。

協作活動構建產品，跟上環境變化的步伐。

學習——學習的目標是開發人員和客戶都使用每個開發週期的結果來了解下一個方向。

自適應軟體開發 - 概念

本章將闡述自適應軟體開發的各種概念。

複雜自適應系統 (CAS) 理論

聖菲研究所的布萊恩·阿瑟及其同事利用複雜自適應系統 (CAS) 理論，徹底改變了人們對物理學、生物學、進化論和經濟學的理解。

布萊恩·阿瑟花了二十多年時間，試圖讓主流經濟學家相信，他們根植於遞減收益、均衡和確定性動力學等基本假設的觀點，已經不足以理解現實。新的世界是遞增收益、不穩定性和無法確定因果關係的世界。

這兩個世界在行為、風格和文化上都大相徑庭。它們需要：

不同的管理技術
不同的策略
不同的理解

複雜的軟體開發

隨著軟體應用範圍的爆炸式增長，即使是軟體開發組織也積累了與上述類似的矛盾。

一個世界代表的是確定性開發，它源於植根於穩定性和可預測性基礎（用阿瑟的話來說就是遞減收益）的管理實踐。
第二個世界代表的是那些從遞減收益環境轉向遞增收益環境的行業，這些環境是不可預測的、非線性的和快速的。

為了解決第二個世界的問題，吉姆·海史密斯提出了一個框架——自適應軟體開發，它與確定性軟體開發不同。

自適應軟體開發側重於解決複雜系統的問題：

自適應軟體開發用於開發生命週期。
自適應管理技術要求與傳統的專案管理實踐不同的思維方式。

在本教程中，您可以理解這兩種實現。

自適應軟體開發 (ASD) 基於兩個視角：

基於複雜自適應系統 (CAS) 理論的概念視角，如本章第一節所述。
基於實踐視角的：
- 多年來使用確定性軟體開發方法的經驗。
- 關於快速應用開發 (RAD) 技術的諮詢、實踐和寫作；以及與高科技軟體公司合作管理其產品開發。

本章將闡述自適應軟體開發的概念視角。

複雜自適應系統 (CAS) 概念

複雜自適應系統 (CAS) 理論包含許多概念。自適應軟體開發基於其中的兩個概念：

湧現
複雜性

湧現

在複雜的軟體產品開發專案中，結果本質上是不可預測的。然而，成功的產品總是從這種環境中湧現出來。

這可以透過複雜自適應系統 (CAS) 理論中闡述的湧現來實現。這可以透過一個簡單的例子來理解，例如鳥類的叢集行為。

當您觀察一群鳥時，您會注意到：

每隻鳥都試圖
- 保持與環境中其他物體（包括其他鳥類）的最小距離。
- 與其鄰近的鳥類匹配速度。
- 向其鄰近鳥類的感知質心移動。
群體沒有行為規則。唯一的規則是關於個體鳥類的行為。
然而，存在一種湧現行為，即鳥類的叢集。當偏離軌道的鳥急於追趕時，鳥群會在障礙物周圍分開，並在另一側重新組合。

這表明自適應開發中最困難的思維模式轉變的需求：從管理和組織個體自由的方式轉變為創造性的新秩序從自發的自組織中不可預測地湧現出來的概念。

除了開發之外，湧現也是從管理角度來看最重要的概念。

複雜性

在軟體開發的背景下，複雜性是指：

團隊成員，例如開發人員、客戶、供應商、競爭對手和股東，他們的數量和速度。
規模和技術複雜性。

自適應軟體開發實踐

自適應軟體開發對軟體管理實踐提供了不同的視角。在下面的章節中，您可以瞭解兩個重要的實踐：質量和 RAD，它們都對需求收集產生影響。

您可以在本教程的“自適應軟體開發實踐”一章中找到所有實踐的詳細資訊。

質量

在複雜的環境中，“一次做對”的古老做法行不通，因為您無法預測一開始什麼才是正確的。您需要目標是產生正確的價值。然而，在複雜的環境中，價值組成部分（如範圍（特性、效能、缺陷級別）、時間表和資源）的組合和排列如此之多，以至於永遠不會有最佳價值。因此，重點轉向在競爭市場中交付最佳價值。

RAD 實踐

RAD 實踐通常涉及以下組合：

進化式生命週期
客戶焦點小組、JAD 會議、技術評審
限時專案管理
持續軟體工程
擁有作戰室的專用團隊

RAD 專案具有固有的自適應、湧現的特性。許多 IT 組織反對 RAD。然而，微軟和其他公司已經使用與 RAD 相當的技術產生了令人難以置信的大型和複雜的軟體，因為它對其基本的世界觀提出了質疑。

RAD 實踐和微軟流程都是自適應開發的實際例子。為它們貼上標籤（即自適應開發）並意識到越來越多的科學知識（即 CAS 理論）解釋了它們為什麼有效。這應為更廣泛地使用這些實踐提供基礎。

自適應軟體開發 - 生命週期

自適應軟體開發是從 RAD 實踐發展而來的。團隊方面也新增到這些實踐中。從紐西蘭到加拿大的公司，針對各種專案和產品型別，都使用了自適應軟體開發。

吉姆·海史密斯於 2000 年出版了《自適應軟體開發》。

自適應軟體開發實踐能夠適應變化，並能夠適應產品在幾乎沒有規劃和學習的情況下不斷發展的動盪環境。

ASD 生命週期階段

自適應軟體開發與進化模型一樣是迴圈的，階段名稱反映了複雜系統中的不可預測性。自適應開發生命週期中的階段是：

推測 (Speculate)
協作 (Collaborate)
學習 (Learn)

這三個階段反映了自適應軟體開發的動態特性。自適應開發明確地用湧現取代了確定性。它不僅僅是生命週期上的改變，更是管理風格上的更深層次的改變。自適應軟體開發具有動態的“推測-協作-學習”生命週期。

自適應軟體開發生命週期關注結果，而不是任務，結果被識別為應用程式特性。

推測 (Speculate)

術語“計劃”過於確定性，表明對預期結果有相當高的確定性。對計劃一致性的隱含和明確目標限制了管理者將專案引向創新方向的能力。

在自適應軟體開發中，術語“計劃”被術語“推測”所取代。在推測過程中，團隊並沒有放棄計劃，而是承認複雜問題中存在不確定性的現實。推測鼓勵探索和實驗。鼓勵進行短週期的迭代。

協作 (Collaborate)

複雜的應用程式不是構建的，而是進化的。複雜的應用程式要求收集、分析和應用大量資訊來解決問題。動盪的環境具有高資訊流速率。因此，複雜的應用程式要求收集、分析和應用大量資訊來解決問題。這導致了多樣化的知識需求，只有透過團隊協作才能處理。

協作需要能夠共同努力以產生結果、共享知識或做出決策的能力。

在專案管理的背景下，協作描繪了在使用傳統管理技術和建立和維護湧現所需的協作環境之間的平衡。

學習 (Learn)

學習是生命週期中專案成功的關鍵部分。團隊必須不斷增強他們的知識，使用以下實踐：

技術評審
專案回顧
客戶焦點小組

每次迭代後都應進行評審。開發人員和客戶都檢查他們的假設，並使用每個開發週期的結果來了解下一個方向。團隊學習：

關於產品變更
關於產品開發方式的基本假設的更根本的改變

迭代需要簡短，以便團隊可以從小錯誤而不是大錯誤中學習。

推測 - 協作 - 學習週期作為一個整體

正如您從上面給出的“推測-協作-學習”週期中觀察到的那樣，這三個階段是非線性的並且重疊的。

我們從自適應框架中觀察到以下幾點。

如果沒有學習就很難協作，如果沒有協作就很難學習。
如果沒有學習就很難推測，如果沒有推測就很難學習。
如果沒有協作就很難推測，如果沒有推測就很難協作。

生命週期特徵

自適應軟體開發生命週期具有六個基本特徵：

以使命為中心
基於特性
迭代式
限時
風險驅動
容錯性

本章將闡述自適應軟體開發的這六個特徵。

以使命為中心

對於許多專案而言，指導團隊的總體使命表達得很好，儘管在專案開始時需求可能不確定。使命陳述充當指南，鼓勵在開始時進行探索，但在專案過程中重點會很窄。使命提供邊界而不是固定目的地。使命陳述以及由此產生的討論為做出關鍵的專案權衡決策提供了方向和標準。

如果沒有明確的使命和持續的使命改進實踐，迭代生命週期將成為振盪生命週期，來回擺動，開發沒有進展。

基於特性

自適應軟體開發生命週期基於應用程式特性，而不是任務。特性是在迭代期間根據客戶的優先順序開發的功能。

當客戶提供反饋時，特性可以在幾個迭代中不斷發展。

實施後直接為客戶帶來結果的應用程式特性是主要的。面向客戶的文件（例如使用者手冊）也被視為特性。其他文件（例如資料模型）即使被定義為可交付成果，也始終是次要的。

迭代式

自適應軟體開發生命週期是迭代式的，側重於頻繁釋出，以便獲得反饋，吸取由此產生的經驗教訓，併為進一步開發設定正確的方向。

限時

在自適應軟體開發生命週期中，迭代是限時的。但是，應該記住，自適應軟體開發中的限時並不是指時間截止日期。它不應被用來讓團隊長時間工作，從而挑戰協作環境或影響可交付成果的質量。

在自適應軟體開發中，限時被認為是關注和強制必要時做出艱難權衡決策的方向。在變化率高的不確定環境中，需要週期性的強制函式（例如限時）來完成工作。

風險驅動

在自適應軟體開發中，迭代是由識別和評估關鍵風險驅動的。

容錯性

自適應軟體開發具有容錯性，它將變更視為整合競爭優勢的能力，而不是開發的問題。

自適應軟體開發 - 實踐

自適應軟體開發實踐源於對持續適應的信念，其生命週期能夠接受持續變更作為常態。

自適應軟體開發生命週期致力於：

持續學習
變更導向
重新評估
洞察不確定的未來
開發人員、管理人員和客戶之間的密切合作

自適應SDLC

自適應軟體開發將RAD與軟體工程最佳實踐相結合，例如：

專案啟動。
自適應週期規劃。
併發元件工程。
質量審查。
最終QA和釋出。

自適應軟體開發實踐可以如下所示：

如上所示，自適應軟體開發實踐分佈在以下三個階段：

推測 - 啟動和規劃
- 專案啟動
- 為整個專案建立時間框
- 確定迭代次數併為每個迭代分配時間框
- 為每個迭代制定主題或目標
- 為每個迭代分配功能
協作 - 併發功能開發
- 分散式團隊的協作
- 小型專案的協作
- 大型專案的協作
學習 - 質量審查
- 從客戶的角度來看結果質量
- 從技術角度來看結果質量
- 交付團隊的運作以及團隊成員正在使用的實踐
- 專案狀態

推測 - 啟動和規劃

在自適應軟體開發中，“推測”階段有兩個活動：

啟動
規劃

“推測”有五個實踐，可以在啟動和規劃階段重複執行。它們是：

專案啟動
為整個專案建立時間框
確定迭代次數併為每個迭代分配時間框
為每個迭代制定主題或目標
為每個迭代分配功能

專案啟動

專案啟動包括：

設定專案的使命和目標
瞭解約束條件
建立專案組織
識別和概述需求
進行初步規模和範圍估計
識別關鍵專案風險

專案啟動資料應在一個初步的JAD會議中收集，其中速度是主要方面。對於中小型專案，啟動可以在集中進行的2到5天內完成，而對於大型專案則需要2到3周的時間。

在JAD會議期間，將收集足夠詳細的需求以識別功能並建立物件、資料或其他架構模型的概述。

為整個專案建立時間框

應根據專案啟動工作產生的範圍、功能集需求、估計和資源可用性，確定整個專案的時間框。

如你所知，“推測”並不意味著放棄估計，而只是意味著接受估計可能會出錯。

迭代和時間框

根據專案的整體範圍和不確定性程度，確定迭代次數和各個迭代的長度。

對於中小型應用程式：

迭代通常為4到8周。
一些專案最適合兩週的迭代。
一些專案可能需要超過8周。

根據適合你的情況選擇時間。一旦你確定了迭代次數和每個迭代的長度，就為每個迭代分配一個時間表。

制定主題或目標

團隊成員應為每個迭代制定一個主題或目標。這類似於Scrum中的Sprint目標。每個迭代都應交付一組可以演示產品功能的功能，使客戶能夠看到產品以進行審查和反饋。

在迭代中，構建應最好每天交付可執行的功能，從而實現整合過程並使開發團隊能夠看到產品。測試應該是功能開發中持續且不可或缺的一部分，不應推遲到專案結束。

分配功能

開發人員和客戶應共同為每個迭代分配功能。此功能分配的最重要標準是每個迭代都必須向客戶交付一組具有相當功能的可見功能。

在將功能分配給迭代期間：

開發團隊應提出功能估計、風險和依賴關係，並將其提供給客戶。
客戶應使用開發團隊提供的資訊來決定功能優先順序。

因此，迭代規劃是基於功能的，並由開發人員和客戶組成的團隊完成。經驗表明，這種型別的規劃比專案經理進行的任務型規劃能更好地理解專案。此外，基於功能的規劃反映了每個專案的獨特性。

協作 - 併發功能開發

在“協作”階段，重點是開發。“協作”階段有兩個活動：

開發團隊協作並交付可執行的軟體。
專案經理促進協作和併發開發活動。

協作是共享建立的行為，它包含開發團隊、客戶和經理。共享建立由信任和尊重促進。

團隊應在以下方面進行協作：

技術問題
業務需求
快速決策

以下是與自適應軟體開發中“協作”階段相關的實踐：

分散式團隊的協作
小型專案的協作
大型專案的協作

分散式團隊的協作

在涉及分散式團隊的專案中，應考慮以下事項：

不同的聯盟夥伴
廣泛的知識
人們互動的方式
他們管理相互依賴關係的方式

小型專案的協作

在小型專案中，當團隊成員在物理上靠近時，應鼓勵非正式的走廊聊天和白板塗鴉式的協作，因為這被認為是有效的。

大型專案的協作

大型專案需要額外的實踐、協作工具以及專案經理的互動，並應根據具體情況進行安排。

學習 - 質量審查

自適應軟體開發鼓勵“實驗和學習”的概念。

從錯誤和實驗中學習要求團隊成員儘早共享部分完成的程式碼和工件，以便：

查詢錯誤
從中學習
透過在小問題變成大問題之前找到它們來減少返工

在每個開發迭代結束時，有四類需要學習的內容：

從客戶的角度來看結果質量
從技術角度來看結果質量
交付團隊和團隊實踐的運作情況
專案狀態

從客戶角度來看結果質量

在自適應軟體開發專案中，獲得客戶的反饋是首要任務。為此推薦的做法是客戶焦點小組。這些會議旨在探索應用程式的工作模型並記錄客戶的變更請求。

客戶焦點小組會議是有組織的會議，類似於JAD會議，但它們不是為了生成需求或定義專案計劃，而是為了審查應用程式本身。客戶會對迭代產生的可執行軟體提供反饋。

從技術角度來看結果質量

在自適應軟體開發專案中，應重視對技術工件的定期審查。應持續進行程式碼審查。可以每週或在迭代結束時對其他技術工件（如技術架構）進行審查。

在自適應軟體開發專案中，團隊應定期監控自身的績效。回顧鼓勵團隊作為一個團隊一起了解自身及其工作。

迭代結束後的回顧有助於定期進行團隊績效自我審查，例如：

確定哪些方面不起作用。
團隊需要做更多的事情。
團隊需要做更少的事情。

專案狀態

專案狀態審查有助於規劃進一步的工作。在自適應軟體開發專案中，確定專案狀態是基於功能的方法，每個迭代的結束都以完成的功能（從而產生可執行的軟體）為標誌。

專案狀態審查應包括：

專案進展到哪裡了？
專案進展與計劃相比如何？
專案應該進展到哪裡？

由於自適應軟體開發專案的計劃是推測性的，因此問題3比問題2更重要。也就是說，專案團隊和客戶需要不斷地問自己：“我們到目前為止學到了什麼，這是否改變了我們對下一步方向的看法？”

自適應軟體開發 - 管理

下圖顯示了傳統軟體管理的流程圖。

傳統的軟體管理的特點是“命令控制”。

許多組織深陷最佳化、效率、可預測性、控制、嚴謹和流程改進的傳統之中。然而，新興的資訊時代經濟需要適應性、速度、協作、即興創作、靈活性和創新性。

哈佛商業評論和管理書籍提出了賦權、參與式管理、學習型組織、以人為本的管理等術語，但這些都沒有被用於管理現代組織。

在自適應軟體開發的背景下，差距看起來更大，有必要考慮在其他領域已被證明成功的自適應管理技術。

自適應管理

自適應管理在資源管理人員與利益相關者和科學家一起作為團隊工作，並具有以下目標的環境中已被證明是成功的：

瞭解管理系統如何響應人為干預。
改進未來的資源政策和實踐。

自適應管理的原則在於，許多資源管理活動都是實驗，因為其結果無法事先可靠地預測。這些實驗隨後被用作未來改進的學習機會。

自適應管理旨在提高面對新資訊以及各種利益相關者目標和偏好的情況下及時響應的能力。它鼓勵利益相關者限制爭議並在環境不確定性得到調查和更好地理解的同時以有序的方式討論它們。

自適應管理幫助利益相關者、管理者和其他決策者認識到知識的侷限性以及需要根據不完善的資訊採取行動。

自適應管理有助於改變做出的決策，因為它明確指出：

這些決策是暫定的。
管理層的決策並不總是正確的。
預計會進行修改。

有兩種型別的自適應管理方法：

被動自適應管理。
主動自適應管理。

被動自適應管理

自適應管理旨在增強科學知識，從而減少不確定性。

在被動自適應管理中，會根據現有資訊和理解選擇單一的首選行動方案。對管理行動的結果進行監控，並根據結果調整後續決策。

這種方法有助於學習和有效管理。但是，它在增強科學和管理能力方面的能力有限，無法應對超出所選行動方案的情況。

主動自適應管理

主動自適應管理方法會在採取管理行動之前審查資訊。

然後，開發一系列相互競爭的替代性生態系統和相關響應系統模型（例如，人口變化；娛樂用途），而不是單個模型。管理方案的選擇基於對這些替代模型的評估。

領導力合作管理

自適應管理最適合自適應軟體開發。這種方法需要資源管理者，即能夠與人合作、允許人為干預並創造友好環境的管理者。

在軟體開發中，領導者通常承擔這些責任。我們需要領導者而不是指揮官。領導者是合作者，與團隊一起工作。協作領導是自適應開發中最受歡迎的做法。

領導者具備以下素質：

掌握並確定方向。
影響相關人員並提供指導。
與團隊合作、促進團隊合作並進行宏觀管理。
提供方向。
創造能夠讓有才華的人進行創新、創造和做出有效決策的環境。
理解他們偶爾需要指揮，但這並非他們的主要風格。

列印頁面