Групповые топологии (далее TT) излагают набор принципов того, как группы разработчиков программного обеспечения взаимодействуют друг с другом, а затем предлагают набор практических предложений о том, как эти команды должны работать на практике. Якобы это применимо конкретно к командам разработчиков программного обеспечения, хотя на практике я думаю, что многие или все идеи можно было бы обобщить на другие дисциплины, работающие со знаниями.

Книга короткая — всего 240 страниц — но невероятно плотная. Я сделал новый рекорд по количеству хайлайтов; 122 по данным Goodreads. Многие жалобы на книгу заключаются в том, что она проста или может быть выведена из первых принципов, и хотя это правда, я думаю, что она сделана сжато и таким образом, чтобы предложить хороший общий словарь для последующих бесед.

Team Topologies написана Мэттью Скелтоном (автором ряда книг по программному обеспечению и программному обеспечению) и Мануэлем Паисом. Его издает IT Revolution Press, которая также опубликовала The Phoenix Project, The Unicorn Project, Accelerate и около дюжины других названий, связанных с программным обеспечением. Они быстро становятся одним из моих любимых издателей материалов, связанных с программным обеспечением.

Существуют десятки или сотни способов оценивать книги, но когда вы читаете научную литературу, особенно научную литературу, связанную с вашей работой, наиболее важной мерой является изменение того, как вы думаете о каком-либо аспекте того, чем вы занимаетесь. С тех пор как я прочитал Team Topologies (я закончил ее чуть больше недели назад, на момент написания), она уже повлияла на то, как я думаю об отношениях между командами и о том, как они предоставляют услуги друг другу. Так что, учитывая это и несмотря на то, что многое из того, что содержится в книге, можно вывести из первых принципов, я должен поставить этой книге пять звезд и настоятельно рекомендовать всем, кто занимает хоть какую-то руководящую или архитектурную должность в компании-разработчике программного обеспечения.

На Goodreads он оценивается в 4,29 звезды с относительно небольшим рейтингом 761.

Командные топологии начинаются с очень прямого предложения, с которым, если вы читаете это, вы, вероятно, уже знакомы. Утверждение теперь известно как закон Конвея, и оно заключается в следующем.

Организации, разрабатывающие системы [ . . . . ] вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций.

Мелвин Конвей, Как изобретают комитеты

Это немного загадочная формулировка, и обычно она означает, что команды создают программное обеспечение, отражающее структуру их команды (или, в шутку, четыре группы, работающие над компилятором, создадут четырехпроходный компилятор). em>, спасибо Эрику Рэймонду.) Однако это не совсем то, о чем говорится. На самом деле закон Конвея гласит, что шаблоны общения команд будут определять паттерны общения в программном обеспечении. Да, это означает, что четыре команды создадут четырехпроходный компилятор, но это также означает, что если команды A и B тесно сотрудничают, первые два прохода могут оказаться неразрывно связанными непредвиденными способами. Удивительно, но лучше всего у вас получается работать с людьми, с которыми вы регулярно работаете (примечание, сарказм).

Этот, казалось бы, простой закон важно понять, потому что он имеет большое количество следствий, многие из которых вы поняли бы, если бы сели и хорошенько подумали об этом (однако я этого не делал до написания этой книги, поэтому я потратил много времени морщился от того, что мне никогда не удавалось вывести эти идеи самостоятельно.) Некоторые из этих идей включают…

  • Первый набросок вашей организационной схемы — это первый набросок вашей архитектуры.
  • Архитекторы программного обеспечения должны управлять людьми, потому что коммуникативные шаблоны организации преобладают над любой диаграммой, которую они могут себе представить.
  • Если вам нужны слабо связанные компоненты (внимание, спойлер, вы хотите), вам следует свести к минимуму пропускную способность командного взаимодействия.
  • Указание явных коммуникационных контрактов может помочь в определении пропускной способности.

Второй ключевой принцип, используемый в ТТ, — это то, что они называют числом Данбара, хотя их интерпретация кажется немного более свободной, чем моя. На самом деле они заявляют, что в командах должно быть небольшое количество людей, не более 15. Затем они предлагают концентрические группы таких команд; менее 15 в команде, затем группа команд, суммарное лидерство которых не более 15, суммарное лидерство их опять не более 15 и т.д. и т.п. Описанный фрактальный шаблон использует команду в качестве базовой единицы, а затем позволяет организации масштабироваться в зависимости от количества доменов, которыми необходимо владеть (внутри предусмотрены некоторые эвристики).

Оставшаяся часть книги посвящена моделям взаимодействия команд друг с другом; четыре описаны в книге со ссылками еще примерно на дюжину. За то время, пока я об этом думал, четыре подробно описанных примера полностью охватывают все примеры, которые я придумал, и я подозреваю, что они охватили бы 80% или более реальных случаев. Я не буду подробно останавливаться на них, но мне очень понравилась команда сложной подсистемы. Команда сложной подсистемы — это команда, которая добавляет ценность команде потока создания ценности (типичная межфункциональная команда, работающая над созданием сквозного продукта), абстрагируя одну сложную подсистему, тем самым позволяя потоку создания ценности команда, чтобы сосредоточиться на том, чтобы удовлетворить своих клиентов, без накладных расходов на такие специальные знания.

Примеры сложных подсистем могут включать кодек обработки видео, математическую модель, алгоритм согласования сделок в реальном времени, систему отчетности о транзакциях для финансовых услуг или механизм распознавания лиц.

Мэттью Скелтон, Топологии команд: организация бизнес- и технологических групп для обеспечения быстрого потока

Все приведенные примеры представляют собой невероятно сложные вычислительные задачи; огромные области, требующие специальных знаний сами по себе. Затем эти сложные домены предоставляют API, SDK или другую абстракцию этих специальных знаний команде потока создания ценности, которой не обязательно знать, как это работает. Я обнаружил, что это дает элегантное решение проблемы, с которой я долгое время боролся, о том, как продуктовая команда может обеспечить сквозную ценность в сложных областях. На самом деле это один из паттернов, которые я сейчас предлагаю командам, с которыми я работаю.

Эта книга явно не идеальна. Одна из частых жалоб заключается в том, что он короткий, но на самом деле я вижу в этом силу в данном случае. Он настолько плотный, что если бы он был длиннее, он мог бы начать содержать неуправляемый объем информации. Одна из вещей, которая действительно беспокоила меня, — это их повторяющиеся ссылки на число Данбара… таким образом, что это, казалось, не согласовывалось с фактическим исследованием Данбара. Я согласен с тем, что команды от 8 до 12 человек, вероятно, идеальны, не более 15, но число Данбара, по-видимому, обычно относится к числу стабильных когнитивных отношений, которые человек может поддерживать, и обычно приводится как что-то между 100 и 250, при этом 150 по-видимому, на него чаще всего ссылаются (FWIW, я не психолог-бихевиорист и, возможно, совершенно неверно истолковал это). 15 отношений, которые Данбар на самом деле называет, он называет группой симпатии. Я думаю, что интерпретация Скелтона оттуда, вероятно, хороша, но неправильная маркировка меня расстраивает.

Один незначительный момент, который меня смутил, заключался в том, что в этой книге «командные топологии» не относятся к какому-либо способу взаимодействия команд, а скорее относятся к конкретным шаблонам, описанным в ней. Я понял это довольно быстро, но оно так и не было определено, и я думаю, что неправильно истолковал его по крайней мере пару раз.

Еще одна вещь, которая мне показалась немного необычной, заключалась в том, что эта книга предлагается как отдельное название, но она так часто и обильно ссылается на несколько других книг, что их почти можно считать обязательными для предварительного прочтения, чтобы следовать ей должным образом. Чаще всего упоминается Ускорение, которое, конечно же, я рекомендую вам прочитать (Я просмотрел его здесь), но я думаю, что если эта книга предназначена для самостоятельной работы, она нуждалась в доработке (или, в качестве альтернативы, должна поставляться со списками рекомендуемой литературы для предварительного чтения). К счастью, я все равно прочитал Accelerate непосредственно перед TT.

В целом, это одна из тех замечательных книг, в которых рассматривается одно понятие (закон Конвея), а затем подробно рассказывается о том, что оно означает и как его применять в реальной жизни. Если вы когда-нибудь будете разрабатывать организационную структуру, архитектуру программного обеспечения (или, как мы узнали из ТТ, и то, и другое одновременно), эта книга должна быть обязательна к прочтению. Если вы когда-либо занимали руководящую должность, где взаимодействие в команде и плоскости перелома являются важными идеями, то эта книга тоже обязательна. Даже если это не так, если вы работаете в любой масштабной организации, хорошие теоретические знания о том, как работают команды и, что важно, взаимодействуют, очень вам пригодятся.

Вы читали "Топологии команд"? Что ты подумал? Какие еще книги повлияли на ваше отношение к программному обеспечению и разработке? (т.е. что мне читать дальше)