客座作者 Sarah Novotny是Nginx的技术推广人员和社区经理。

一个聪明人曾经说过,你在建造自己知道的东西,然后你知道自己在建造什么。尽管这些并不是计算机程序员梅尔文·康威(Melvin Conway)在1968年所说的确切话,但人们的情绪还是存在的。 

他的社会学观察被称为康韦定律,认为任何设计系统的组织都将不可避免地产生其结构是该组织通信结构副本的设计。

快进到2015年:许多组织都在盯着单一的应用程序和体系结构,并且想知道他们如何到达那里。而且,也许更重要的是,他们从这里去哪里?

我坚信,实际上很少有技术问题与技术有关。无论您是要从单一的,与供应商相关的模型中发展,还是准备采用微服务,现在都该看看您的内部文化,人员和系统如何影响应用程序开发速度和性能。

这里有五个想法可以帮助您入门。

在比萨饼订单上设置上限:创建小团队

许多组织陷入了陷阱,那就是团队中的人员越多越好。在2000年代初期,亚马逊的创始人兼首席执行官Jeff Bezos挑战团队提高工作效率,更好地沟通和更快地行动。他认为,一个团队的人数不能超过两个比萨饼,因此创建了现在称为“两个比萨饼团队法则”的规则。

这个想法是让小型而敏捷的团队通过强有力的协议(例如需求文档和API)协同工作。只要团队不违反将团队和代码绑定在一起的合同,就可以授权他们对代码段进行必要的更改。

微服务等技术是这一概念的扩展。在微服务模型中,复杂 应用领域 由小的,独立的 组件。这个 模块化的 开发方法减少了任何一项服务出现问题会导致整个应用程序无法满足最终用户或消费者(或更正式地说是服务级别协议(SLA))的可能性。 为失败而设计 可以带来更积极的客户体验,更好的开发人员体验以及内部团队,这些团队可以更自由,更快速地迁移。

识别并授权先驱者

即使将单个服务从整体应用程序中移出,也会带来重大的文化挑战。的确,尽管在整个组织中组建小型团队很重要,但从小做起。 

从一个开始 单一的创业团队 在您广泛学习之前。选择那些天生的领导者,他们具有与生俱来的好奇心和解决问题的能力,并且对缺乏明确性的容忍度很低。您希望员工不怕说:“目前尚不清楚我们将如何完成这项特定任务,但我会想出一种方法来解决。”

请记住,膏霜具有丰富经验的先驱者是理想的选择。您想要一个团队,其中包括在现有的整体架构中具有深厚背景的人员;有些人是从外面来的,有着新鲜的眼睛和视角;以及其他经验较少但有信心问“愚蠢”的问题,以了解发展为何朝着当前方向发展。但是请确保这是一支能够在没有个性冲突的情况下一起工作的团队!

加强使命

不仅要选择将在您的开拓团队中任职的人,而且还要与未被选中的人进行沟通时要小心。加强 所有 利益相关者认为,新团队是以下方面的典范: 大家 组织中的人员最终将构建,构思和交付软件。如果仅通过先驱的早期“现场报告”,就可以使整个组织参与到转型中来,这将有助于增加认可度,并鼓励透明性作为抵御新的和不同的竖井行为风险的武器。

不过请注意:这是团队将团队拖入公司传统业务的潜在危险所在。

建立高信任度的文化

同样,建立失败和分享的文化也很重要。在过渡到这种新模型时,并非一切都会顺利进行。您需要鼓励个人 从不可避免的不幸和挑战中学习,并将所学内容反馈到开发周期中。积极主动地建立一种内省的文化,在这种文化中,团队可以感到有能力承担风险和承认错误,而无需怪罪。

慢慢来

在组织中我经常看到一个陷阱,那就是低估了所需的社会变革的数量。毕竟,您不仅在更改代码,而且还在从上到下更改组织的工作方式。 

重大更改可能不适合您的组织。对于某些组织来说,快速进行多种文化和技术变革实在太多了;也许您只是没有足够的空间或容量或优先级的意识来立即进行此类更改。例如,如果在12个月的时间内将一个大型应用程序转换为100个小型应用程序是不切实际的,那么对您的组织来说,将代码和服务逐个细分成小组可能更好。


为了打破流程受限,形式化,自上而下的命令和控制(导致僵化,单一的应用程序)的周期,请从原始先驱者那里借鉴实践。回到砍木头和浇水的日子,以创造共同的旅程和成长感。玩得开心,信任您的人民,并记住康威的法律。旨在创建一个灵活,强大且自治的组织结构,并提供匹配的软件。