敏捷软件过程的局限性.docxVIP

PAGE 1 PAGE 1 敏捷软件过程的局限性  软件开发人员和项目经理努力地评估机敏过程对他们的开发环境的适应性。本文指出很多已公布的机敏过程对不同的项目类型来说存在的局限性，机敏过程应用在这些项目中可能会存在问题。  绪论  当越来越多的组织要求通过准时部署基于Internet的服务来寻求获得竞争优势时，开发人员就承受不断增长的压力以尽快实现新的、增加的服务。机敏软件开发过程主要针对这个问题发展起来的，即在“网络时代”开发软件的问题。机敏方法采用技术上和管理上的过程，这些过程能持续地适应  (1)源自开发过程中获取的经验而进行的变更  (2)软件需求的变更  (3)开发环境的变更。  机敏过程特殊支持尽早尽快地交付可工作代码的产品，这通过迭代的开发过程完成的，其中每次迭代都注意提交可工作的代码以及其他制品（artifacts）以供客户评估，同时也供项目评估。机敏过程的支持者和批评者都强调在这些过程中注意代码。支持者经常争辩说代码是唯一重要的可交付的产品，可以忽视分析和设计模型、文档在软件开发、演化过程中的角色。机敏过程批评者指出，强调代码能带来全体记忆丢失（corporatememoryloss），因为没有重视编写良好的文档和模型来支持浩大、复杂软件系统的创造和演化。机敏支持者和批评者提出的声明引出这样的问题：在当今快速变化的开发环境中，什么样的实践、技术和基础结构适合软件开发过程？特殊是，对有关特定应用程序领域和开发环境的机敏过程适应性的问题的回答通常是依据轶闻报导。  本文，我们基于对已发表有关机敏过程的作品的分析介绍了我们所熟悉到的机敏过程的局限性。很多自称为“机敏”的过程在价值上、实践上和应用领域有很大的差别。因此评估全部机敏过程和识别适应于全部机敏过程的局限性不是一件简单的事情。我们的分析是依据对假设采用极限编程（XP）,Scrum,机敏统一过程，机敏建模以及机敏联盟提出的宣言的研究。这主要是一个分析性研究，由作者指导的几个XP项目经验作支持。  机敏联盟  最近几年的文献中，提出很多种称为“机敏”的过程。为了避免在什么样的过程是“机敏”的这个问题上引起混淆，17位业界专家在2001年召开的研讨软件过程将来发展趋势的一次会议上，就什么是“机敏”达成全都意见。这次会议的一个成果是成立了“机敏联盟”并发布了联盟机敏宣言(参考/principles.html)。这份联盟机敏宣言是“机敏软件开发”价值和目标的浓缩定义，并通过很多共同的原则进行了细化。这些原则如下所示。  1.我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满足。  2.在项目的整个开发期间，业务人员和开发人员必需每天在一起工作。  3.即使到了开发后期，也欢迎需求变化。  4.经常性地交付可以工作的软件。  5.可以工作的软件是主要的进度度量标准。  6.围绕被激励起的个体来构建项目。为他们供应所需的环境和支持，并信任他们能胜任工作。  7.最好的架构、需求和设计来自于自组织的团队。  8.在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。  9.机敏过程提倡可持续的开发速度。  10.不断地关注最优秀的技术和良好的设计能增加机敏能力。  11.简洁是根本的。  12.开发团队每隔一定时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整。  机敏过程分析  这一节我们在分析机敏联盟原则和机敏过程潜在的假定的基础上，争论了机敏过程的局限性。下一小节列出了在我们研究中识别出的管理上和技术上的假定，随后的一小节争论了由这些假定推导出的局限性。潜在的假定机敏过程声明的比传统说明性过程的优点是建立在这些假定正确有效的基础上。  这些假定在另外一篇论文中进行了更具体地争论。  假定1：客户要和开发团队协同工作，随时作好和开发人员交流的预备。而且，面对面的交流需要开发人员彼此位于很近的位置。  假定2：文档和软件模型在软件开发中不充当重要的角色。  假定3：软件需求和软件开发环境随着软件开发的发展而发展。  假定4：动态适应不断变化的项目和产品特征的开发过程，更有可能开发出高质量的产品。  假定5：开发人员具有正确地定义和适应过程的经验。换句话说，一个组织能建立由有丰富经验的问题  解决者组成的团队，他们在执行过程期间，能有效地改进过程。  假定6：项目的可见性能主要通过增量和一些度量的传递来获取。  假定7：软件制品（产品和过程）严格的评估仅限于经常非正