【编者按】软件开发和採购人员常常会对现有软件开发方法、技巧和工具产生一些疑问。针对这些疑问，Kevin Fall 整理了五个软件方面的话题：Agile at Scale，Safety-Critical Systems。Monitoring Software-Intensive System Acquisition Programs，Managing Intellectual Property in the Acquisition of Software-Intensive Systems。以及 Managing Operational Resilience。

该系列的第一篇主要关注 Agile at Scale 问题，本文由

utm_source=Community&utm_medium=Article&utm_term=AgileOne&utm_campaign=AugSoftArti&from=matefiauao">OneAPM project师编译整理：

这里会有一系列文章来介绍这5个话题相关的最佳实践。

第一组文章分为上下两篇，介绍了规模化敏捷开发中的挑战以及总结出的10个最佳实践。限于篇幅问题，本文仅仅介绍了10个最佳实践中的前5个，下一篇将介绍余下的5个最佳实践和应用这些最佳实践过程中的3个建议。

规模化敏捷开发所面临的挑战

敏捷开发的概念在过去的十年间已经得到了广泛的使用，也使得软件开发团队能够开发出更好的软件。之所以能取得这种效果。主要是敏捷开发的方法能够提高项目进展的透明度，同一时候用户还能够非常早就预见产品的雏形。并与开发团队进行交流。

然而，达到商业目的远远不是开发出好软件这么简单。而假设期望规模化敏捷则必须先关注下面几个方面：

1．团队规模

试想一下，敏捷开发的方法应用在超过100人的开发团队中会有什么效果？当这支开发团队须要与其它部门在质检、集成、项目管理、市场运营等进行合作和沟通以保证产品的顺利交付时又会有怎样的问题？通常极限编程这类的敏捷开发方法仅仅适用于7至10人的小型团队中。而大型团队则须要分为几个小团队。同一时候须要和一些非开发的人员进行配合。眼下已经有人在研究怎样更好地解决团队规模所带来的协作问题了。

2．系统复杂程度

通常情况下。大型系统会包含较多的特性和新技术，还要与其它系统进行通信和集成，并且要照应不同用户群的需求。须要搞清楚是否有实时性、可靠性和安全性的要求，以及相关利益者都是谁。通常复杂系统都须要经过严格的验证。这使得敏捷开发中的高速迭代变得复杂化了。

3．项目规划

有多长时间用于系统开发？系统维护的周期是多长？通常大型系统所需的开发和维护时间都比敏捷开发适用的系统长一些，并且须要关注可能的更改和又一次设计，还可能会被要求交付不同的版本号。

搞清楚这些有助于决定对项目来说哪些才是衡量项目成功的重要指标。

规模化敏捷开发的最佳实践

各个企业的情况有所不同，所以怎样应用这些最佳实验须要推断它能否使企业得益。

特别要注意企业的商业目的、现有的流程和企业文化，由于全部的实践都有其局限性。不可能存在所谓的万金油。选择这些最佳实践时最好能够让它们能互相配合，并且要依据企业的实际情况做出一定的调整。

1.团队协作乃是第一要务

Scrum 是眼下使用范围最广的敏捷项目管理方法。简单来说 Scrum 开发环境仅仅须要一个 Scrum 团队。这一团队须要具备说明需求、系统架构、设计、编码以及測试所需的知识和能力。

然而。在项目的规模和复杂程度添加之后，单一的 Scrum 团队可能就不能满足开发的需求了，这时就要依据系统特性和服务来划分不同的小团队。对一个项目假设已经决定了要使用 Scrum 这种项目管理方法。能够对各个 Scrum 小团队也使用 Scrum 的方法进行管理。这就须要一个另外的协作团队，这个协作团队有两个责任：一是确定团队之间所交换的信息，这是为了解决团队之间的依赖性和沟通问题。二是对团队之间的协作问题和潜在的风险进行分析并解决。

协作团队的成员通常来自各个开发团队，如此协作团队的成员就能够了解整个项目全部的功能，另外也可能另一些用户界面设计、系统架构、測试和部署的专业人员參与。这一协作团队能够帮助各个开发团队之间实现目标、问题和风险的交流和共享。但当协作团队自己人数也多起来的时候则要当心了。

2.使用 Architectural Runway 来管理技术复杂性

严格的安全要求和任务关键需求会添加技术上的复杂性以及风险。假设一项任务在一次迭代中无法完毕，同一时候也无法分解成较小的任务交给多个小组并行的话。这就说明这项任务有着技术上的复杂性。须要解决技术复杂性的问题。管理员必须在项目早期就完毕最重要的软件架构特性，有时甚至要将这个问题提升到整个企业的高度，比方对基础设施平台或者产品线。

敏捷开发里把这个叫做 Architectural Runway。它的目的是为以后的迭代提供一个相对稳定的基础。有一个相对稳定的基础对多个团队是非常重要的。软件的架构能够决定系统特性的重要性进，从而决定他们在开发中的优先级。通过定义 Architectural Runway 并在系统开发过程中对其进行扩展，开发团队能够优先开发架构跑道中的特性以满足用户的需求。

Architectural Runway 也能够帮助开发团队在项目早期就发现技术上的风险，并避免技术复杂性的问题。此外，系统质量上的要求如安全性、可用性和性能也是越早确定越好，否则非常可能得进行大的修改或者造成项目延期。开发系统功能时假设所须要的基础设施已经就位也能添加需交付功能的确定性。

3.基于

assetID=87764">特性开发与系统分解的结合

敏捷团队通常的做法是在系统的全部组件中实现一个特性。这使得开发者能够专注于完毕对用户有意义的特性，而不必等待其它人的开发完毕才干进行。这个途径被称之为「vertical alignment」。由于系统中每一个实现这个特性的组件都在各个团队中独立开发。

但系统的分解也能够是水平的，这主要基于系统的架构。这个方案主要被用于一些通用服务商，由于它们能够被很多其它的复用。

不管是针对特性进行开发还是对系统进行水平分解，其目的都是依据系统的分解来安排开发团队并且解耦以便保持进度。当须要在敏捷稳定性和进度上保持平衡时能够採用的策略是先开发一个通用服务的平台，再在此基础上以插件的方式高速进行基于特性的开发。

4.使用质量评估来决定架构上的需求

Scrum所注重的是解决用户面对的特性问题，这确实也对系统成功与否起到重要作用。但当注意力全然放在功能特性上的时候，往往就会忽略架构上的需求。

这里的建议是在开发 Architectural Runway 时收集、记录、沟通和确认潜在的系统质量上的要求。而大型系统来说由于维护周期都比較长，所以这点尤为重要。

在项目早期就应该对质量上的要求进行评估。以便决定哪些架构上的需求应该尽快满足或者有哪些方式交付用户需求的捷径。

举个样例说。比方一个系统要满足100万用户使用。

这是说立马就要满足100万用户使用呢？还是如今它事实上仅仅是一个測试产品再比方系统一般都会使用一些框架，理解系统质量要求能够帮助开发者确定哪些架构上的需求已经被框架攻克了。当须要解决安全和部署环境方面需求变化时，架构上的需求必须给予最高的优先级。

5.在整个生命周期中使用測试驱动理念

这一条假设用一句话来概括就是开发之前先写好測试。假设开发的过程中仅仅考虑正常情况，那么后期就会过度依赖于測试来找出开发中忽略掉的情况。

为了避免这种情况在开发过程中就要考虑到异常。

假设能够先写好測试。使用測试驱动开发或验收測试驱动开发的方法，将使得我们推荐的其它实践变得更有成效。

原文链接：10 Recommended Practices for Achieving Agile at Scale

OneAPM 是应用性能管理领域的新兴领军企业。能帮助运维人员进行故障预警和定位。降低业务系统维护的工作量。同一时候还能提供可追溯的性能数据，量化运维部门的业务价值。

想告别加班熬夜，欢迎免费注冊使用！