大规模软件研发的困难和应对之策

Mary Poppendieck 在 Agile Adria 2015 年会上做了关于大规模团队敏捷开发难题的主题演讲。使多个团队一起工作是很有挑战性，然而大型复杂产品的团队协同研发需求又总是存在的。Poppendieck 在演讲中，为需要大规模敏捷开发的组织提出了一些想法。

在 InfoQ 的采访中，Mary & Tom Poppendieck 谈到敏捷团队如何在协作和自主之间做平衡，如何通过不断实验来解决复杂问题，做研发时保持做产品的心态为什么优于做项目的心态，以及怎样做才能确保对业务影响的关注。

InfoQ:你的演讲中包含了大规模研发团队试图解决的四方面问题: 合作、复杂性、心态和关注点。你提到团队正在寻找平衡协作和自主权的方法。请您详细阐述一下大规模研发如此困难的原因何在?

Mary & Tom Poppendieck: 在 2009 年出版的《驱动力》一书中，作者 Daniel Pink 强调了三件能够激励人们的事情：自治、掌控和目的。敏捷开发的团队把“自治”按字面意思理解为“不受外界的控制和影响或称独立”。有趣的是，尽管存在一些的偏见（如团队思维往往会抑制团队个体的自主权），但敏捷开发通常只会让小团队拥有自治权，而并不会让团队的个体自治。

许多地方的人们都认为，小的跨职能的开发团队应该相互间完全独立, 却很少关注其实这些团队是一个更大的整体的一部分，只有大团队的成功才能带来小团队的成功。这种对于小型团队自主性的关注常常演变为一种掌控，所以当要求小团队通过相互合作而实现更大目标时, 他们常常觉得自主权受到了侵害。

事实上，为了合作，团队及成员之间应当相互包容——他们必须放弃对自己目标的过分关注，取而代之的是一个更大的共同目标。当团队可以独立负责一段代码，例如微服务时，此时并不需要彼此包容。但在许多领域，模块和组件的开发需要一个更大的团队，而这些人必须一起协同工作——或是以一组小团队的方式协同合作——那么自治权在此时适用于更大的组织。

大规模协作的团队肯定不是一个新想法——事实上，人类历史上早已经有了 30 至 50 人规模的团队。生物进化学家称这种规模的团体为“狩猎团体”——为达成更大的目标这个团体必须具备一定的人数, 比如通过狩猎大型猎物来养活一个村庄。诺贝尔奖得主 Eleanor Ostrom 已经搜集了许多大团体高效合作利用自然资源的事例，如林业、牧业、灌溉、以及渔产养殖业。

不幸的是, 一些敏捷开发的 7 人左右小团队有时过于捍卫自主权, 他们往往缺乏实际可行的办法去容纳其他团队的需要，最终很难形成一个整体去完成更高层次的目标。所以，我们需要使小团队重新平衡，自治需让步于合作，从而使整个团队向着一个共同的目标前进。

InfoQ:请举例说明 30 到 150 人的较大规模的团队是如何有效合作的？

Mary & Tom Poppendieck:一个新的产品推出上市并获得成功往往需要超过 7 个人的团队。不管它是保险产品还是智能手机应用, 你会发现产品要想成功，从设计、营销、工程、发布、售后支持、财务到许多相关领域的洞察力都是不可或缺的。回首看看最近遇到的一些伟大的产品, 你可能会发现他们的团队都会多达 30 到 50 人。

我们曾经（错误地) 认为产品交付团队应当是一个自治团队——事实并不是这样——它更像一个大团队中的一个小组。将软件研发团队拆散，形成开发目标独立明确的“自治”小团队，这种做法限制了小团队对于整个产品的贡献。我相信伟大的产品之所以有好的迭代进化，是由于工程师团队参与了整个产品设计过程中的宏观讨论，包括产品应当具备哪些功能，应该运用哪些技术, 如何将产品提供给市场, 需要什么样的支持, 什么样的升级路径会取得最好的效果，等等。

在 Gore and Associates 公司，150 人规模的团队是很常见的, 这些团队能够完全涵盖整条业务线，同时团队成员的生计又依赖于这项业务的成功与否。Pixar 公司的团队有 200 人左右，并肩工作了三年时间，开发了一个又一个动画大片，他们关注如何帮助同伴（经常是不同业务线的）实现最好的作品。

InfoQ:你曾经提出用“试探法”去解决团队扩展的复杂性问题。你能描述一下如何以及为什么这样做么?

Mary & Tom Poppendieck:复杂自适应系统理论对于思考如何研发大规模软件是有意义的——尤其是当软件的产品、市场和业务交织在一起的时候。整个软件密集型业务系统显然是一个复杂的系统。我们从复杂自适应系统理论中能够学到很多，其中一点是，那些取得成功的领先系统总是能够根据实际情况在自组织（agency) 模式和相互依存（connectedness）模式间取得平衡。

长期生存且不断成长的复杂系统都是自适应的，并且这种自适应以一种特定的方式发生。通过源源不断的小实验——其中不乏一些失败的——使得系统的负责人能够逐渐发现好的做法。即便整个复杂系统的响应是有章可循的，仍有必要进行小实验, 一些微小输入条件的变化（比方说，一只蝴蝶拍打翅膀) 都可能会导致系统响应的巨大变化。

对复杂系统的大的变更肯定会产生影响, 但预测产生怎样的影响则几乎是不可能的, 因为没有人或团队可以完全理解交织错综的依赖关系。因此，那些看重可预测性和安全性的人应该明白, 实现稳定的唯一途径是尝试小的事物, 观察结果, 并且使系统调整适应从而解决问题。那种认为当今系统仍然是可预测的，应该进行大的精心策划的想法，早已被证明只是人们的一厢情愿。我们需要明白，就像是在战争中或是复杂的系统中, 做计划的过程是有用的, 但计划本身却是无用的。

InfoQ:你能否解释与保持做项目的心态相比，以一种做产品的心态去研发更能取得好的成果？

Mary & Tom Poppendieck:项目的问题是人们首先需要埋头应付项目中批量的工作，其次项目的目标是遵循计划。在精益软件开发世界中, 我们已经认识到, 小批量部署的代码能够显著提高代码质量，同时大大增加流动效率（因此整体效率也得以提高)。

项目中所谓的“交付团队”期望执行一个精心设计的计划，并且会考核实际执行情况与计划的偏差。但这样的做法要求计划——往往是在项目初期可用信息最少的时候制定的——在整个项目后续的执行中始终保持正确有效。这种做法认为不需要了解项目实际情况并加以适应。虽然一些大型项目允许分阶段滚动改变未来部分的项目计划，但从根本上项目还是基于这样一种理念: 计划是有价值的，并且应当严格遵循。这种假设在不确定的环境中本身就是有缺陷的。

产品面对的是一个不确定的世界——经费不确定、竞争不确定、业务影响不确定。产品被不同的、多样化的团队（包括设计、产品管理、市场营销、工程、支持和运营等团队）构思、尝试和实践。当这些不同技能领域的特长专家共同理解市场、消费者、技术现状以及未来的各种可能性时, 伟大的产品就此出现。事实上，当今市场上，几乎所有伟大的产品都离不开不断地实验过程。

Marty Cagan (来自硅谷产品集团) 表明, 所有好的软件密集型产品中，超过一半的创意来自工程团队，因为这些人明白技术的力量和未来的方向。这意味着当工程团队将重点放在项目交付上，如果只是循规蹈矩完成“业务”要求的需求, 那么大多数潜在的好想法将永远不会变成产品。

InfoQ:你谈到当使用大规模敏捷的时候要关注业务的影响，你能举例说明这点么？

Mary & Tom Poppendieck: 我想改述你的问题——为什么会有人想度量“敏捷”? 如果做得正确，精益 (和敏捷) 是一种心态，这种东西你无法衡量和评测。你可以度量——并测量——的是，通过引入敏捷和精益的原则所带来的积极的业务影响。所以让我们来谈谈为什么以及如何关注业务影响。

聪明、富有创造力的工程师们会在自己的工作中找出有意义的目标。如果他们受制于组织现状，自己对产品的积极改进无法让用户受益，那他们将会另外寻找工作的意义，或是通过历练自己的技术达成美化简历的目标, 或是以追求个人或团队愿景为目标。但是工程师也是人, 与能够通过对技术的掌控而有效解决他人重大问题相比，这种靠程序员内在驱动产生的目标所带来的激励要差很多。以一种对业务有持续积极影响的方式，解决自己所关心的人的重大难题, 这种工作目标才会有最好的激励效果。

这是怎么做到的呢? 最应当关注的是设计师、产品经理、工程师之间的反馈回路是否达到了预期的效果？好的做法是三者都在一起工作，从他们决定尝试一些事情，到他们收到反馈（按照最佳实践应从真实客户处得到反馈）。这个反馈回路是按小时计? 按天? 按周? 按月? 还是根本没有回路？ 设计师 Bent Victor 有一条指导原则: 创造者需要与他们创造的东西有紧密的联系。我们有一个类似的指导原则: 团队应该基于他们从工作中获得的经验而做出调整。缩短反馈回路。

查看英文原文： Scaling Dilemmas and How to Deal with Them

感谢丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。