跳转至内容

软件工程/流程/敏捷模型简介

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://wikibooks.cn/w/index.php?title=Introduction_to_Software_Engineering/Process/Agile_Model&oldid=3445676"
华夏公益教科书