更高水平的， 敏捷开发 很容易定义。它描述了任意的坚持敏捷软件开发的宣称价值的开发方法（尤其是伪装成项目团队熟知的方法论）。 1 简短来说，这些值关注于个人和交互、工作软件和用户协作，它们承认改变是不可避免的甚至是有价值的软件开发部分。但是这一高级定义仅描述了敏捷团队的价值，而没有他们所做的内容。当我谈论敏捷所做的内容时，我是指敏捷团队尊循的实践和技术，诸如持续集成、自动化的单元测试和短叠代。敏捷社区中不断讨论着遵循敏捷实践却不使用敏捷值的团队是否能够被称为敏捷的。这些值是十分重要的，因为它们提供了适当的 Agie 实践和技术的实现指导。但是，我将会跨过这些争论，使用术语敏捷以鉴别敏捷团队使用的实践和技术。
然后， 配置管理 -- 可被描述为 "质量"的概念 -- 传统意义上具有多种不同定义。 2 大家似乎完全同意配置管理包括了鉴别系统条目和特定条目与系统的变化。一种狭义的配置管理的定义可以满足流行源代码控制系统的实现及使用。同时， 一种广义的定义也许涵盖了全部项目团队和所有工件，包括全部的确保系统正确操作的代码和行为，所有改变控件行为，和追踪团队每天的变化。我将在本文中对配置管理采用一种中立的定义，包括了程序员所做的组织系统组件，了解任意时刻的系统状态、管理演化、确保开发过程中正确的系统功能。
大企业对敏捷实践的需求
现在我们已经符合了讨论的标准，让我们看看它们是如何在一起工作的。首先，小型项目没有了质量不一和不正规的配置管理实践时，大部分读者可能都会同意大型开发组织都会需要正规的配置管理方法。这种认识在六年前被认为是十分大胆的，而我根据针对大型开发遇到的问题所做的观察得出的这一结论。当几十种（没有上百）产品组件正在运行，并且您与上百个（没有上千）开发者协作时，潜在的混乱、迟缓的开发周期、和很差产品质量的可能性是十分高的。大型系统变得过于复杂与迅速以至于不能靠手动系统加以维护了。因此在这些企业中，自动化、流程控制、管理变化、和团队协调对于保证开发质量是十分必要的。
其次，让我们讨论一下敏捷开发和配置管理的混合。当敏捷开发还是一种新兴的，软件开发专家最为重视的破坏进度、开销溢出、项目失败特点的主题时，没有人谈论配置管理的敏捷方法。但是敏捷证明了它是一种极好的配置管理实践，因为敏捷团队需要健壮的灵活的代码库以响应不断变化的业务环境和客户需求。一种方式是在项目中经常性的集成代码（一般来所，一天集成几次）。另一种敏捷的重要原则就是将测试作为一种有效的配置管理组件。在许多敏捷团队中，全部新代码都要经过自动化的单元测试，每次执行架构都会运行所有单元测试。未通过的单元测试将被视为与编译错误一样严重的问题。在任何好的配置管理流程中，敏捷团队都需要了解所有代码行的健康度。而且，他们努力保持对代码状态的控制。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
