跳轉至內容

軟體工程/流程/敏捷模型簡介

Add links
來自華夏公益教科書
< 軟體工程導論 | 流程
最近一次評審版本於2020年12月12日檢查。有模板/檔案更改等待評審。

敏捷軟體開發是一組基於迭代和增量開發的軟體開發方法，其中需求和解決方案透過自組織的跨職能團隊之間的協作而不斷發展。敏捷宣言[1]於2001年引入了該術語。

歷史

[編輯 | 編輯原始碼]

前身

[編輯 | 編輯原始碼]
Jeff Sutherland，Scrum框架的創造者之一

增量式軟體開發方法可以追溯到1957年。[2] 1974年，E. A. Edmonds發表了一篇關於自適應軟體開發過程的論文。[3]

所謂的“輕量級”軟體開發方法在20世紀90年代中期發展起來，是對“重量級”方法的反應，這些方法的特點是被其批評者描述為高度管制、機械化、微觀管理的瀑布模型開發方法。輕量級方法（現在是“敏捷”方法）的支持者認為，它們是軟體開發歷史上早期開發實踐的迴歸。[2]

輕量級方法的早期實現包括Scrum（1995）、Crystal Clear、極限程式設計（1996）、自適應軟體開發、特徵驅動開發和動態系統開發方法（DSDM）（1995）。這些現在通常被稱為敏捷方法，這是在2001年釋出的敏捷宣言之後。[4]

敏捷宣言

[編輯 | 編輯原始碼]

2001年2月，17位軟體開發者[5]在猶他州斯諾伯德的一家滑雪勝地會面，討論輕量級開發方法。他們釋出了“敏捷軟體開發宣言”[1]來定義現在被稱為敏捷軟體開發的方法。宣言的一些作者組成了敏捷聯盟，這是一個非營利組織，致力於推廣根據宣言原則進行軟體開發。

敏捷宣言全文如下：[1]

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

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

也就是說，雖然右側的條目也有價值，但我們更重視左側的條目。

敏捷宣言的背後有十二條原則，包括：[6]

  • 透過快速交付有用的軟體來滿足客戶
  • 歡迎在開發過程中的任何時間發生變更需求
  • 經常交付可工作的軟體（幾周而不是幾個月）
  • 可工作的軟體是衡量進度的主要指標
  • 可持續開發，能夠保持穩定的開發速度
  • 業務人員和開發人員之間密切的日常合作
  • 面對面交流是最好的交流方式（共同位置）
  • 專案圍繞積極主動的個人構建，這些人應該得到信任
  • 持續關注技術卓越和良好設計
  • 簡潔
  • 自組織團隊
  • 定期適應不斷變化的環境

2005年，由Alistair Cockburn和Jim Highsmith領導的一個小組撰寫了專案管理原則的附錄，即“相互依存宣言”[7]，以指導根據敏捷開發方法進行軟體專案管理。

特徵

[編輯 | 編輯原始碼]
結對程式設計，敏捷使用的XP開發技術

有許多具體的敏捷開發方法。大多數方法都提倡在專案的整個生命週期中進行開發、團隊合作、協作和流程適應性。

敏捷方法將任務分解成小的增量，並進行最少的規劃，並且不直接涉及長期規劃。迭代是短暫的時間段（時間盒），通常持續一到四周。每次迭代都涉及一個團隊完成一個完整的軟體開發週期，包括規劃、需求分析、設計、編碼、單元測試和驗收測試，在該測試中，向利益相關者展示可工作的產品。這最大限度地降低了整體風險，並使專案能夠快速適應變化。利益相關者根據需要生成文件。一次迭代可能不會增加足以保證市場釋出的功能，但目標是在每次迭代結束時提供一個可用的版本（具有最少的錯誤）。[8] 可能需要多次迭代才能釋出產品或新功能。

敏捷專案中的團隊組成通常是跨職能的，並且是自組織的，不考慮任何現有的公司層級或團隊成員的公司角色。團隊成員通常負責提供迭代所需功能的任務。他們分別決定如何滿足迭代的需求。

敏捷方法強調面對面交流而不是書面文件，前提是團隊都在同一個地點。大多數敏捷團隊在一個開放式辦公室（稱為牛棚）中工作，這有利於這種交流。團隊規模通常很小（5-9人），以簡化團隊交流和團隊協作。更大的開發工作可以透過多個團隊來完成，這些團隊朝著共同目標努力或在工作的不同部分工作。這可能需要協調跨團隊的優先順序。當團隊在不同的地點工作時，他們透過視訊會議、語音、電子郵件等方式保持每天的聯絡。

無論需要什麼開發學科，每個敏捷團隊都會包含一個客戶代表。這個人由利益相關者任命，代表他們行動，並做出個人承諾，在迭代過程中隨時為開發人員提供問題域的答案。在每次迭代結束時，利益相關者和客戶代表會回顧進度，重新評估優先順序，以最佳化投資回報率（ROI）並確保與客戶需求和公司目標保持一致。

大多數敏捷實現都使用例行和正式的每日面對面交流，團隊成員之間進行交流。這明確包括客戶代表和任何感興趣的利益相關者作為觀察者。在一個簡短的會議中，團隊成員相互報告他們前一天做了什麼，他們今天打算做什麼，以及他們遇到了什麼障礙。這種面對面交流可以暴露問題，因為它們會隨著時間的推移而出現。

敏捷開發強調可工作的軟體是衡量進度的主要指標。這與對面對面交流的偏好相結合，產生的書面文件比其他方法更少。敏捷方法鼓勵利益相關者根據迭代開始時感知的業務價值，優先考慮其他迭代結果。

諸如持續整合、自動化或xUnit測試、結對程式設計、測試驅動開發、設計模式、領域驅動設計、程式碼重構和其他技術等特定工具和技術通常用於提高質量和增強專案敏捷性。

與其他方法的比較

[編輯 | 編輯原始碼]

敏捷方法有時被描述為與“計劃驅動”或“規範”方法處於光譜的另一端；然而，敏捷團隊可能會採用高度規範的正式方法。[9] 更準確的區分是，方法存在於從“自適應”到“預測”的連續體上。[10] 敏捷方法位於此連續體的“自適應”側。自適應方法側重於快速適應不斷變化的現實情況。當專案的需要發生變化時，自適應團隊也會隨之變化。自適應團隊難以準確描述未來將會發生的事情。日期越遠，自適應方法對該日期將會發生的事情就越模糊。自適應團隊無法準確報告下週將要完成的任務，而只能報告下個月計劃的哪些功能。當被問及六個月後的釋出時，自適應團隊可能只能報告發布的使命宣告，或者預期價值與成本的宣告。

相比之下，預測方法側重於詳細地規劃未來。預測團隊可以準確報告整個開發過程的計劃功能和任務。預測團隊難以改變方向。計劃通常針對原始目標進行最佳化，改變方向可能會導致已完成的工作需要重新開始。預測團隊通常會設立變更控制委員會，以確保只考慮最有價值的變更。

與自適應和預測方法相比，正式方法側重於計算機科學理論，具有多種型別的證明器。正式方法試圖在一定程度的確定性下證明不存在錯誤。一些正式方法基於模型檢測併為無法證明的程式碼提供反例。通常，數學模型（通常透過特殊語言支援，參見 SPIN 模型檢測器）對映到關於需求的斷言。正式方法依賴於工具驅動的模式，並且可以與其他開發模式相結合。一些證明器不容易擴充套件。與敏捷方法類似，與高完整性軟體相關的宣言已在 Crosstalk 中提出。

敏捷方法與 1980/90 年代由 James Martin 等人提出的“快速應用程式開發”技術有很多共同點。

敏捷方法

[編輯 | 編輯原始碼]

眾所周知的敏捷軟體開發方法包括

  • 敏捷建模
  • 敏捷統一過程 (AUP)
  • 動態系統開發方法 (DSDM)
  • 基本統一過程 (EssUP)
  • 極限程式設計 (XP)
  • 特性驅動開發 (FDD)
  • 開放統一過程 (OpenUP)
  • Scrum
  • 速度追蹤

方法定製

[編輯 | 編輯原始碼]

在文獻中，不同的術語指的是方法適應的概念，包括“方法定製”、“方法片段適應”和“情景方法工程”。方法定製被定義為

人類代理透過對上下文、意圖和方法片段的響應性變化以及動態互動，為特定專案情況確定系統開發方法的過程或能力。[11]

幾乎所有敏捷方法都適合進行方法定製。即使是 DSDM 方法也用於此目的，並且已在 CMM 上下文中成功定製。[12] 情況適宜性可以被認為是敏捷方法和傳統軟體開發方法之間的區別特徵，後者相對更嚴格和更具規定性。實際意義是，敏捷方法允許專案團隊根據各個專案的需要調整工作實踐。實踐是方法框架的一部分的具體活動和產品。在更極端的層面上，方法背後的哲學，包括一些原則，可以進行調整（Aydin，2004）。[11]

極限程式設計 (XP) 明確了對方法適應的需求。XP 的基本理念之一是，沒有一種流程適合所有專案，而是應該根據各個專案的需要定製實踐。正如 Beck 所建議的那樣，對 XP 實踐的區域性採用已在多個場合被報道。[13] Mehdi Mirakhorli 提出了一種定製實踐，它為適應所有實踐提供了足夠的路線圖和指南。RDP 實踐旨在定製 XP。該實踐最初在 ICSE 2008 大會上的 APSO 研討會上以一篇長篇研究論文的形式提出，目前是唯一提出的可應用於定製 XP 的方法。雖然它專門針對 XP，但該實踐具有擴充套件到其他方法的能力。乍一看，該實踐似乎屬於靜態方法適應的範疇，但使用 RDP 實踐的經驗表明，它可以被視為動態方法適應。靜態方法適應和動態方法適應之間的區別很微妙。[14] 靜態方法適應背後的關鍵假設是，專案上下文在專案開始時給出並在專案執行期間保持不變。結果是專案上下文的靜態定義。給定這樣的定義，可以根據預定義的標準集，使用路線圖來確定應該為該特定專案使用哪些結構化方法片段。相比之下，動態方法適應假設專案處於一個不斷湧現的上下文中。不斷湧現的上下文意味著專案必須處理影響相關條件但不可預測的不斷湧現的因素。這也意味著專案上下文不是固定的，而是在專案執行期間不斷變化的。在這種情況下，規定性的路線圖不合適。動態方法適應的實際意義是，專案經理通常必須在專案執行期間修改結構化片段，甚至創新新的片段（Aydin 等人，2005）。[14]

衡量敏捷性

[編輯 | 編輯原始碼]

雖然敏捷性可以被視為一種手段，但已提出了一些方法來量化敏捷性。敏捷指數測量 (AIM)[15] 根據一些敏捷性因素對專案進行評分，以獲得總分。類似命名的敏捷測量指數[16] 根據軟體專案的五個維度（持續時間、風險、新穎性、工作量和互動）對開發進行評分。其他技術基於可衡量的目標。[17] 另一項使用模糊數學[18] 的研究表明，專案速度可以作為敏捷性的指標。有一些敏捷自我評估可以確定團隊是否使用敏捷實踐（諾基亞測試[19]，卡爾斯克魯納測試[20]，42 點測試[21]）。

雖然已經提出了這些方法來衡量敏捷性，但這些指標的實際應用還有待觀察。

經驗和反響

[編輯 | 編輯原始碼]

Shine Technologies 在 2002 年 11 月至 2003 年 1 月進行的一項調查是早期報道使用敏捷方法在質量、生產力和業務滿意度方面取得進展的研究之一。[22] IBM Rational 方法組敏捷開發實踐負責人 Scott Ambler 在 2006 年進行的一項類似調查報告了類似的優勢。[23] 在 VersionOne 在 2008 年進行的一項調查中，55% 的受訪者回答說敏捷方法在 90-100% 的情況下取得了成功。[24] 其他人聲稱敏捷開發方法還太年輕，不需要對其成功進行廣泛的學術證明。[25]

適用性

[編輯 | 編輯原始碼]

大規模敏捷軟體開發仍然是一個活躍的研究領域。[26][27]

敏捷開發已被廣泛記錄（參見下面的經驗報告，以及 Beck[28]第 157 頁，以及 Boehm 和 Turner[29]），對於小型（<10 名開發人員）的同地團隊來說效果很好。

可能對敏捷專案成功產生負面影響的一些因素包括：

  • 大規模開發工作（>20 名開發人員），儘管擴充套件策略[27]和一些大型專案的證據[30]已被描述。
  • 分散式開發工作（非同地團隊）。策略在彌合距離[31]和使用敏捷軟體過程進行離岸開發[32]中有所描述。
  • 將敏捷流程強加於開發團隊[33]
  • 關鍵任務系統，任何情況下都不可失敗（例如用於手術程式的軟體）。

已有若干成功的敏捷大規模專案被記錄在案。模板：在哪裡 BT 在英國、愛爾蘭和印度有多達數百名開發人員協同工作於專案，並使用敏捷方法。[需要引用]

在離岸敏捷開發方面，LogiGear 公司高階副總裁 Michael Hackett 表示，“離岸團隊……應該擁有專業知識、經驗、良好的溝通能力、跨文化理解、團隊成員之間的信任和理解，以及團隊成員之間的相互理解”。[34]

Barry Boehm 和 Richard Turner 建議使用風險分析來選擇適應性（“敏捷”）和預測性（“計劃驅動”）方法。[29]作者建議，連續統的兩端都有其自身的主場，如下所示：

敏捷主場：[29]

  • 低關鍵性
  • 高階開發人員
  • 需求經常變化
  • 少數開發人員
  • 在混亂中蓬勃發展的文化

計劃驅動主場：[29]

  • 高關鍵性
  • 初級開發人員
  • 需求不常變化
  • 大量開發人員
  • 要求秩序的文化

正式方法

  • 極端關鍵性
  • 高階開發人員
  • 有限的需求，有限的功能，參見 Wirth 法則
  • 可以建模的需求
  • 極端質量

經驗報告

[編輯 | 編輯原始碼]

敏捷開發一直是幾個會議的主題。其中一些會議有學術支援，包括同行評審的論文，包括同行評審的經驗報告專欄。經驗報告分享了敏捷軟體開發的行業經驗。

截至 2006 年，經驗報告已在以下會議上發表或即將發表：

  • XP（2000,[35] 2001, 2002, 2003, 2004, 2005, 2006,[36] 2010（會議記錄由 IEEE 出版）[37]）
  • XP Universe（2001[38]）
  • XP/Agile Universe（2002,[39] 2003,[40] 2004[41]）
  • 敏捷開發大會[42]（2003, 2004, 2007, 2008）（同行評審；會議記錄由 IEEE 出版）

參考文獻

[編輯 | 編輯原始碼]
  1. ↑ a b c Beck, Kent；等（2001）。 "敏捷軟體開發宣言"。敏捷聯盟. 檢索於 2010-06-14. {{引用網頁}}: 顯式使用等：|author2= (幫助)
  2. ↑ a b Gerald M. Weinberg，如Larman, Craig; Basili, Victor R. (2003). "迭代和增量開發：簡史". 計算機. 36 (6): 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162. 早在 1957 年，我們就在洛杉磯，在 Bernie Dimsdale（在 IBM 的 ServiceBureau Corporation）的指導下進行了增量開發。他是約翰·馮·諾依曼的同事，所以他可能在那裡學到的，或者認為這是完全自然的。我還記得 Herb Jacobs（主要是，儘管我們所有人都參與了）為摩托羅拉開發了一個大型模擬，其中使用的技術，據我所知……。我們所有人，據我所知，都認為對一個大型專案進行瀑布式開發是相當愚蠢的，或者至少是不瞭解現實情況的。我認為瀑布式描述對我們的作用是讓我們意識到我們正在做其他事情，除了“軟體開發”之外沒有名字的事情。 {{引用期刊}}: |access-date= 需要 |url= (幫助); 未知引數 |month= 被忽略 (幫助)
  3. ↑ Edmonds, E. A. (1974). "為非技術使用者開發軟體作為適應性系統的方法". 一般系統. 19: 215–18.
  4. ↑ Larman, Craig (2004). 敏捷和迭代開發：管理者指南. Addison-Wesley. p. 27. ISBN 9780131111554.
  5. ↑ Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、Jon Kern、Brian Marick、Robert C. Martin、Stephen J. Mellor、Ken Schwaber、Jeff Sutherland 和 Dave Thomas
  6. ↑ Beck, Kent; 等 (2001). "敏捷宣言背後的原則". Agile Alliance. 檢索於 2010-06-06. {{cite web}}: 在中明確使用等: |author2= (幫助)
  7. ↑ 安德森，大衛 (2005). "相互依賴宣言".
  8. ↑ 貝克，肯特 (1999). "擁抱變化與極限程式設計". 計算機. 32 (10): 70–77. doi:10.1109/2.796139.
  9. ↑ 布萊克，S. E.; 博卡，P. P.; 鮑文，J. P.; 戈爾曼，J.; 欣奇，M. G. (2009). "正式與敏捷：適者生存". IEEE 計算機. 49 (9): 39–45. {{cite journal}}: 未知引數 |month= 被忽略 (幫助)
  10. ↑ 博姆，B. (2004). 平衡敏捷性和紀律：困惑者的指南. 馬薩諸塞州波士頓：Addison-Wesley. ISBN 0-321-18612-5. {{cite book}}: 未知引數 |coauthors= 被忽略 (|author= 建議) (幫助) 附錄 A，第 165-194 頁
  11. ↑ a b Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). 敏捷資訊系統開發方法的應用. Turk J Elec Engin, 12(2), 127-138
  12. ↑ Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). 敏捷方法的新方向：比較分析. ICSE'03 會議論文集, 244-254
  13. ↑ Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). 敏捷軟體開發方法：回顧與分析. VTT 出版物 478
  14. ↑ a b Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). 關於敏捷資訊系統開發方法的適應性. 資料庫管理雜誌，敏捷分析、設計和實施特刊，16(4), 20-24
  15. ↑ "大衛·博克的部落格：部落格". Jroller.com. 檢索於 2010-04-02.
  16. ↑ "敏捷度測量指標". Doi.acm.org. 檢索於 2010-04-02.
  17. ↑ Peter Lappo. "評估敏捷性" (PDF). 檢索於 2010-06-06. {{cite web}}: 未知引數 |coauthors= 被忽略 (|author= 建議) (幫助)
  18. ↑ Kurian, Tisni (2006). "敏捷度指標：一種基於定量模糊方法的軟體過程敏捷度測量方法" ISAM - 國際敏捷製造大會論文集 '06（ICAM-2006）, 諾福克，美國.
  19. ↑ Joe Little (2007-12-02). "諾基亞測試，一個Scrum特定的測試". Agileconsortium.blogspot.com. 檢索於 2010-06-06.
  20. ↑ Mark Seuffert，瑞典 Piratson Technologies. "卡爾斯克魯納測試，一個通用的敏捷採用測試". Piratson.se. 檢索於 2010-06-06.{{cite web}}: CS1 維護：多個名稱：作者列表 (連結)
  21. ↑ "你有多敏捷，一個Scrum特定的測試". Agile-software-development.com. 檢索於 2010-06-06.
  22. ↑ "敏捷方法論調查結果" (PDF). Shine Technologies. 2003. 檢索於 2010-06-03. 95% [表明] 沒有任何影響或成本降低. . . 93% 表明生產力更好或顯著更好. . . 88% 表明質量更好或顯著更好. . . 83% 表明業務滿意度更好或顯著更好 {{cite web}}: 外部連結在 |publisher= 中 (幫助); 未知引數 |month= 被忽略 (幫助)
  23. ↑ Ambler, Scott (2006 年 8 月 3 日). "調查顯示：敏捷在實踐中有效". Dr. Dobb's. Retrieved 2010-06-03. 只有 6% 的受訪者表示他們的生產力下降了......34% 的受訪者報告生產力沒有變化，60% 的受訪者報告生產力提高了......66% 的受訪者表示質量更高......58% 的組織報告滿意度提高，而只有 3% 的組織報告滿意度下降。
  24. ↑ "敏捷開發現狀" (PDF). VersionOne, Inc. 2008. Retrieved 2010-07-03. 敏捷交付
  25. ↑ "回答“敏捷方法有效的證據在哪裡”這個問題". Agilemodeling.com. 2007-01-19. Retrieved 2010-04-02.
  26. ↑ 敏捷流程研討會 II 管理多個併發敏捷專案。華盛頓：OOPSLA 2002
  27. ↑ a b W. Scott Ambler (2006) "超級大號我"" 在 Dr. Dobb's Journal，2006 年 2 月 15 日。
  28. ↑ Beck, K. (1999). 極限程式設計釋義：擁抱變化. 馬薩諸塞州波士頓：Addison-Wesley. ISBN 0-321-27865-8.
  29. ↑ a b c d Boehm, B. (2004). 平衡敏捷性和紀律：困惑者的指南. 馬薩諸塞州波士頓：Addison-Wesley. pp. 55–57. ISBN 0-321-18612-5. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  30. ↑ Schaaf, R.J. (2007). "敏捷 XL"，2007 年系統與軟體技術大會，佛羅里達州坦帕
  31. ↑ "縮短距離". Sdmagazine.com. Retrieved 2011-02-01.
  32. ↑ Martin Fowler. "在離岸開發中使用敏捷軟體流程". Martinfowler.com. Retrieved 2010-06-06.
  33. ↑ [敏捷開發的藝術 James Shore & Shane Warden 第 47 頁]
  34. ↑ [1] LogiGear，PC World 越南，2011 年 1 月
  35. ↑ 2000
  36. ↑ "2006". Virtual.vtt.fi. Retrieved 2010-06-06.
  37. ↑ "2010". Xp2010.org. Retrieved 2010-06-06.
  38. ↑ 2001
  39. ↑ 2002
  40. ↑ 2003
  41. ↑ 2004
  42. ↑ "敏捷開發大會". Agile200x.org. Retrieved 2010-06-06.

進一步閱讀

[edit | edit source]
[edit | edit source]
Retrieved from "https://wikibook.tw/w/index.php?title=Introduction_to_Software_Engineering/Process/Agile_Model&oldid=3445676"
華夏公益教科書