Это позволяет группам, выделенным для преобразований, быстро выполнять итерации и проводить эксперименты для повышения производительности. Мы также убедились, что сможем выделить достаточное количество времени для улучшения, исправления известных проблем и ограничений архитектуры, в том числе и на нефункциональные требования. Примеры с компаниями Nordstrom и LinkedIn продемонстрировали, как значительно можно уменьшить время выполнения заказов и улучшить качество, если мы найдем проблемы в потоке создания ценности и выплатим технический долг.
Глава 7. Как проектировать организацию и ее архитектуру, не забывая о законе Конвея
В предыдущих главах мы определили поток создания ценности для запуска программы преобразований DevOps и установили общие цели и методы для подключения отобранной для преобразований команды в целях улучшения способов доставить продукт клиенту.
В этой главе мы начнем разбираться, как лучше организовать себя для достижения целей потока создания ценностей. В конце концов то, как мы организуем команду, повлияет на то, как мы будем работать. В 1968 году доктор Мелвин Конвей провел известный эксперимент в контрактной исследовательской организации. Восьми сотрудникам было поручено написать компиляторы языков COBOL и ALGOL. Он отметил: «После некоторых первоначальных оценок сложности и необходимого времени пять человек были назначены на написание компилятора COBOL, и три — компилятора ALGOL. В результате компилятор COBOL выполнял компиляцию в пять проходов, компилятор ALGOL — в три».
Эти наблюдения послужили основой того, что сейчас называют законом Конвея, гласящего: «Организации, проектирующие системы… производят их, копируя структуры коммуникаций, сложившиеся в этих организациях… Чем крупнее организация, тем менее она гибкая и тем сильнее выражен характер этого явления». Эрик Реймонд, автор книги The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, придумал упрощенный (и сейчас более известный) вариант закона Конвея, изложенный в словаре Jargon File[46]: «Организация программного обеспечения и организация команды разработчиков программного обеспечения будут совпадать»; обычно упрощается до «если над компилятором работают четыре группы, то получите четырехпроходный компилятор».
Другими словами, то, как мы организуем команды, оказывает мощное воздействие на производимое программное обеспечение, равно как и на результаты проектирования и производства. Чтобы процесс от разработчиков к отделу эксплуатации протекал быстро, с высоким качеством и большой отдачей для клиентов, мы должны организовать команды и деятельность так, чтобы закон Конвея работал на нас. Если сделали плохо, то закон не даст командам действовать безопасно и самостоятельно: вместо этого они будут тесно связаны друг с другом и ожидать друг от друга завершения назначенных частей общей задачи, и даже небольшие изменения потенциально вызовут глобальные, катастрофические последствия.
Пример того, как закон Конвея может либо препятствовать достижению целей, либо способствовать этому, можно найти в технологии Sprouter, разработанной компанией Etsy. Etsy начала использовать DevOps в 2009 г. Сейчас она одна из наиболее уважаемых организаций с DevOps, в 2014 г. получила доход в размере почти 200 миллионов долларов и успешно провела IPO в 2015 г.
Первоначально разработанная в 2007 г., Sprouter соединяла людей, процессы и технологии. Способы соединения нередко приносили нежелательные результаты. Sprouter, сокращение английской фразы stored procedure router (маршрутизатор хранимых процедур), была первоначально разработана для облегчения жизни разработчиков и групп, поддерживающих базы данных. Как заявил во время своей презентации на конференции Surge 2011 Росс Снайдер, старший инженер компании Etsy, «Sprouter была разработана, чтобы команды разработчиков могли писать код PHP для приложений, а администраторы баз данных — запросы SQL в Postgres и Sprouter помогала бы им встретиться на середине этих процессов».