【编者按】软件开发和采购人员经常会对现有软件开发方法、技巧和工具产生一些疑问。针对这些疑问，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 问题，本文由 OneAPM 工程师编译整理：
这里会有一系列文章来介绍这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.基于特性开发与系统分解的结合
敏捷团队通常的做法是在系统的所有组件中实现一个特性。这使得开发人员能够专注于完成对用户有意义的特性，而不必等待其他人的开发完成才能进行。这个途径被称之为「vertical alignment」，因为系统中每个实现这个特性的组件都在各个团队中独立开发。但系统的分解也可以是水平的，这主要基于系统的架构。这种方法主要被用于一些通用服务商，因为它们可以被更多的复用。
无论是针对特性进行开发还是对系统进行水平分解，其目的都是根据系统的分解来安排开发团队并且解耦以便保持进度。当需要在敏捷稳定性和进度上保持平衡时可以采用的策略是先开发一个通用服务的平台，再在此基础上以插件的方式快速进行基于特性的开发。
4.使用质量评估来决定架构上的需求
Scrum所注重的是解决用户面对的特性问题，这确实也对系统成功与否起到重要作用。但当注意力完全放在功能特性上的时候，往往就会忽略架构上的需求。
这里的建议是在开发 Architectural Runway 时收集、记录、沟通和确认潜在的系统质量上的要求。而大型系统来说由于维护周期都比较长，所以这点尤为重要。在项目早期就应该对质量上的要求进行评估，以便决定哪些架构上的需求应该尽快满足或者有哪些方式交付用户需求的捷径。
举个例子说，比如一个系统要满足100万用户使用。这是说立刻就要满足100万用户使用呢？还是现在它其实只是一个测试产品再比如系统一般都会使用一些框架，理解系统质量要求可以帮助开发人员确定哪些架构上的需求已经被框架解决了。当需要解决安全和部署环境方面需求变化时，架构上的需求必须给予最高的优先级。
5.在整个生命周期中使用测试驱动理念
这一条如果用一句话来概括就是开发之前先写好测试。如果开发的过程中只考虑正常情况，那么后期就会过度依赖于测试来找出开发中忽略掉的情况。为了避免这种情况在开发过程中就要考虑到异常。如果能够先写好测试，使用测试驱动开发或验收测试驱动开发的方法，将使得我们推荐的其他实践变得更有成效。