敏捷方法论:意义、优点、缺点等

敏捷方法论是一种 软件开发 该理念旨在通过使用更短的开发周期并不断修订来为客户提供更好的价值。
软件开发是从数学和科学领域发展而来的。 因此,它最初融合了这些领域的科学方法。
这些方法在 1970 年代演变成瀑布方法,以满足当时的需求。 那时的计算机及其软件庞大而复杂,并且设计可以使用数十年。 因此,瀑布方法非常适合。
但是,到 1990 年代后期,互联网正在极大地改变世界,因此需要一种新的方法。 敏捷方法就是这样诞生的。
以下是对这一软件开发运动的详细介绍,以及它如何帮助您和您的团队。
敏捷开发方法的历史
敏捷软件开发源于互联网及其在 1990 年代和 2000 年代初期的繁荣时期对应用程序的永不满足的需求。
这也是许多没有计算机科学背景的开发人员转向 Web 开发的时期,因为对迎合不同群体和行业的网站的大量需求。
当然,大多数 初创公司 规模很小。因此,大多数开发都是由小团队进行的,最终目标往往是快速上市。因为迟到意味着失去市场份额。
为了应对瀑布模型对尽快将产品推向市场的限制,不同的开发人员在 1990 年代提出了不同的方法。 它们包括快速应用程序开发 (RAD)、Scrum、极限编程 (XP)、看板等。
然后,在 2001 年的某个时候,17 名从事早期敏捷开发的一种或另一种形式的开发人员聚集在美国犹他州。 然后他们通过发布“敏捷软件开发宣言”结束了他们的会议。
该宣言基于 4 个价值观和 12 条原则。
敏捷开发的 4 个价值观和 12 条原则
从他们在会议期间聚集的经验来看,这 17 位开发人员就一组价值观达成了一致,以更有效地创建软件。
这四个值如下:
- 个人与互动 过流程和 工具. 这意味着在遵循特定流程的同时使用工具开发软件很重要。 但是让有能力的人更有效地合作更为重要。
- 工作软件 超过全面的文档。 这攻击了在实际软件开发过程之前首先设计软件并为其编写文档的瀑布方法。
- 客户合作 过度合同谈判。 只有与客户或用户密切合作,您才能准确了解和开发客户的需求。 这创造了更多的价值。
- 应对变化 而不是遵循计划。遵循 项目 计划很重要。但计划不能太死板。它必须适应变化以满足利益相关者的期望。
上述敏捷宣言价值观基于 12 条原则,具体如下:
- 通过早期和持续交付有价值的软件来满足客户的需求。
- 欢迎不断变化的需求,即使是在后期开发中。
- 经常交付工作软件(几周而不是几个月)
- 业务人员和开发人员之间密切的日常合作
- 项目是围绕有动力的个人建立的,他们应该被信任
- 面对面交谈是最好的沟通方式(同地办公)
- 工作软件是进度的主要衡量标准
- 可持续发展,能够保持恒定的步伐
- 持续关注卓越的技术和良好的设计
- 简单——最大化未完成工作量的艺术——是必不可少的
- 最佳架构、需求和设计来自自组织团队
- 定期,团队反思如何变得更有效率并做出相应的调整
迭代或冲刺
敏捷软件开发中的迭代或冲刺通常是 1 到 4 周的短周期,开发工作被分解为其中。 这使得事情更容易管理,因为它需要更少的计划。
每个团队通常还由具有不同职能的成员组成,这些职能包括规划、分析、设计、编码和测试。
团队在每次迭代或冲刺时一起开发软件。 他们最终生产出工作产品。 根据敏捷宣言,这个工作软件是衡量真正进步的标准。
根据产品和客户的需求,迭代的产品可能会投放市场或不投放市场。 因此,单个版本通常需要多次迭代。
敏捷开发的优势
可以想象,敏捷方法带来了许多优势。 它们如下:
- 更快地实施想法
- 比瀑布方法更灵活
- 优化 生产率 使用托管迭代
- 通过用户交互更好的产品
- 快速识别和消除错误
敏捷方法的缺点
使用敏捷开发方法也有一些缺点。 它们可以包括:
- 一开始可能很难评估全部成本
- 它需要大量的客户输入
- 涉及大量计划外工作
- 没有明确定义的项目结束
何时使用敏捷方法
- 当您无法估计软件需要什么时
- 您有足够的客户访问权限
- 您正在开发 Web 应用程序或易于更新的系统
- 您需要通过早期版本快速占领市场份额
流行的敏捷开发框架
有许多流行的敏捷开发框架。 有些人在 2001 年敏捷宣言之前就开始了,而其他人则较晚。
框架的目标只是定义方法的规则。 因此,虽然下面列出了最流行的框架供您参考,但还有更多。 您还可以自由创建或修改现有框架以适应您的团队。
- 争球:此框架专为 10 名或更少成员的团队设计。 工作分为 2-4 周的冲刺,每天 15 分钟的会议。
- 看板:看板源于丰田,是一个日语单词,意思是广告牌,对于欣赏视觉辅助的团队非常有帮助。 使用便笺或应用程序等视觉表示将任务从一个阶段移动到另一个阶段。
- 快速应用程序开发 RAD:这句话既可以指一般的敏捷软件开发,也可以指詹姆斯马丁方法。 RAD 专注于用户界面需求,并在很大程度上依赖于原型设计。
- 精益创业:此框架适用于那些需要开发产品或服务的人,但首先必须确定其市场可行性。 它涉及使用实验来查看哪些有效,哪些无效。
其他值得注意的框架包括极限编程 (XP)、自适应软件开发、敏捷建模、动态系统开发方法和规模化敏捷框架。
敏捷与瀑布方法
以下是用于开发软件的敏捷方法和瀑布方法的并列视图。 它可以帮助了解每种方法如何相互叠加。 因此,您可以轻松选择最适合您工作的工具。
敏捷 | 瀑布 |
---|---|
增量和迭代方法 | 线性和顺序生命周期模型 |
灵活改变 | 刚性实现 |
测试和审查正在进行中 | 完成后只有一个测试阶段 |
要求可以改变 | 需求在计划后确定 |
许多小型项目的集合 | 一个项目 |
更多的客户参与 | 减少客户参与 |
适应性与预测性发展
敏捷软件开发的目标是适应现实世界的变化。 这些通常是客户或用户需求的结果。 适应与瀑布模型的预测性质形成鲜明对比。
因此,在开发您不太确定事情会如何发展的系统时,使用敏捷方法是有意义的。 或者当一个行业不断变化和发展时。 互联网就是一个很好的例子。
否则,如果您正在开发一个您对一切都了如指掌的系统或市场,并且几乎不会改变或对改变免疫。 那么,瀑布哲学的预测性质可能会有所帮助。
软件工艺
Software Craftsmanship 是另一种建立在敏捷开发原则之上的哲学,它侧重于强调参与项目的软件开发人员的技能。
软件工艺运动也有一个宣言,它指出:
作为有抱负的软件工匠,我们通过实践和帮助他人学习技能来提高专业软件开发的标准。 通过这项工作,我们开始重视: · 不仅是工作软件,而且是精心制作的软件 · 不仅响应变化,而且稳步增加价值 · 不仅是个人和互动,而且是专业人士社区 · 不仅是客户合作,但也是富有成效的伙伴关系也就是说,在追求左边的项目时,我们发现右边的项目是不可或缺的。 © 2009,签名者。 本声明可以任何形式自由复制,但只能通过本通知全文复制
结语
在我们对敏捷方法和软件开发的了解结束时,您会看到那里有很多选择。
每个团队都是不同的。 正如不同的团队开发了不同的方法来适应不断变化的时代一样。 您也必须通过使用已经建立的框架或对其进行调整以适应您的团队来适应。