规模化敏捷开发的10个最佳实践（上）

【编者按】软件开发和采购人员常常会对现有软件开发方法、技巧和工具产生一些疑问。针对这些疑问，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.在整个生命周期中使用测试驱动理念

这一条若是用一句话来归纳就是开发以前先写好测试。若是开发的过程当中只考虑正常状况，那么后期就会过分依赖于测试来找出开发中忽略掉的状况。为了不这种状况在开发过程当中就要考虑到异常。若是可以先写好测试，使用测试驱动开发或验收测试驱动开发的方法，将使得咱们推荐的其余实践变得更有成效。

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

本文系 OneAPM 工程师编译整理。想阅读更多技术文章，请访问 OneAPM 官方博客。