“大团队”和“敏捷开发”，谁说不可兼得？
极客时间编辑部
讲述：杜力大小：1.84M时长：04:01
当小团队的产出跟不上业务需求时，团队就面临规模化的问题。从 1 个团队到 3 个团队，仍可以通过简单的团队沟通保持高效协作。而当产品复杂到需要 5 个以上团队同时开发时，就需要一定的组织设计来保证团队间的顺畅协作，以保证多团队共同开发一个产品时仍能保持敏捷性。这时候的组织该怎样设计呢？阿里巴巴敏捷教练张迎辉认为，可以设计两种组织形态，具体如下。
第一种，业务单元特性团队
即便小团队努力保持专而精，并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。
比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。在人员方面，各业务单元有独立的业务、产品和研发团队。在技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。
举个例子，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。比如微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。
技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造，一些必要的初始化操作放在 common 容器中，各业务在自己的 bundle 中。各业务 bundle 按需加载，只能依赖底层的 common 架构，不能相互依赖。这样各业务 bundle 可以并行开发，互不干扰。
按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，并通过不断试错找到业务发展的方向。
第二种，无限制特性团队
有时团队随着业务的发展壮大了，但经过一段高速发展，原有的业务方向遇到了瓶颈，新的业务方向还在摸索中，并不明朗，此时，难以按照明确的业务单元组建团队，而团队也需要适应业务方向的变化，所以就要鼓励团队广度学习，避免局部优化。
无限制特性团队没有相对独立的业务领域，多个特性团队共享一份产品代办列表（Product Backlog），按照统一的优先级交付产品功能。当然，每个团队都可以有自己的特色和专长，只要多个团队组合起来能够按照产品代办列表的优先级交付即可。
此外，无论是业务单元特性团队，还是无限制特性团队，每个团队都要具备独立交付产品特性的能力。一个复杂的产品特性，通常都需要修改多个模块才能实现。那么，多个团队修改同一个模块时，如何保证模块设计的一致性，并及时清理代码，偿还技术债？
引入模块守护者通常是个有益的实践，每个模块最好有两位模块守护者互相 backup，修改模块代码时需要请模块守护者做 code review，一些复杂的修改最好预先进行设计评审。
综上，在业务方向明确的情况下，按照业务单元组建特性团队是最理想的选择。在业务方向不明朗的情况下，可以先组建无限制特性团队，再逐步过渡到业务单元特性团队。当然，无论采用哪种组织设计，目的都是快速跑通业务闭环，持续地交付业务价值，并在真正的市场环境中检验假设，通过快速试错找到在一定的利润水平上为企业或终端用户提供产品和服务的可行方法。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
加菲猫与微服务开发方式有些类似1
收起评论