NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

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

  • 2015-05-20
  • 本文字数:3535 字

    阅读完需:约 12 分钟

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 读者交流群)。

2015-05-20 08:582511

评论

发布
暂无评论
发现更多内容

Zebec官方辟谣“我们与Protradex没有任何关系”

西柚子

K8S发布应用步骤详解

tiandizhiguai

云原生 k8s

【深度挖掘RocketMQ底层源码】「底层源码挖掘系列」透彻剖析贯穿RocketMQ的消费者端的运行调度的流程(Pull模式)

洛神灬殇

RocketMQ 消费原理 运行机制 源码实现

科技“新贵”ChatGPT缘何“昙花一现”,仅低代码风靡至今

这我可不懂

低代码 ChatGPT

大数据时代下的企业网络安全

镭速

一款互联网SaaS产品都包含哪些内容

Y

乌托邦UTO系统开发NFT技术

薇電13242772558

NFT

数字山河一盘棋:2023新华三如何发力商业市场?

脑极体

新华三

Zebec生态持续深度布局,ZBC通证月内翻倍或只是开始

西柚子

架构实战营模块1作业

大势前瞻!文旅还是短视频,你弯道超车风口在这了

引迈信息

创业 投资 短视频 旅游 创业项目风口

数据隔离方案

Y

2023年Web安全最详细学习路线指南,从入门到入职(含书籍、工具包)【建议收藏】

网络安全学海

黑客 网络安全 信息安全 渗透测试 WEB安全

软件测试/测试开发 | 黑盒测试方法论—因果图

测试人

软件测试 自动化测试 测试开发 测试用例 测试方法

白鲸开源发布迁移工具 Airphin 并开源,2 步迁移 Airflow 至 Dolphinscheduler

Apache DolphinScheduler

Apache 开源 Apache DolphinScheduler airflow Airphin

Zebec官方辟谣“我们与Protradex没有任何关系”

股市老人

Zebec官方辟谣“我们与Protradex没有任何关系”

EOSdreamer111

2023-02-22:请用go语言调用ffmpeg,保存mp4文件的视频帧,每帧用ppm图片保存。

福大大架构师每日一题

golang ffmpeg 福大大

关于云原生,我问了ChatGPT几个问题......

拓维信息

DevOps 云原生 ChatGPT

2023 版最新大数据面试宝典

五分钟学大数据

大数据 大数据面试

阿凡达(Avata)泰山众筹系统开发部署技术

薇電13242772558

智能合约 dapp

netstat与ss

飞翔

模块七作业

张贺

架构训练营

数据服务门槛再提升,这个“TOP1玩家”凭何再度领军?

澳鹏Appen

人工智能 自动驾驶 智能驾驶 数据标注

10 个值得掌握的 reduce 技巧

devpoint

JavaScript reduce 数组方法

【深度挖掘 RocketMQ底层源码】「底层源码挖掘系列」抽丝剥茧贯穿RocketMQ的消费者端的运行核心的流程(Pull模式-下)

洛神灬殇

RocketMQ 消息队列 源码解析 原理解析

好用的录屏工具值得免费拥有

穿过生命散发芬芳

录屏工具

做好产业数字化助手,腾讯云助力贝壳实现降本增效与业务创新

科技热闻

MAR:针对动作识别的视频掩码建模

Zilliz

新耀东方-2023第二届上海网络安全博览会暨高峰论坛 SCSF-SHANGHAI CYBER SECURITY FAIR AND SUMMIT FORUM 2023

Anthony

网络安全 信息安全 大数据 开源

软件测试/测试开发 | 黑盒测试方法论—场景法

测试人

软件测试 自动化测试 测试开发 测试用例 测试方法

大规模软件研发的困难和应对之策_文化 & 方法_Ben Linders_InfoQ精选文章