引子
过去十年间，敏捷软件开发赢得了大好发展局面，被众多不同规模组织采用[1]。敏捷方法宣扬一整套价值观，并且提出了一系列实践活动去帮助获得并维护这些价值。尽管从一开始，敏捷方法常以提升作为工作单元的小团队的效率为中心，但最近有趋势将敏捷方法拓展到企业层面[3]。然而，在企业层面会产生新的问题，可能需要重新考虑敏捷软件开发的某些价值观与实践活动。构建软件平台来实现企业范围重用策略，是主要问题之一。在本文中，我列举了五项首要挑战，敏捷组织在决心采取软件平台战略时应该准备面对它们。
软件平台是什么？
软件平台是由一组子系统和接口构成的一个通用基础架构，支撑相关产品在其上开发[4]。可以把软件平台看作实现组织层面重用的一个战略手段。很多组织曾表明，应用软件重用能带来很多好处，如：减少开发和测试工作从而更快交付产品、开发和维护成本更低、重用部件具备更高品质、重用被证明过的解决方案风险更低、更容易估算项目的时间与成本。
五项首要挑战
采用软件平台策略是一个根本性的改变，需要组织重新审视并调整已有的做法。单就敏捷而言，如果不不加考虑地沿用某些敏捷原则和实践，反而会制造新的挑战。在本文中，我们会集中讨论五个主要问题，即：特性团队、团队自主管理、业务价值、代码所有权以及稳定性。虽然这里列出的可能不是全部，但它们应该是最明显的。另外，根据组织的不同，这里每一项挑战对于软件平台影响的严重性可能有所差异。
1.特性团队还是组件团队
在给定系统中，特性团队通常承担端到端职责，围绕特性（也就是所谓的故事）展开工作。另一方面，组件团队更侧重于交付一个子系统，这个子系统与其他子系统交互以发挥作用。敏捷方法重视向最终用户交付可直接感知的价值，因此更倾向于特性团队而非组件团队，但这并非完全否定组件团队存在的必要性。不过,实施者普遍感觉组件团队总是不那么被看好，从项目经理或技术领头人那里常听到下面的论调：
“我听说，敏捷界都认为组件团队不好，因为它们做不到端到端负责。”
然而，就平台开发而言，有需要把二者结合起来。例如某些服务——尤其后台服务重要且基本，开发成本昂贵，可能有必要安排专门的组件团队来进行维护，而不应交给具体项目中的特性团队去负责。
特性团队与组件团队的交叉合作很重要。有时需要组件团队来构建和维护特定核心服务——这些服务有可能会大范围影响产品，抑或需要特殊领域知识或专长。有时候需要另外一些与应用层有密切互动的组件团队来与特性团队更紧密地合作，以理解他们的需求。
为了交付应用级特性，特性团队通常承担着端到端的职责。在端到端的开发中，特性团队除了使用平台中的服务，偶尔还需要对平台做些修改以满足需要。修改有以下两种方式：
A. 直接修改核心平台代码：
应该允许特性团队填补平台的欠缺之处，视需要还允许新添一些组件。这是推荐的做法，但首先要满足以下两个前提：
特性团队对平台组件所作的任何修改和扩展，都必须经过主管该部分的平台团队的审核。这是为了确保改动技术上可靠，并且防止违反任何设计及结构上的规制和准则。如果代码有跨平台的要求，那么跨平台性也要纳入审核范围。
特性团队应该有权对平台组件进行回归测试，这样他们就可以在提交更改前在本地针就不同的配置环境生成产品。否则平台不稳定将造成用户认为平台不可靠。
B.从核心平台代码创建分支
有些时候，特性团队所要求的改动，可能与使用平台的其他产品产生无法解决的冲突。举例来说，有个新产品需要平台提供某种行为，而现存组件与要求的行为仅有略微的差别。如果组织觉得同时支持新旧两种方式有价值，那么有必要让组件团队和特性团队展开合作，针对所有产品对组件的各方面要求，提炼出其中共通的部分，再充分发掘差异的部分。可以使用配置管理和可变更性管理的技巧[6]来支持这个步骤。
如果来自应用层的某个需求会导致平台的变更，最好从平台团队（也就是组件团队）抽调至少一名成员临时加入负责这个变更的特性团队。特性团队所作的决定要经过该名成员确认方能生效。这样的协作与确认会加快审核过程，这种参与还会促进组织内的知识流通，因为它提供了一个机会让特性团队里的开发者更好地理解领域知识并了解跨平台问题。在日常的Scrum会议中，每一位平台团队成员都应该汇报他们参与特性团队的讨论后的结论（例如所采取的决定、必要的变更）。
2.团队自主管理：
还有一个问题可能会妨碍软件平台开发，这就是高度自主管理的团队。当一个高度自主管理的团队的成员呆在一起很长时间后，这个团队会有渐渐变成孤岛的危险。在组织内放任孤岛的出现会产生严重的后果，如代码冗余、可重用资产的低可见度、虚假的重用资产以及平台分裂等。有时内部的关于平台的决策发生冲突，导致出现平台不同分支，即萌生平台分裂的情况。再过一段时间后，分支间的差异会巨大到使平台只能应用于某个特定操作系统或产品，甚至于失去共通的基础模型。
再者，高自主性造成团队将特定问题作为团队的内部问题去考虑，忽视自身的决策对平台以及平台上其他特性团队的影响。而当团队和业务单元具备联邦主义（Federalism，一种治理关系，常见于较大的敏捷组织）特色时，会给平台相关的决策造成更大的挑战。例如，有时需要就平台重用与否做决定，是重用现存的平台，还是换个方向，如单独为当前业务目标构建一个独立的变体。一方面，公司作为软件的拥有者，有经济上的理由推行重用，但在公司层面常常难以兼顾具体业务事项错综复杂的全部细节，因而下这样一个决定就很有挑战性。另一方面，如果做决定的权力被赋予直接受重用问题影响的团队和业务单元，有很多因素都可能把决策过程导向错误的方向。试举一例：单个团队倾向于选择看得到短期利益的方向，而非从长远目标来考虑（如维持平台的生命力）。况且还有“非我发明（Not-Invented-Here）”综合症，会让团队排斥重用别人开发的组件，偏好自己另起炉灶。
3.业务价值意识：
在敏捷组织中很强调贡献业务价值，这早已被证明为敏捷软件开发的重大的优势。不过如果对于什么是业务价值理解得不成熟，这种理解的广泛性反而会成为障碍。障碍并非来自以业务价值为导向的思维本身，而是来自围绕着这种思维产生的误解。比方说，“只有客户看得见的才有价值”这样的观念就很有害，尤其是在软件平台的问题上。下面的论调不算少见：
“我认为所谓价值就是提供给客户的有用而且能用的功能”[2]
可是业务价值并不总是立竿见影，也不一定直接对客户发生影响。重构即为一例。
转换到平台战略会带给组织很多经济上的好处，但从最终客户的角度来说没有变化。在严格根据对当前客户的影响来衡量业务价值的环境里，很难去激励团队和个人去接受平台模式。与能够和客户进行第一手交流的特性团队相比，可能会错误的认为专注开发并且持续完善核心服务的团队贡献的价值较小。因此要对业务价值有更深刻的理解，方能将面向客户与面向业务两方面的价值兼收并蓄。不要只是问：“这个对客户有什么好处？”，我们还应该问：“这个对业务有什么好处？”。第二个问题根本上源自第一个问题，毕竟任何业务的成功都依赖于它能否满足当前客户并吸引新的客户。但是重要的是要明确这个区别才能纠正认识上的偏差。
4.对代码和产品所有权意识：
团队和产品所有者往往很注意保护他们的资产和产品，让转换到平台战略更加困难。这主要是因为拥有组件的团队宁愿把这个组件抓在手里，而不愿在平台里维护一个共享的组件。而且在平台语境下，代码所有权不像在条块分割的开发方式下那样明确和清晰，平台里被多个团队和产品共享的组件，说不清该由谁拥有。
克服这个问题的方法是宣传平台以及其上的产品归集体所有的思想。这可能需要一个内部的开源模式，可以让特性团队为平台作出贡献并对他们贡献的代码临时承担起责任和获得所有权，直到它足够成熟、健壮后再把责任移交给组件团队。而对产品所有者来说，需要一种更加讲求协作的做法来决定如何把需求传递给他们的团队，既要考虑客户的短期要求还要考虑维持平台的长期需要。
5.敏捷性与稳定性的矛盾：
在构建平台的传统模式里，先平台后产品的思想占据统治地位。可以在一些软件开发范式中发现这个思路，例如“软件生产线工程（software
product line engineering）”强调开发领域部件而后才是应用部件[5]。这样的先后顺序意味着，在产品下层的平台的开发取得实际的进展之后，组织才会开始构建产品。可在敏捷型的组织里，在软件平台开发上更倾向于采用一种产品驱动的方式。按照这样的做法，平台除了衍生自从现成的产品，也可以从正在进行的项目的需求中产生，在这些项目里，开发中的产品作为平台的第一批用户，与被依赖的平台同时开发。
特别在产品驱动开发平台的情况下，要在平台的稳定性与保持变化的灵活性之间取得平衡很具有挑战性。虽然在敏捷环境下团队必须保证对手头产品积极应对以满足当前客户，但也必须认识到平台稳定性非常地关键，因为很多产品依赖这个平台作为共同基础，所以应该值得信赖，不应该变化得过于频繁。对基础架构组件和核心服务而言，被放到一个正在进行的项目中去面对不断变化的需求可能会带来很大的风险。
当产品所有者要求对平台进行修改时，如果牵涉到象可用性（usability）这样横向贯穿性的方面，会出现一个两难选择。第一个选项是遵循敏捷原则批准这个变更请求以满足手头的客户，于是所有依赖于变化的这部分平台的产品都会受到影响从而导致不稳定。另一个选项是不理这个请求，在有证据表明这也是其他产品的共通问题时再加以处理，但要付出引起客户不满的代价。
要破解稳定性与敏捷性的矛盾首先要能够识别每个需求的实际的业务价值。关键的是要权衡面向业务的价值和面向客户的价值，以此决定应该马上回应该请求，还是在证明其是普遍需要前搁置它，还是为了业务目标而完全忽视它。
结论
把敏捷方式拓展到到企业范围会产生一些后果，我们需要理解并加以应对。通过软件平台来推进重用是一个企业关心的问题，需要调整敏捷方法和实践以支持业务战略和目标的需要。我们要应对的五个主要挑战包括：找到一种混合的团队组织方式能够支持组件开发和特性开发、避免条块分割的思考方式以及团队联邦主义、重新审视业务价值的定义以囊括那些可能不直接关系用户的方面、构建一个更加整体的、协作的代码与产品所有权模式，最后是基于对需求的业务价值的理解在敏捷性与稳定性之间找到平衡。
| 
