本文内容包括：
开始之前：术语声明
大企业对敏捷实践的需求
敏捷配置管理实践
对于大系统的可扩展的敏捷配置管理
注释
参考资料
本文来自于 Rational Edge：由于其规模及复杂性，大企业更需要拥抱敏捷开发策略。通过本文了解如何通过敏捷配置管理环境来有效地协调成百上千的资源。
在我作为顾问的早期，很幸运我有机会接触一个使用了被称为极限编程（eXtreme Programming）方法的项目。这个项目的环境十分典型：二十个人，有限的复杂度与平台需求。最后这个项目成功了。新方法帮助我们按时交付并且降低了缺陷。之后，我又经历了各种更具挑战性的敏捷环境，包括很大的项目团队（一百多人）和固定的成本花销。一种最普遍的方案就是他们全部是单一的项目团队，即使有些团队的规模很大。尽管具备了这些经验，我仍然不满意于敏捷开发为企业带来的好处 -- 尤其是关于配置管理的敏捷实践和技术 -- 直到我在两年时间内与财富 100 企业的项目团队一起工作后才发生了改变。
当我作为一名顾问进入到公司后，我发现这是一家不使用常规源代码控制、只有少量自动化构建或自动化单元测试的企业。我们花费了几个月的时间，利用持续的集成、短迭代、和各种其他的敏捷实践与技术，最终建立了一个更灵活的项目团队。当项目成功后，团队成员就可以帮助其他团队使用敏捷方法了。十八个月后，我们已经有了六个遵循主要敏捷配置管理实践的项目。每个项目团队具备自己的代码库，但是他们会互相共享组件、测试和构建流程。程序员会在一天内多次检入代码，尽快地增加自动测试，甚至写了几行代码后就会重新编译。项目团队会在一天内多次运行他们自己的自动化测试组件和系统。企业开始从更健壮的代码库、更及时的交付、和更好的最终产品中获益。
从那时起，许多大公司的开发团队都希望了解敏捷是否适合他们。他们一直认为敏捷是无序的、混乱的，并且风险很大。没有什么比事实更有说服力了。我自己的经验证明了敏捷实践和技术能够提供可靠的灵活的配置管理环境，而这正符合了大公司保持竞争力，满足质量的目标。
我将在本文中展示部分基本的敏捷配置管理构建模块，并详细介绍如何使用这些实践为大型开发企业带来收益。
开始之前：术语声明
术语对于专业的软件开发来说既有益处又有坏处。也就是说，我们都利用术语来工作。不幸的是，我们往往使用它们的意思而使工作做得很糟糕。因此，在继续之前，我想首先花一些时间声明一下我将使用的术语。
由最先出现的开始 大型开发组织 可以有很多种形式。例如，它可以是一个大型项目，包括了上百人，为了计划和开发的目的分解为许多个子系统和子团队。它还可以是一家开发企业，包括许多相互联系的系统和项目团队。更一般的说法是，它可以是任何被描述为 "企业"的开发组织。 大的开发组织意味着多个团队和大量代码行。这些大型组织常常拥有不同阶段的开发、产品，或接近退役的系统；任意的数据库、文件仓库和其他的数据源；一系列不同的项目方案和委托；含有各种需求和议程的一群有趣的团队。这些大型组织常常接近（或已经陷于)复杂性之中。
此文章共有8页 1 2 3 4 5 6 7 8 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
