在敏捷世界中构建软件平台的五项首要挑战.docVIP

在敏捷世界中构建软件平台的五项首要挑战 　　引子 　　过去十年间，敏捷软件开发赢得了大好发展局面，被众多不同规模组织采用[1]。敏捷方法宣扬一整套价值观，并且提出了一系列实践活动去帮助获得并维护这些价值。尽管从一开始，敏捷方法常以提升作为工作单元的小团队的效率为中心，但最近有趋势将敏捷方法拓展到企业层面[3]。然而，在企业层面会产生新的问题，可能需要重新考虑敏捷软件开发的某些价值观与实践活动。构建软件平台来实现企业范围重用策略，是主要问题之一。在本文中，我列举了五项首要挑战，敏捷组织在决心采取软件平台战略时应该准备面对它们。 　　软件平台是什么？ 　　软件平台是由一组子系统和接口构成的一个通用基础架构，支撑相关产品在其上开发[4]。可以把软件平台看作实现组织层面重用的一个战略手段。很多组织曾表明，应用软件重用能带来很多好处，如：减少开发和测试工作从而更快交付产品、开发和维护成本更低、重用部件具备更高品质、重用被证明过的解决方案风险更低、更容易估算项目的时间与成本。 　　五项首要挑战 　　采用软件平台策略是一个根本性的改变，需要组织重新审视并调整已有的做法。单就敏捷而言，如果不加考虑地沿用某些敏捷原则和实践，反而会制造新的挑战。在本文中，我们会集中讨论五个主要问题，即：特性团队、团队自主管理、业务价值、代码所有权以及稳定性。虽然这里列出的可能不是全部，但它们应该是最明显的。另外，根据组织的不同，这里每一项挑战对于软件平台影响的严重性可能有所差异。 　　1. 特性团队还是组件团队 　　在给定系统中，特性团队通常承担端到端职责，围绕特性（也就是所谓的故事）展开工作。另一方面，组件团队更侧重于交付一个子系统，这个子系统与其他子系统交互以发挥作用。敏捷方法重视向最终用户交付可直接感知的价值，因此更倾向于特性团队而非组件团队，但这并非完全否定组件团队存在的必要性。不过，实施者普遍感觉组件团队总是不那么被看好，从项目经理或技术领头人那里常听到下面的论调： “我听说，敏捷界都认为组件团队不好，因为它们做不到端到端负责。” 　　然而，就平台开发而言，有需要把二者结合起来。例如某些服务 —— 尤其后台服务重要且基本，开发成本昂贵，可能有必要安排专门的组件团队来进行维护，而不应交给具体项目中的特性团队去负责。 　　特性团队与组件团队的交叉合作很重要。有时需要组件团队来构建和维护特定核心服务——这些服务有可能会大范围影响产品，抑或需要特殊领域知识或专长。有时候需要另外一些与应用层有密切互动的组件团队来与特性团队更紧密地合作，以理解他们的需求。 　　为了交付应用级特性，特性团队通常承担着端到端的职责。在端到端的开发中，特性团队除了使用平台中的服务，偶尔还需要对平台做些修改以满足需要。修改有以下两种方式： 　　A. 直接修改核心平台代码： 　　应该允许特性团队填补平台的欠缺之处，视需要还允许新添一些组件。这是推荐的做法，但首先要满足以下两个前提： 特性团队对平台组件所作的任何修改和扩展，都必须经过主管该部分的平台团队的审核。这是为了确保改动技术上可靠，并且防止违反任何设计及结构上的规制和准则。如果代码有跨平台的要求，那么跨平台性也要纳入审核范围。 特性团队应该有权对平台组件进行回归测试，这样他们就可以在提交更改前在本地针就不同的配置环境生成产品。否则平台不稳定将造成用户认为平台不可靠。 　　B. 从核心平台代码创建分支 　　有些时候，特性团队所要求的改动，可能与使用平台的其他产品产生无法解决的冲突。举例来说，有个新产品需要平台提供某种行为，而现存组件与要求的行为仅有略微的差别。如果组织觉得同时支持新旧两种方式有价值，那么有必要让组件团队和特性团队展开合作，针对所有产品对组件的各方面要求，提炼出其中共通的部分，再充分发掘差异的部分。可以使用配置管理和可变更性管理的技巧[6]来支持这个步骤。 　　如果来自应用层的某个需求会导致平台的变更，最好从平台团队（也就是组件团队）抽调至少一名成员临时加入负责这个变更的特性团队。特性团队所作的决定要经过该名成员确认方能生效。这样的协作与确认会加快审核过程，这种参与还会促进组织内的知识流通，因为它提供了一个机会让特性团队里的开发者更好地理解领域知识并了解跨平台问题。在日常的Scrum会议中，每一位平台团队成员都应该汇报他们参与特性团队的讨论后的结论（例如所采取的决定、必要的变更）。 　　2. 团队自主管理： 　　还有一个问题可能会妨碍软件平台开发，这就是高度自主管理的团队。当一个高度自主管理的团队的成员呆在一起很长时间后，这个团队会有渐渐变成孤岛的危险。在组织内放任孤岛的出现会产生严重的后果，如代码冗余、可重用资产的低可见度、虚假的重用资产以及平台分裂等。有时内部的关于平台的决策发生冲突，导致出现平台不同分支，即萌生平台分