聊聊外包和远程项目的敏捷管理（合辑共7篇）

这是鼎叔的第五十一篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

第四个合辑完工了，咱们介绍了外包管理或远程项目如何敏捷交付，满足管理层预期。

外包项目主要分为项目外包，计件外包和人力外包，它能给公司带来运营成本下降，补充重要技能，缩短获取市场的时间等多个好处，但是带来的严重问题也很多，比如技能有限，人员流失快，效率较低，管理事故等等。本合辑从外包项目和团队的建立过程和管理机制开始简单介绍，然后重点分享了提升测试管理效能的实践经验，如关键角色和对接模式，技能类型分工，外包管理系统及度量，风险把控等知识。

最后，针对ODC建设与远程管理，本章给出了组织及能力层面的敏捷改善心得和真实范例，这些也适用于多地联合研发的敏捷管理。

之前三个合辑可以看这里：聊聊提升用户体验的评测方案（合辑共8篇），聊聊团队能力培养与创新氛围（合辑共17篇），聊聊探索式测试理论与实践（合辑共9篇）

1 聊聊多地点团队的敏捷研发

随着全球化和信息技术的发展，以及疫情的助推，多地点“分布式研发”成为新常态，给项目管理者带来很大的新挑战。即使团队分布在多个不同的地点，各种经典敏捷实践活动都是适用的。

2 聊聊远程项目交付的敏捷管理

对于日益重要的国际化市场，越来越多的离岸项目（内包或外包）在进行中，即需求方/客户在A地，开发团队在B地甚至海外。这种情形下，常见的敏捷实践活动也都是适用的。敏捷和精益关注的是价值观和原则。价值观也是文化的一部分，因此需要和离岸团队交谈并学习如何共同工作才能建立。本文内容也适用于任何远程项目的敏捷管理。

对于远程项目，关键的不足在于缺少致力于理解和应用敏捷价值观的利益相关方（即客户和管理层），因此，我们要教导真正客户和真正开发者之间通过反馈循环进行紧密而持续的协作。所有利益相关方的思维模式和行为要为了敏捷而改变。

3 聊聊CMM/CMMI认证的反敏捷

对于传统软件行业的QA（过程改进）和PM人员，CMM/CMMI知识是基本要求，但是在推行敏捷的组织中，CMM/CMMI并不被接受，甚至和敏捷转型理念背道而驰。CMM/CMMI如果作为一个过程改进的知识框架，本身并不会和敏捷研发产生冲突，但这篇文章我们会关注CMM/CMMI行业认证中的反敏捷之处。QA人员也可以对比思考，如何在组织中选取更符合敏捷价值观的实践方案。

4 聊聊技术外包的价值和团队组建

测试团队通常是企业外包实践的主力部门，基于鼎叔多年的实践经验，本篇会展开聊聊，外包的分类和价值，如何选择合适的外包敏捷管理模式，以及如何组建外包团队。提高敏捷交付效率，满足商业目标。内容也适用于其他岗位的外包团队。

测试工作繁重，在业务快速发展的同时，把部分测试任务外包出去，既可以降低管理成本和快速扩张的风险，又可以快速承接任务，同时让核心成员专注做更有价值的工作。

5 聊聊技术外包的风险与定位

外包团队的建设和管理虽然看着比较简单，但是实际运作时还是会感觉效率不高，经常出现一些意外问题，甚至让投资外包的公司管理层不甚满意。

而内部员工和外包，各自做哪些测试类型的分工是最合适的，有利于各自长期发展？

6 聊聊外包团队的高效管理机制

对于大规模的外包团队，需要一个易用的外包管理OA系统，才能提高日常交付效率。同时，我们也在探索哪一种外包交付的对接模式运作更为高效。

7 聊聊远程技术中心的高效建设（真实案例）

随着外包团队规模的扩大，以及安全和效率管控的需求，越来越多的外包项目采用ODC场地办公模式（Offshore Development Center），国内的外包行业把甲方公司以外建设的技术中心统称为ODC，而跨国企业通常把ODC定义为跨国的离岸技术中心。本文引用国内的ODC概念，泛指远程技术中心。

在上节介绍的外包高效管理经验之上，我们进一步阐述如何让ODC远程管理更加完善。

总结：针对远程团队外包交付，或者多地联合研发的项目，敏捷测试理念和实践方法都是适用的，下面是给这类项目团队的提效建议汇总。

1）如无必要，尽可能减少研发的地点数量，据行业数据统计，多地联合研发项目的平均效能是单地点研发的一半。

2）迭代规划一定是围绕产品的增量交付，而不能为每个联合开发的地点单独安排迭代。这时本书介绍的持续测试和验收测试驱动开发等实践就能发挥关键作用。所有团队聚焦在最高优先级的待办条目上，这样的投入产出效率是最高的。

3）每个地点的研发团队最好都是一个或多个相对独立的特性团队，分而不散，尽量减少彼此的交付依赖。

4）尽可能不要按职能来安排各地点的研发分工，比如把测试团队安排在地点A，把开发团队安排在其他地点；也不要把公共基础组件放在单独的地点。这种安排会让团队直接的沟通协作变得极为错综复杂，如果团队隔着多个时区，更会陷入低效的噩梦状态。各个团队尝试和其他地点的专家结对学习和远程视频技术评审，逐步掌握原先不熟悉的测试工具和能力，真正具备独立工作的交付水平。

5）当团队不得不分散时，每个地点配备好加强彼此沟通的设备，流畅的网络，在多个会议室布置便宜易用的视频设备和软件，所有团队在共享Wiki上记录和更新有争议的内容。尝试着在初期让所有团队飞到一个地点一起工作几个迭代，建立真正的信任关系。在迭代的回顾会议上可以增加不同层次的回顾内容，比如按地域进行回顾：针对某地团队的工作环境和资源情况回顾。

6）多地点团队交流时，可以通过共享的词汇来创造共通的团队文化。尝试在大项项目开始前组织一场“产品愿景研讨会”，绘制共同的业务领域视图，一同认知产品未来的发展蓝图和重大特性。

7）不建议盲目购买昂贵的商业敏捷工具用于多地联合研发，尽可能挑选简单的免费协作软件。商业工具可能会拖慢多地研发，因为要频繁申请预算，购买许可和远程认证，不利于团队发展的频繁需求定制和本地化部署。

8）把远程的用户卷入到研发之中，让他和工程师及产品经理可以直接建立联系，清晰地知道我们敏捷研发运作的机制。可以邀请客户参与迭代重要会议和验收测试，增加他对远程项目的信心。

9）多地研发团队建立健康平等的合作关系，切记不要“某地负责管理，其他团队负责远程开发”。如果是跨国团队协作，开多地会议时不要总是安排某个团队不方便的时候，关注彼此的公共假期。尽可能把一整套以客户为中心的完整特性让一个单地域团队承担，但是接近客户的其他团队可以帮助其进行详细的需求分析。

10）鼓励远程外包团队说不，当团队发生问题时，甲方应过去拜访合作伙伴，实地寻找根本原因，而不是依赖所谓的“质量规范”粗暴要求其整改。