组织架构适配下的敏捷开发

摘要： 本文将会讨论如何协调公司内各个工程师团队之间的合做，从而高效地保持系统的弹性和灵活性，以知足敏捷开发的需求。本文选自《Node.js微服务》。

　　若是一个公司采用微服务来构建软件系统，那么每一个干系人都须要参与决策。
　　微服务是一次重大的范式转换。一般，大型组织倾向于使用至关传统的方式来构建软件系统。每一个重大发布须要经历数月的研发周期，以后须要一个完备的质量保证阶段以及数小时的部署阶段。
　　当一个公司选择使用面向微服务的架构时，方法论就会发生彻底的改变：每一个小团队负责各自的小功能点，包括它们的构建、测试和部署。每一个团队各司其职，而且可以处理好各自负责的单一事项（一个微服务，或更确切地说是数个微服务），每一个团队成员将熟练掌握构建软件系统的相关技术与领域知识。
　　这一般被称为跨职能团队。这是一个由少数人组成的工做单元，他们都具有了构建高质量软件组件的能力。
　　有一点值得注意的是，团队成员应当掌握必要的领域知识来理解业务需求。
　　在个人职业生涯中，大多数致使公司失败的主要问题不外乎如下这点（就我我的观点而言）。首先，有一种观点认为开发者是“堆砖器”，便可以在没有提早沟通的状况下却依然能神奇地理解业务流。并且，还有观点认为，若是一个开发者一周能够完成X 量级的工做，那么10 个开发者一周就能够交付10X 量级的产量。这些观点都是错误的。
　　为了保持高效以及考虑到康威定律在改变业务流程方面对系统的影响，构建微服务的跨职能团队中的成员必须熟练掌握（不只仅是了解）相关领域知识。
　　每当谈及微服务的组织架构适配时，自治才是关键因素。为了保证构建微服务的敏捷性，每一个团队都必须保持自治，这也意味着要确保技术的自主选择权，以下所示：

• 使用的语言。
• 代码规范。
• 解决问题的模式。
• 各种工具的选择，好比软件的构建、测试、调试及部署工具。

这是很是重要的部分，由于这是咱们须要定义公司如何构建软件，而且可能会引入工程问题的部分。
　　举个例子，咱们来看看代码规范问题，以下所示：

• 咱们须要在全部团队内都保持统一的代码规范吗？
• 咱们应该让每一个团队都有各自的代码规范吗？

通常来讲，我偏好于“80%准则”：80%的完美度已经足以涵盖100%的使用场景。这意味着放宽代码规范（也适用于其余领域），以及容许必定程度的不完美或者个性化，都有助于减小团队间的摩擦，也能让工程师可以尽快关注到那些极少数的重要准则，好比日志策略以及异常处理。
　　若是你的代码规范过于复杂，那么在某个团队想要向其余团队的微服务提交代码时就会遇到不少阻力（切记，一个团队拥有本身的服务，可是其余团队的成员也能够对这个服务作出贡献）。
　　本文选自《Node.js微服务》，点此连接可在博文视点官网查看此书。
　　　　　　　　　　　　　　　　　　　　　

　　想及时得到更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。