多团队协作及工程优化
随着业务发展，团队人员越来越多，不得不分成多个团队来工作（参考两张披萨原则）。多团队带来了团队协作的挑战，同时人员扩张也会带来团队文化被稀释，规范被破坏的风险。由于处于业务快速发展期，有些较大的需求可能无法在一个迭代内完成，所以迭代的时间盒也可能被突破。下面我们来讨论一下面临这些挑战需要注意的点和一些解决方案。
团队协作
- 团队划分：我们通常按业务领域来划分团队，一个团队负责的领域相对内聚，不同团队可以通过业务交互来划分接口进行对接。
- 接口联调：在确定跨团队的接口设计后，一定要约定谁对接口进行联调。首先大家都需要对自己所完成工作的质量负责，所以建议接口提供方完成接口后， 需要自己完成对接口的测试（推荐进行接口级的单元测试），其次对于业务场景来说，使用方会更加清楚，所以我们一般推荐使用方对接口进行联调。
- 关注公共领域：对于通用域、支撑域（按DDD的概念）的设计常常被忽略，可能做完后才发现大家做了同样的事情，但设计有差异难经合并，导致需要花费较大的精力来整合。因此团队必须要有人对整体的领域划分和技术架构负责（参考康威定律）。负责的可以是一个人（一般都是技术负责人），也可以是一个虚拟的小组。
开发规范和代码质量
所有的规划执行都是有成本的，所以我们建议每条开发规范的制定都要有充足的理由。我们可以参考行业一些好的实践，但我们引入时要清楚的知道每条规范的原因、成本，评估是否适合我们。当团队扩张时，规范的定制和执行会变成一项重要的工作，否则一段时间后，可能会发现系统很多都没有按原有的设计开发，变成一个难以收拾的烂摊子。
- 最好的规范是能够将其内置到构架和开发框架中，提高不按规范执行的成本，正常情况就不会违反规划（故意搞破坏的除外）。
- 其次是在开发流水线中使用工具来检查规范和代码质量是否符合要求，根据规则来进行卡点。
- 最后是制定规范文档，然后在CodeReview中进行检查。
跨迭代需求
对于超出迭代时间盒的需求，有的可以划分成多个部分，而且对当前迭代和线上的内容影响不大，比如全新的模块。有的可能影响较大，而且无法较好的切分，比如对原有模型的调整。
- 如果需求可以划分成多个部分进行测试和验证，我们可以在一个迭代内完成一部分验证后发布上线，这时候只有代码上去了，便并没有新的系统功能上线（可以通过隐藏入口、添加少量开关等方式）。这样做的好处一方面利于团队迭代规则，而且可以避免长生命的分支合并代码带来的麻烦和风险。
- 对于无法分多个阶段发布的需求，特别需要注意与迭代功能代码的关联处理，避免跨迭代需求上线时，需要解决大量的代码冲突，或者需要对已上线功能进行重新测试。因此在迭代规划时，需要对这部分进行更精细的设计，比如对于迭代和跨迭代需求都需要修改的部分，在开发迭代需求中就完成两部分的能力支持。
- 尽量不要在对一个模型进行调整的同时，同时在其上面迭代新功能。有时候我们不得不这么干，就得准备好新功能在模型调整后，需要在新模型上重新实现一遍。但这样会带来很高的成本和风险，如果一边调整模型，一直加新功能，可能新的调整迟迟无法上线，越久累积的风险越高。
多团队分支模型
多团队协作可能需要更复杂的分支模型来支撑并行的工作，这里我们不会给出具体的分支模型指导，一方面是因为网上已经有很多经典模型的讨论，另一方面是分支需要根据团队工作模型、基础设施情况进行自己的设计。
- 我们建议可以根据自己团队的规模匹配一个经典的分支模型，然后在实践过程中进行调整和优化，重要的是团队里要有人关注和研究分支模型对团队的影响。
- 分支模型的设计尽量简单明了，不要追求覆盖各种场景的“完美”设计，对于特殊情况可以采用变通的方式进行处理，避免复杂的分支设计对团队成员带来理解困难。通常来说理解困难都会带来持续不断的“人为错误”，特别是在团队扩张，新人较多的时候。
工作集成
需要注意的是多团队会带来团队工作的集成要求。如果在单团队开发时，我们就有较好的持续集成实践，这可能不是一个问题。如果之前单团队工作就有一个集成节点，那现在就变成了多团队工作集成了，因为集成的内容较多而且跨团队，所以这个集成可能非常耗时。以下是一些优化集成工作的建议：
- 尽量将质量左移到开发和联调阶段。可以通过加强前期设计、自测和联调来达到质量左移的效果，可以采用“工作完成定义”、单元测试、将自测联调加到迭代任务中、在测试用例中标注自测用例等方法来加强落地。
- 让拆解出来的功能可以自闭环，我们就可以在迭代过程中对提交的功能进行相对闭环的验证，这样能够大幅提升系统的质量并降低集成的工作量。因此我们建议遵循敏捷开发的指导，把需要拆解成能闭环的用户故事，团队按故事优先级，先完成高优先级的故事，然后提交验证。
- 将集成测试用例独立出来并自动化。在迭代过程中，团队更容易关注到变更对团队负责部分的影响，往往容易忽略关联影响。因此建议将集成测试用例独立出来，在集成时回归之前的集成测试用例。最好将这项工作自动化，如果团队暂时没有精力进行自动化，建议将迭代回归的评估和执行加到迭代常规工作项中。
优化可观测性
当系统功能规模和用户规模都在大幅增长时，需要更完善的可观测能力来提前发现系统的风险，快速定位系统问题。建议在常规日志和监控告警的基础上，引入Trace（带租户标识）、Metrics、Profiler等能力。
- 链路追踪：当前架构主要是单体模型，但一个请求会经过前端、负载均衡、网关、服务、中间件及数据库，整体复杂性不会像微服务那么高，但迭加分布式部署有多个负载服务器，出现问题时一段一段排查还是非常耗时的。所以很有必要建设链路追踪的能力。前期可能不需要那么完善，但整个链路能够串起来，后面优化会轻松很多。否则可能需要修改架构和框架，越晚成本越高。
- Metrics：可以针对网关流量、中间件、基础设施等进行度量并配置相关告警，可以提前发现风险，及时处置。
- Profiler：很多Profiler会对系统性能带来影响，所以建议采用开关的模式，当需要时打开开关进行数据抓取，关闭后生成报告。对于某些语言可能需要在开地框架中提前内置相关能力。
