摘要

软件开发人员和项目经理努力地评估敏捷过程对他们的开发环境的适应性。本文指出许多已公布的敏捷过程对不同的项目类型来说存在的局限性，敏捷过程应用在这些项目中可能会存在问题。 


绪论 

当越来越多的组织要求通过及时部署基于Internet的服务来寻求获得竞争优势时，开发人员就承受不断增长的压力以尽快实现新的、增强的服务。敏捷软件开发过程主要针对这个问题发展起来的，即在“网络时代”开发软件的问题。敏捷方法采用技术上和管理上的过程，这些过程能持续地适应

(1)源自开发过程中获取的经验而进行的变更
(2)软件需求的变更
(3)开发环境的变更。 

敏捷过程特别支持尽早尽快地交付可工作代码的产品，这通过迭代的开发过程完成的，其中每次迭代都注重提交可工作的代码以及其他制品（artifacts）以供客户评估，同时也供项目评估。敏捷过程的支持者和批评者都强调在这些过程中注重代码。支持者经常争论说代码是唯一重要的可交付的产品，可以忽视分析和设计模型、文档在软件开发、演化过程中的角色。敏捷过程批评者指出，强调代码能
带来全体记忆丢失（corporate memory loss），因为没有重视编写良好的文档和模型来支持庞大、复杂软件系统的创造和演化。 敏捷支持者和批评者提出的声明引出这样的问题：在当今快速变化的开发环境中，什么样的实践、技术和基础结构适合软件开发过程？特别是，对有关特定应用程序领域和开发环境的敏捷过程适应性的问题的回答通常是根据轶闻报导。

本文，我们基于对已发表有关敏捷过程的作品的分析介绍了我们所认识到的敏捷过程的局限性。许多自称为“敏捷”的过程在价值上、实践上和应用领域有很大的差别。因此评估所有敏捷过程和识别适应于所有敏捷过程的局限性不是一件容易的事情。我们的分析是根据对假设采用极限编程（XP）, Scrum , 敏捷统一过程，敏捷建模以及敏捷联盟提出的宣言的研究。这主要是一个分析性研究，由作
者指导的几个XP项目经验作支持。

敏捷联盟 

最近几年的文献中，提出许多种称为“敏捷”的过程。为了避免在什么样的过程是“敏捷”的这个问题上引起混淆，17位业界专家在2001年召开的研讨软件过程未来发展趋势的一次会议上，就什么是“敏捷”达成一致意见。这次会议的一个成果是成立了“敏捷联盟”并发布了联盟敏捷宣言(参考http://www.agilealliance.org/principles.html)。这份联盟敏捷宣言是“敏捷软件开发”价值和
目标的浓缩定义，并通过许多共同的原则进行了细化。这些原则如下所示。 

1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。

2. 在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。 

3. 即使到了开发后期，也欢迎需求变化。 

4. 经常性地交付可以工作的软件。 

5. 可以工作的软件是主要的进度度量标准。 

6. 围绕被激励起的个体来构建项目。为他们提供所需的环境和支持，并信任他们能胜任工作。 

7. 最好的架构、需求和设计来自于自组织的团队。 

8. 在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。 

9. 敏捷过程提倡可持续的开发速度。

10. 不断地关注最优秀的技术和良好的设计能增强敏捷能力。 

11. 简单是根本的。 

12. 开发团队每隔一定时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整。 


敏捷过程分析 


这一节我们在分析敏捷联盟原则和敏捷过程潜在的假定的基础上，讨论了敏捷过程的局限性。下一小节列出了在我们研究中识别出的管理上和技术上的假定，随后的一小节讨论了由这些假定推导出的局限性。 潜在的假定 敏捷过程声明的比传统说明性过程的优点是建立在这些假定正确有效的基础上。

这些假定在另外一篇论文中进行了更详细地讨论。 

假定1：客户要和开发团队协同工作，随时作好和开发人员交流的准备。而且，面对面的交流需要开发人员彼此位于很近的位置。 

假定2：文档和软件模型在软件开发中不充当重要的角色。 

假定3：软件需求和软件开发环境随着软件开发的发展而发展。 

假定4：动态适应不断变化的项目和产品特征的开发过程，更有可能开发出高质量的产品。 

假定5：开发人员具有正确地定义和适应过程的经验。换句话说，一个组织能建立由有丰富经验的问题

解决者组成的团队，他们在执行过程期间，能有效地改进过程。 

假定6：项目的可见性能主要通过增量和一些度量的传递来获取。 

假定7：软件制品（产品和过程）严格的评估仅限于经常非正式的审查和代码测试。 

假定8：重用性和通用性不应该是面向应用程序软件开发过程的目标。 

假定9：变更的成本不随着时间的变化而显著增加。 

假定10：软件可以被增量开发。 

假定11：无需为变更作设计，因为任何变更能通过重构代码有效地处理

敏捷过程的局限性 

上述的假定通常不是所有的软件开发环境都支持，尤其是也不是被所有的“敏捷”过程支持。这无需惊讶，任何一个敏捷过程都不是银弹（尽管有支持者热情地声明）。在这部分我们将描述敏捷过程通常不适应的情况。可能一些敏捷过程能更好地符合这些假定，而其他的敏捷过程能通过扩展解决这儿讨论的局限性。类似的扩展能合并通常与更多预言性开发实践有关的原则和实践到敏捷过程中。 

1.缺乏对分布式开发环境的支持：

 敏捷过程提倡的强调在实践中协作，不能很好地适应推动一些行业
实现全球化分布式软件开发环境。团队成员和客户在地理上分布的开发环境可能无法支持敏捷过程提倡的面对面的交流。在这种情况下，人们至少可能通过诸如视频会议的技术手段进行面对面地交流，不过这些技术太昂贵，而且不一定达到预期效果。


面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，但是不会经常发生，而且必须事先计划好以保证所有的相关人员都能参加。可以利用这种面对面的会议作为主要的同步事件，地理上分布的开发者

(1)可以了解其他人的进度

(2)讨论产品下一步开发的计划。

两次会议之间，文档（在代码之上）成为主要的交流方式。及时地创建和维护良好的需求和设计文档，对于保证分布式的开发成员对开发的产品保持一致的观点具有重要的作用。这不应该认为是需要对软件的所有方面都要写文档或建模，文档和模型仅是在对项目和项目
有关人员有价值的时候才创建和维护。 

[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>