Agile简介1

admin管理员组

文章数量:1535374

2024年1月14日发(作者：)

Agile(即：敏捷方法)是一套与传统软件工程显著不同的价值观和原则，是包括 Scrum

和XP（Extreme Programming，极限编程）在内的所有敏捷过程或方法所共同具有的某些性质和特征，而不是某一个具体的过程、方法论或做法。

Agile横空出世

传统计划驱动的开发方法不仅没有获得良好的效果，并且由于强调过分过程控制，所以在开发过程中要产生大量的文档，以跟踪，检查设计各阶段的进度，设计状态，因此给程序员，管理者带来很多额外的工作量，这也是计划驱动方法一直为人诟病的地方，因此被称为重量级方法。这种方法会产生一些后果：

1. 大量的开发时间被用在开发文档的撰写和维护上，而真正花在代码上的时间就相对少了。

2. 由于主要依赖过程控制，而不是程序员自我管理，开发过程的管理非常复杂和低效。

因此，在近几年，一种被成为敏捷方法的开发思想开始流行起来。敏捷方法正是针对传统计划驱动方法的弊端而发展起来的。它是一类方法的总称。它有若干种不同的方法模型，比如水晶模型，scrum模型，XP编程。敏捷方法从另外的角度重新认识软件开发，颠覆了计划驱动方法的两个假设前提：需求固定和人是可替换的。

认识Agile

敏捷软件开发是供软件开发使用的概念性框架，它强调在项目的生命周期中使用迭代式开发，进行开放的协作，同时提倡自适应性。

一. Agile的目标

简单说，Agile的目标就是Good Software, Quickly and at Low Cost!敏捷的目标应该是重新审视现有软件开发流程，放弃不切实际的梦想（流水线和准确计划），根据敏捷的基本原则，重新优化现有流程和文档体系，但不是全面推到重来。

二. Agile的特征

敏捷方法有两个主要特征：

1. 开发采用适应性方法，经过多次小型迭代开发过程逐步逼近实际需求，从而为客户提供实际需要的软件。这种开发方法的核心是，小型发布，不断集成和严格回归测试。每一次的小型发布都经过严格测试后集成到最终产品中，保证每一次小型发布都是经过测试的高质量的代码。在每一次小型发布后和客户沟通，得到客户反馈，不断修改，增加新的客户需要的功能，从而生产出符合客户需要的产品。开发过程以代码为核心，而不是以文档为核心。设计以简单为原则。

2. 敏捷开发的第二个特征是以人为本。在敏捷方法里，程序员在软件开发中不再是单纯被管理的对象，而是开发的主体。所有的主要设计策略的制定，开发方法的选择，需求的确定都由程序员决定，因为他们才是真正生产软件的人，他们最了解如何开发软件。

三．目前列入Agile的方法

Agile简介

1.

2.

3.

4.

5.

6.

7.

8.

9.

软件开发节奏：Software Development Rhythms

敏捷数据库技术：AD/Agile Database Techniques

敏捷建模：AM/Agile Modeling

自适应软件开发：ASD/Adaptive Software Development

水晶方法：Crystal

特性驱动开发：FDD/Feature Driven Development

动态系统开发方法：DSDM/Dynamic Systems Development Method

精益软件开发：Lean Software Development Scrum

测试驱动开发：TDD/Test-Driven Development Breed

10.

极限编程：en :XP /en: Extreme Programming

四．Agile的三个层次

1. 小组级：在一个小组（5-11人）内部采用敏捷技术开发软件；

2. 组织级：在一个项目中实施敏捷但需要尽量与组织现有的管理模式进行对接；

3. 企业级：在整个企业级实施敏捷同时依据敏捷的原则对组织架构和流程进行改造。

五．Agile的价值观

1. 个人和交互重于方法和工具

– Individuals and interactions over processes and tools

2. 可工作的软件重于完备的文档

– Working software over comprehensive documentation

3. 与客户的协作重于合同谈判

– Customer collaboration over contract negotiation

4. 响应变化重于严格遵照计划

– Responding to change over following a plan

六．Agile的原则

我们遵循以下原则：

1. 我们最优先的目标是：通过尽早地、持续地交付高价值的软件来满足客户。

2. 我们欢迎需求的变化，甚至在开发的后期。敏捷过程通过驾驭变化来帮助客户取得竞争优势。

3. 经常交付可用的软件，间隔从两周到两个月不等，优先采用较短的时间尺度。

4. 整个项目自始至终，业务人员和开发人员都必须每天在一起工作。

5. 以积极主动的员工为核心建立项目团队，给予他们所需的环境和支持，并且信任他们能够胜任工作。

6. 在开发团队内外传递信息最有效率和效果的方法是：面对面的交流。

7. 可用的软件是最主要的进展指标。

8. 敏捷过程提倡可持续的开发。发起人、开发者和用户都应该始终保持稳定的工作步调。

9. 持续关注技术上的精益求精和优良的设计以增强敏捷性。

10. 简约 — 使必要的工作最小化的艺术 — 是成功的关键。

11. 最优的架构、需求和设计浮现于自组织的团队。

12. 团队定期不断地对如何更加有效地工作进行反思，并相应地调整、校正自己的行为。

七．敏捷的人

1

Agile简介

前面提到敏捷方法要以人为本，首先需要明确的是建立敏捷过程必须有敏捷的人。敏捷的人才有敏捷的思想。那么怎样才算敏捷的人呢，下面我们来分析下，

1. 首先有敏捷的编程技能，敏捷方法采用适应性方法进行设计，通过不断重构去适应新的需求和逼近设计目标。这就需要程序员有高超的设计和编程能力，能够高效率的开发和重构代码，并能高效的通过测试。

2. 另外，还要有敏捷的思想和个人素质，敏捷的人必须一切从敏捷出发，打破常规，高效率的工作，因此，必须有改变的勇气和信心，相信自己越变越好，程序越重构越好，而不是拒绝改变。

3. 然后，敏捷需要组织内部和组织之间要高效的协调，通信，项目才能平稳向前推进，这就要求程序员要具有高度的自律，高度的责任感，非凡的沟通能力。否则，敏捷无从谈起。

八．Agile的贡献和局限

敏捷的最大贡献在于它是对整个软件工程的一次再认识。具体到敏捷需求分析领域，其实涉及到一个核心问题：是否承认（软件）需求可以在一开始就搞清楚并确定下来？敏捷的答案是No！而在传统开发中，更多的是合同式验证的情形，大多数客户的思想基础都是基于需求最初就能确定下来的。但事实上，这在当前阶段基本属于“不可能完成的任务”，不符合软件开发本质。在敏捷需求分析中，需求应是贯穿于整个软件生命周期全过程中并在其中不断变更、迭代和完善。

任何方法都是有适用条件的。

1. 敏捷方法抛弃了繁琐的文档管理，就必须依靠程序员主动，开放，平凡的面对面的高效交流来达成对需求，目标，设计实现的理解；

2. 敏捷方法抛弃了机械、严格的过程控制，就必须依赖于程序员和开发团队的高标准自我要求：严格的自律，团队合作精神，个人高度自觉的主动性，责任感。

3. 敏捷方法的高效和高质量实际上是以程序员的高素质和开发团队的高度合作的开发文化为基础的。

因此敏捷方法的实施前提是必须找到愿意并有能力实施敏捷方法的团队。

但是不管怎样，敏捷方法提供了一种崭新的，不同于以往的软件开发过程方法，敏捷方法提倡的简化设计，简化流程，迭代方法，以人为本的思想都是非常值得任何软件组织研究和借鉴的，它也是以往的软件开发大师们的开发实践成功经验的总结，我们必须学习，领会其根本思想，然后根据本组织的情况，有条件的借鉴其实践方法，把敏捷方法和传统开发方法结合起来，不断改进，持续提高，才能建立起一套适合自己的，具有本组织特色的，行之有效的软件开发过程体系。

九．Agile反对的观点

要实施敏捷，首先需要做的是打破开发组织中的两个迷信，挣脱枷锁，才能轻装前进。

1. 一个迷信是软件开发可以成为生产线，每个岗位的职责可以被明确定义，各个岗位之间接口同样可以被明确定义，大家只要各司其职，高质量的软件就可以被生产出来。生产线是我们的愿望，但不是现实；按照这样的美好愿望去组织软件开发必然付出惨痛的代价。软件开发是一个高度复杂的团队智力活动，如同创作一件雕塑作品一样，在基本的职责框架下，团队内部必须协同合作，才能开发出高质量的软件。画地为牢是行不通的。

2. 另一个迷信是软件开发过程可以向建筑一样被准确地预测和计划，这同样是美好愿望而不是现实。敏捷号召的就是在这两个问题上回归现实。

2

Agile简介

Agile的应用

试举一例，比如说敏捷开发方法XP中提到要建立coding standard。然后大家要遵守它。但是如何保证大家都遵守coding standard呢？如果保证大家很好的遵守它并取得了很好的效果？敏捷方法很简单，取消繁琐的过程，它可能和传统的方法一样会有一个code review过程，但是不需要很多的记录，也不需要特定的形式。

1. 首先程序员要自觉地按照code standard去写程序并尽最大努力写好它。

2. 其次采用尽可能简化的方式请reviewer帮助程序员发现更多的问题，而不是为了惩罚，或者为了统计测量等其他任何无关的目的和任何与code review无关的任何行动。Review的过程集中于发现问题和解决问题，而不是记录问题和惩罚措施，这样就可以做到简单高效。但是前提是所有人已经适应了敏捷开发的文化和具备了敏捷开发的能力。

总结

敏捷方法是相对于传统软件过程方法而言是一种轻量级的方法，可以简化流程，提高效率。这是很多软件组织青睐敏捷方法的原因，但是敏捷方法不适放之四海而皆准的真理，不是任何组织，任何软件开发都可以使用XP（Extreme Programming，极限编程，敏捷方法的一种）的。敏捷方法有其适用的条件和适用场合，如果在没有满足使用条件的情况下使用敏捷方法，可能效果适得其反。因此必须分析组织的现状和实施敏捷方法的可行性。逐步导入敏捷方法，才有可能获得成功,实现敏捷方法的价值。

3

本文标签： 方法开发过程设计软件