论敏捷在软件开发中的应用

1、敏捷在软件开发中的应用摘要本文从敏捷方法的定义，提出背景，实施方法等方面对敏捷方法进行描述，并与传统软件工程方法相对比，分析敏捷开发的优劣。通过实际软件开发的案例分析软件生产的价值观，得出敏捷方法在软件开发中的价值。关键词：敏捷开发；增量；迭代；用户故事；文档；软件工程；精益生产第一章敏捷开发概述1.1敏捷开发的定义从广义上来给敏捷开发下定义，敏捷开发（agiledevelopment）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。1.2敏捷开发提出的背景在实践中，开发人员常常埋怨以精确方法工作的方式。大部分技术人员认为，尽管各种新技术非常吸引人，但是在实践中，很少按照正规方法的复杂流程一步一步前进，RUP、ISO9000，……开发人员常常会被浩瀚的文档所淹没，被繁文缛节的过程压垮。基于对传统软件工程存在的种种弊端，2001年2月，敏捷联盟会议在犹他州的雪鸟城召开。敏捷联盟是1。

2、7位不同敏捷开发方法的提倡者共同成立的，目的是推进敏捷开发方法的研究和应用，他们并不要求强制使用某种开发方法，而是提出了敏捷开发的几个核心价值和基本原则：核心价值:个人和交流重于过程和工具正在运行的软件本身重于复杂的文档与客户的沟通和交流重于使用合同约束客户对变化的快速响应重于跟随计划基本原则:最高目标是通过快速的和经常的发布软件满足客户的需要提交软件的周期为几个星期到几个月产生正确的软件是衡量进度的首要标准主动接受需求的改变而不是拒绝商务人员和开发人员工作在一起个人必须有动力，要创造环境支持他们的要求，信任他们最有效的交流方法是面对面的交流最好的结构，需求和设计来自于自组织的团队（self-organizingteam），允许任何人提出想法和建议持续改进设计和编码鼓励正常工作，减少长时间加班。

3、保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难定期调整过程，获得更高效率1.3敏捷开发的方法前面提到的这4个核心价值观会导致高度迭代式的、增量式的软件开发过程，并在每次迭代结束时交付经过编码与测试的软件。接下来几节覆盖了敏捷开发小组的主要工作方式，包括：增量与迭代式开发作为一个整体工作按短迭代周期工作每次迭代交付一些成果关注业务优先级检查与调整1.3.1增量与迭代式开发从下图可以直观的看出增量与迭代式开发的含义：增量开发，意思是每次递增的添加软件功能。每一次增量都会添加更多的软件功能。使用增量法逐渐地增进功能，那么如果开发花费的时间多于预期，就可以将迄今为止已经增量构建的功能发布出去。（在软件开发的实践中往往项目开发花费的时间大于预期。）增量地释放版本，可以实际地得到已创造的商业价值。因为在人们开始使用构建好的软件之前，软件开发方是不会真正地得到投资回报的。在那之前，预期的商业价值只是一种估计。如果估算软件开发是困难的，那么就尝试估。

4、算投资回报率吧。迭代式开发：在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，软件开发经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。笔者对迭代开发的理解是先构建软件，然后评估它是否能够正常的工作，然后对其作出修改。而且是根据用户需求的不断变化，不停的对其进行修改，不停的校验是否满足客户的需求，通过迭代找到正确的解决方案。从XP、Crystal、RUP、ClearRoom等方法学中对比，体会迭代设计的精妙之处：每一次的迭代都是在上一次迭代的基础上进行的，迭代将致力于重用、修改、增强目前的架构，以使架构越来越强壮。在软件生命周期的最后，除了得到软件，还得到了一个非常稳定的架构。对于一个软件组织来说，这个架构很有可能就是下一个软件的投入或参考。1.3.2敏捷小组作为一个整体工作项目取得成功的关键在于，所有的项目参与者都把自己看作朝向一个共同目标前进的团队的一员。“扔过去不管”的心理在敏捷开发项目中是。

5、没有市场的。分析师不会把需求“扔”给设计师；设计师和架构师不会把设计“扔”给编码人员；编码人员不会把只经过部分测试的代码“扔”给测试人员。一个成功的敏捷开发小组应该具有“我们一起参与其中”的思想。虽然敏捷开发小组是以小组整体进行工作，但是小组中仍然有一些特定的角色。有必要指出和阐明那些在敏捷估计和规划中承担一定任务的角色。第一个角色是产品所有者(productowner)。产品所有者的主要职责包括：确认小组的所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具价值的功能，以及做出决定使得对项目的投入可以产生良好的回报。在商业软件开发中，产品所有者通常是公司的市场部门或者产品管理部门的人员。而在开发内部使用的软件时，产品所有者则可能是用户、用户的上级、分析员，也可能是为项目提供资金的人。第二个角色是客户(customer)。客户是做出决定为项目提供资金或者购买软件的人。在一个开发内部使用的软件的项目中，客户通常是来自另一个团组或者部门的代表。在这样的项目中，产品所有者和客户的角色常常是重合的。而对一个商业产品来说，客户就是购买这个软件的人。无论是哪种情况，客户都可能是，。

6、也可能不是软件的用户(user)。用户当然也是一个主要的角色。另一个值得注意的角色是开发人员(developer)。这里使用开发人员来概指所有开发软件的人。它包括了程序员、测试人员、数据库工程师、可用性专家、技术文档编写者、架构师、设计师，等等。使用这一定义，即使是产品所有者在很多项目中也可以被看作是开发人员。最后一个角色是项目经理(projectmanager)。如Highsmith(2004a)所述，在敏捷开发项目中，项目经理的角色发生了变化。敏捷开发项目经理会更多地关注领导而不是管理。在某些敏捷开发项目中，承担项目经理角色的人也会承担其他的角色，通常是作为开发人员，少数时候也会担任产品所有者。1.3.3敏捷小组按短迭代周期工作在敏捷开发项目中，对开发阶段没有什么重要的分隔——没什么先期需求阶段，然后是分析阶段，然后是架构设计阶段，等等。根据您实际选择的或者定义的敏捷开发过程，您可以在项目的最开始设置一个很短的设计、建模或其他阶段。但只要项目真正开始，在每次迭代中都会同时进行所有的工作(分析、设计、编码、测试，等等)。迭代是受时间框(timebox)限制的，意味着即使放弃一些功能，。

7、也必须按时结束迭代。时间框一般很短。大部分敏捷开发小组采用2～4周的迭代，但也有一些小组采用长达3个月的迭代周期仍能维持敏捷性。大多数小组采用相对稳定的迭代周期长度，但是也有一些小组在每次迭代开始的时候选择合适的周期长度。1.3.4敏捷小组每次迭代交付一些成果比选择的特定迭代周期长度更重要的是，开发小组在迭代中把一个以上不精确的需求声明变成经过编码、测试，实际可以交付的软件。当然，大多数小组不会把每次迭代的结果都交付给用户；敏捷开发的目标只是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些小功能，但是增加的每个功能都经过编码、测试，达到了可以发布的质量。在每次迭代结束的时候让产品达到潜在可交付状态是很重要的。实际上，这并不是说小组必须全部完成发布所需的所有工作，因为他们通常并不会每次迭代都真的发布产品。例如，我曾经参与一个小组的工作，他们需要在发布产品之前对软硬件都进行2个月的MTBF(MeanTimeBetweenFailure，平均无故障时间)测试。他们不能缩短这2个月的时间，因为这是他们的客户通过合同约定的，而且检查硬件故障也需要这么多时间。这个小组按照4周的迭代周期工作。

8、，他们的产品在每次迭代结束的时候除了没有进行这2个月的MTBF测试，都达到了确实可以发布的状态。由于单次迭代并不总能提供足够的时间来完成足够满足用户或客户需要的新功能，因此我们需要引入更广义的发布(release)概念。一次发布由一次或以上(通常是以上)相互接续，完成一组相关功能的迭代组成。最常见的迭代一般是2～4周，一次发布通常是2～6个月。例如，在一个投资管理系统中，一次发布可能包括所有与买入和卖出共同基金和货币市场基金有关的功能。这需要6次2周的迭代来完成(大约3个月)。第二次发布可能增加了股票和债券交易，需要4次2周的迭代。可以按不同的间隔进行发布。也许需要6个月来完成第一次发布，而接下来的发布则可能在3个月以后，等等。1.3.5敏捷小组关注业务优先级敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者所制定的顺序交付功能，而产品所有者一般会按照使机构在项目上的投资回报最大化的方式来确定功能的优先级，并将它们组织到产品发布中。要达到这一目的，需要根据开发小组的能力和所需新功能的优先级建立一个发布计划。要让产品所有者在确定功能的优先级时具有最大的灵活性，就。

9、必须在编写功能时使它们相互之间的技术依赖性最小化。如果选择一个功能要求先开发另外的3个功能，产品所有者就很难在发布计划中确定功能的优先级。开发小组不太可能达到绝对没有任何依赖的目标；但是，把依赖性控制在最低程度则是相当可行的。其次，敏捷开发小组关注完成和交付具有用户价值的功能，而不是完成孤立的任务(任务最终组合成具有用户价值的功能)。达到这个目的的最佳方法之一就是采用一种表示软件需求的轻量级技术(Cohn2004)，即用户故事。一个用户故事(userstory)是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑用户故事是比较有益的：“作为〈用户的类型〉，我希望可以〈能力〉以便〈业务价值〉。”以这样的模板作为例子，您可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN找到一本书，以便更快找到正确的书。”用户故事是轻量级的，因为并不需要一开始就把它们全部收集和记录下来。与写下一篇冗长的需求说明相比，敏捷开发小组发现采用刚好及时的需求分析方法更有效。通常可以通过在记录卡片上写下一个用户故事的简短说明来开。

10、始，对较大的或者分布式的小组，则可以把它录入计算机中。不过故事卡片只是个开始，对每个用户故事，开发人员和产品所有者都应根据需要进行交流。这些交流在需要时进行并且应包含所有必需的人。使用基于用户故事的需求分析方法时，仍可能需要编写文档。不过，工作重点在很大程度上从文档编写转移到了口头的交流。1.3.6敏捷小组进行检查和调整任何项目开始的时候所建立的计划都不是对将来会发生些什么事情的保证。事实上，它只是一个当前的猜测。有很多事情可以让这个计划失效——项目成员的增减、某种技术比预期的效果好或差、用户改变了想法、竞争者可能会迫使我们做出不同的或者更快的反应，等等。对每个这样的变化，敏捷开发小组都把它看作为了更好地反映当前的实际情况而更新计划的机会和需要。在每次新迭代开始的时候，敏捷开发小组都会结合在上一次迭代中获得的所有新知识作出相应的调整。如果小组认识到一些可能影响到计划的准确性或是价值的内容，他们就会调整计划。小组可能发现他们过高或过低地估计了自己的进展速度，或者发现某项工作比原来以为的更耗费时间，从而影响到计划的准确性。计划的价值也可能由于产品所有者获得了期望用户或是可能用户的想法而发生改。