|
本文来自于 Rational Edge：由于其规模及复杂性，大企业更需要拥抱敏捷开发策略。通过本文了解如何通过敏捷配置管理环境来有效地协调成百上千的资源。项目管理者联盟
在我作为顾问的早期，很幸运我有机会接触一个使用了被称为极限编程(eXtreme Programming)方法的项目。这个项目的环境十分典型：二十个人，有限的复杂度与平台需求。最后这个项目成功了。新方法帮助我们按时交付并且降低了缺陷。之后，我又经历了各种更具挑战性的敏捷环境，包括很大的项目团队(一百多人)和固定的成本花销。一种最普遍的方案就是他们全部是单一的项目团队，即使有些团队的规模很大。尽管具备了这些经验，我仍然不满意于敏捷开发为企业带来的好处 -- 尤其是关于配置管理的敏捷实践和技术 -- 直到我在两年时间内与财富 100 企业的项目团队一起工作后才发生了改变。项目管理者联盟
当我作为一名顾问进入到公司后，我发现这是一家不使用常规源代码控制、只有少量自动化构建或自动化单元测试的企业。我们花费了几个月的时间，利用持续的集成、短迭代、和各种其他的敏捷实践与技术，最终建立了一个更灵活的项目团队。当项目成功后，团队成员就可以帮助其他团队使用敏捷方法了。十八个月后，我们已经有了六个遵循主要敏捷配置管理实践的项目。每个项目团队具备自己的代码库，但是他们会互相共享组件、测试和构建流程。程序员会在一天内多次检入代码，尽快地增加自动测试，甚至写了几行代码后就会重新编译。项目团队会在一天内多次运行他们自己的自动化测试组件和系统。企业开始从更健壮的代码库、更及时的交付、和更好的最终产品中获益。项目管理者联盟
从那时起，许多大公司的开发团队都希望了解敏捷是否适合他们。他们一直认为敏捷是无序的、混乱的，并且风险很大。没有什么比事实更有说服力了。我自己的经验证明了敏捷实践和技术能够提供可靠的灵活的配置管理环境，而这正符合了大公司保持竞争力，满足质量的目标。项目经理博客
我将在本文中展示部分基本的敏捷配置管理构建模块，并详细介绍如何使用这些实践为大型开发企业带来收益。项目管理者联盟
开始之前：术语声明项目管理者联盟
术语对于专业的软件开发来说既有益处又有坏处。也就是说，我们都利用术语来工作。不幸的是，我们往往使用它们的意思而使工作做得很糟糕。因此，在继续之前，我想首先花一些时间声明一下我将使用的术语。项目管理者联盟
由最先出现的开始 大型开发组织 可以有很多种形式。例如，它可以是一个大型项目，包括了上百人，为了计划和开发的目的分解为许多个子系统和子团队。它还可以是一家开发企业，包括许多相互联系的系统和项目团队。更一般的说法是，它可以是任何被描述为 "企业"的开发组织。 大的开发组织意味着多个团队和大量代码行。这些大型组织常常拥有不同阶段的开发、产品，或接近退役的系统;任意的数据库、文件仓库和其他的数据源;一系列不同的项目方案和委托;含有各种需求和议程的一群有趣的团队。这些大型组织常常接近(或已经陷于)复杂性之中。项目管理论坛
更高水平的， 敏捷开发 很容易定义。它描述了任意的坚持敏捷软件开发的宣称价值的开发方法(尤其是伪装成项目团队熟知的方法论)。 1 简短来说，这些值关注于个人和交互、工作软件和用户协作，它们承认改变是不可避免的甚至是有价值的软件开发部分。但是这一高级定义仅描述了敏捷团队的价值，而没有他们所做的内容。当我谈论敏捷所做的内容时，我是指敏捷团队尊循的实践和技术，诸如持续集成、自动化的单元测试和短叠代。敏捷社区中不断讨论着遵循敏捷实践却不使用敏捷值的团队是否能够被称为敏捷的。这些值是十分重要的，因为它们提供了适当的 Agie 实践和技术的实现指导。但是，我将会跨过这些争论，使用术语敏捷以鉴别敏捷团队使用的实践和技术。项目管理者联盟
然后， 配置管理 -- 可被描述为 "质量"的概念 -- 传统意义上具有多种不同定义。 2 大家似乎完全同意配置管理包括了鉴别系统条目和特定条目与系统的变化。一种狭义的配置管理的定义可以满足流行源代码控制系统的实现及使用。同时， 一种广义的定义也许涵盖了全部项目团队和所有工件，包括全部的确保系统正确操作的代码和行为，所有改变控件行为，和追踪团队每天的变化。我将在本文中对配置管理采用一种中立的定义，包括了程序员所做的组织系统组件，了解任意时刻的系统状态、管理演化、确保开发过程中正确的系统功能。项目管理者联盟
大企业对敏捷实践的需求项目管理者联盟
现在我们已经符合了讨论的标准，让我们看看它们是如何在一起工作的。首先，小型项目没有了质量不一和不正规的配置管理实践时，大部分读者可能都会同意大型开发组织都会需要正规的配置管理方法。这种认识在六年前被认为是十分大胆的，而我根据针对大型开发遇到的问题所做的观察得出的这一结论。当几十种(没有上百)产品组件正在运行，并且您与上百个(没有上千)开发者协作时，潜在的混乱、迟缓的开发周期、和很差产品质量的可能性是十分高的。大型系统变得过于复杂与迅速以至于不能靠手动系统加以维护了。因此在这些企业中，自动化、流程控制、管理变化、和团队协调对于保证开发质量是十分必要的。pmp.mypm.net
其次，让我们讨论一下敏捷开发和配置管理的混合。当敏捷开发还是一种新兴的，软件开发专家最为重视的破坏进度、开销溢出、项目失败特点的主题时，没有人谈论配置管理的敏捷方法。但是敏捷证明了它是一种极好的配置管理实践，因为敏捷团队需要健壮的灵活的代码库以响应不断变化的业务环境和客户需求。一种方式是在项目中经常性的集成代码(一般来所，一天集成几次)。另一种敏捷的重要原则就是将测试作为一种有效的配置管理组件。在许多敏捷团队中，全部新代码都要经过自动化的单元测试，每次执行架构都会运行所有单元测试。未通过的单元测试将被视为与编译错误一样严重的问题。在任何好的配置管理流程中，敏捷团队都需要了解所有代码行的健康度。而且，他们努力保持对代码状态的控制。项目管理者联盟
最后，就是敏捷开发和大型开发组织。所有的大企业确实可从集成的敏捷开发部分获得收益。理所当然,有独特的大型开发组织的挑战，例如，与多个项目、系统、数据源连接的逻辑行为外的个人与团队间的通信与协作。但是无论是否遵循敏捷方法，大型组织都有其需要面对的问题。转自项目管理者联盟
敏捷开发能为大型企业提供什么?首先，敏捷能够通过自动化的实现任务以减少人类所犯错误并使得团队利用更少的资源作更多工作以提高团队效率。其次，敏捷能够帮助大型企业改进质量，更有效的处理回馈给开发成员的改变，从而更迅速的解决问题。第三，敏捷能够通过使用叠代计划、分析、开发行为 -- 这些可由系统根据所设计的代码自动化的产生 -- 替换庞大的(且很快过期的)需求文档，以进行更丰富更及时地沟通。项目管理者联盟
最后，敏捷配置管理方法可以在项目级或企业级加以实现。不需要在这之前考虑一个组织，因为单个项目可以是一种实验性的或想法孵化器。同时，当在企业级实现了敏捷配置管理实践，那么企业必须为每个项目团队提供足够的灵活性与自主性，实现其最佳解决方案。项目管理者联盟
敏捷配置管理实践club.mypm.net
精简进程和自动化是敏捷配置管理方法的基础。 3 每一个活动(来自于代码检测确定损坏测试)都应很容易的执行，并为单个程序员和整体团队提供快速反馈。而且，敏捷团队力图使得这一行为自动化的记录于文档中。例如，自动化的构建仅需要写入它的执行脚本中。可以很容易的得出包括由 Microsoft Word 所创建的过期文档，"指南"文档在内的良好自动化构建脚本收集的好处。项目管理者联盟
已根据各种项目环境中的用途标识出了组成敏捷配置管理的实践 -- 无论大或小，简单或复杂。 我将在本部分中探讨实践，下一部分讨论针对大型企业特殊需求的应用。talent.mypm.net
源代码控制项目管理者联盟
这是常常会忘记的重要敏捷配置管理的组件，并不是因为组成敏捷团队不使用源代码控制。它常常被忘记是因为大部分敏捷团队假定每个项目都会有一个源代码控制系统，并且每个项目都会正确的使用它。一般的源代码控制系统都会有许多部分，例如版本化、回滚、打标签以及合并等。但是更重要的是，源代码控制为全部项目团队或开发组织的代码行提供了可靠的记录位置 。这仅仅当每名程序员能够经常性的检入系统代码时才会发生。我的意思是至少一天一次。这时，项目能够了解在哪里找到当前系统。它不会由于不同的开发工作站，或位于不同地点的共享服务器造成支离破碎。当前系统(或仅仅几小时前)总是检查源代码控制系统。项目经理博客
重申一下，仅仅因为项目或组织具有源代码控制系统不意味着系统支持敏捷配置管理方法。在我管理几个团队的客户端，两百名员工的开发组织使用企业级的源代码控制授权工具。但是系统却有重大的瑕疵：执行一次 check-in 要花费数小时!因此，团队仅仅在不得已的时候才做一次 check in -- 在发布到产品环境之前。一种普通的源代码控制系统对于一家大型企业十分有益(之后会做解释)，但是仅仅限于程序员和团队能够以具有时效的方式检入/检出代码的情况。项目管理者联盟
我将对源代码控制作最后的解释。团队不应该仅仅对所写代码进行版本控制;还必须对编译与测试代码的流程(或脚本)进行版本控制。如果团队需要先前的代码，那么就可以回溯到所需的构建和测试流程。项目管理者联盟
构建自动化项目管理者联盟
自动化构建是团队用以评估当前软件或系统稳定性的第一步。而且，自动化的构建还可以降低程序花费在不必要任务上的时间，并且减少了来自开发流程的瓶颈(也就是，团队依靠于一个构建人员或一个独立的构建团队)，从而实现了对于改变的更迅速的响应。项目管理者联盟
|
