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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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