Командні Топології [переклад]

Будь-яка масштабна робота по створенню програмного забезпечення потребує залучення великої кількості людей, а тут одразу постає питання, як розділити їх на ефективні команди. Формування команд, орієнтованих на бізнес-можливості, допомагає в розробці ПО, що буде відповідати потребам клієнтів, але перелік необхідних навичок часто буває завеликий. Командні Топології (Team Topologies) — це модель для опису організації команд розробки ПО, запропонована Метью Скелтоном (Matthew Skelton) і Мануелем Пейсом (Manuel Pais). Вона визначає чотири форми команд і три режими командних взаємодій. Модель заохочує співпрацю, яка дозволяє командам, орієнтованим на бізнес-можливості, процвітати у виконанні своїх цілей із забезпечення постійного потоку цінного програмного забезпечення.

Оригінал: TeamTopologies
Автор: Martin Fowler

Основним типом команди в цій структурі є потокова команда (stream-aligned team), орієнтована на бізнес-можливості, яка відповідає за програмне забезпечення для окремого бізнес напрямку. Це команди, які працюють довго і спрямовують свої зусилля по створенню програмного продукту для збільшення можливостей бізнесу.

Кожна потокова команда має повний стек і повний життєвий цикл: відповідає за інтерфейс, бек-енд, базу даних, бізнес-аналіз, пріоритезацію функцій, UX, тестування, розгортання, моніторинг – увесь комплекс розробки програмного забезпечення. Вони орієнтовані на результат, зосереджені на бізнес-цінності, на відміну від команд, що зосереджені на діяльності і таких функціях, як бізнес-аналіз, тестування або бази даних. Але вони також не повинні бути занадто великими, ідеальний розмір, це команда, яку можна нагодувати двома великими піцами. Велика організація матиме багато таких команд, з різними бізнес-можливостями для підтримки, але спільними потребами, як зберігання даних, мережеві налаштування і можливість моніторингу.

Для невеликої команди важливим є зменшення когнітивного навантаження, щоб вони могли зосередитися на потребах бізнесу, а не на таких питаннях як, наприклад, зберігання даних. Важливою частиною цього процесу є створення платформи для рішення цих нефокусних проблем. Це може бути широко доступна стороння платформа, наприклад Ruby on Rails. Але не для всіх продуктів існує єдина готова до використання платформа, тож команді доведеться знайти та інтегрувати кілька систем. У великій організації також постане питання використання внутрішніх послуг та дотримання корпоративних стандартів.

Цю проблему можна вирішити шляхом створення внутрішньої платформи для організації, яка буде об’єднувати внутрішні та зовнішні служби. Team Topologies називає команду, яка це будує - команда платформи.

Менші організації можуть працювати з єдиної командою платформи, яка створює тонкий шар поверх зовнішнього набору продуктів. Однак для великих платформ потрібно більше людей, ніж можна нагодувати двома піцами. Таким чином, автори переходять до опису групи платформи, що включає декілька команд платформи.

Важливою характеристикою платформи є те, що вона призначена для використання здебільшого в режимі самообслуговування. Потокові команди як і раніше відповідають за роботу свого продукту та керують використанням платформи, не очікуючи детальної співпраці з командою платформи. У структурі командних топологій цей режим взаємодії називається режимом X-як-послуга, при цьому платформа діє як сервіс для потокових команд.

Однак команди платформ повинні самі будувати свої послуги як продукти, глибоко розуміючи потреби своїх клієнтів. Це часто вимагає, щоб вони використовували інший режим взаємодії - режим співпраці. Режим співпраці є більш інтенсивною партнерською формою взаємодії, і його слід розглядати як тимчасовий підхід, доки платформа не стане достатньо зрілою, щоб перейти до режиму X-як-послуга.

Поки що нічого особливо винахідливого модель не представляє. Поділ організацій на команди, орієнтовані на бізнес, і команди технологічної підтримки — це підхід, такий же старий, як корпоративне програмне забезпечення. Останніми роками багато авторів висловлювали важливість того, щоб ці бізнес-команди відповідали за повний стек і повний життєвий цикл. Для мене яскраве розуміння командних топологій зосереджено на проблемі: наявність повноцінних бізнес-команд із повним життєвим циклом означає, що вони часто стикаються з надмірним когнітивним навантаженням, яке суперечить бажанню невеликих команд. Ключовою перевагою платформи є те, що вона зменшує це когнітивне навантаження.

Головний інсайт Командних топологій це зменшення когнітивного навантаженні на потокові команди завдяки використанню платформи.

Це розуміння має глибокі наслідки. Для початку це змінює те, як команди платформ мають думати про платформу. Зменшення когнітивного навантаження клієнтських команд призводить до різних дизайнерських рішень і планів продуктів для платформ, призначених головним чином для стандартизації або скорочення витрат. За межами платформи це розуміння спонукає командні топології до подальшого розвитку своєї моделі, визначивши ще два типи команд.

Деякі потреби вимагають спеціалістів, які можуть витратити багато часу та енергії на опанування теми, важливої для багатьох команд, що вирівнюють потоки. Спеціаліст із безпеки може витрачати більше часу на вивчення питань безпеки та взаємодію із напрямком безпеки, ніж це було б можливо як член команди, що працює в потоку. Такі люди об’єднуються в команди можливостей, роль яких полягає в розвитку відповідних навичок в інших командах, щоб ці команди могли залишатися незалежними та краще володіти та розвивати свої послуги. Щоб досягти цього, робочі групи використовують третій режим взаємодії в командних топологіях. Режим фасилітації включає в себе роль тренера, де команда не існує для написання та забезпечення відповідності стандартам, а натомість для навчання своїх колег, щоб потокові команди стали більш автономними.

Потокові команди несуть відповідальність за весь потік цінностей для своїх клієнтів, але час від часу ми знаходимо технічну спеціалізацію потокової команди, яка є достатньо специфічною, щоб зосередитися на ній окремо. Це веде до четвертого й останнього типу команди: команда складної підсистеми. Метою команди зі складною підсистемою є зменшення когнітивного навантаження потокових команд, які використовують цю складну підсистему. Це вартий розподіл, навіть якщо для цієї підсистеми є лише одна команда клієнтів. Переважно команди зі складними підсистемами прагнуть взаємодіяти зі своїми клієнтами, використовуючи режим X-як-послуга, але їм доведеться використовувати режим співпраці протягом коротких періодів часу.

Командні топології містять набір графічних символів для ілюстрації команд та їхніх взаємовідносин. Наведені тут стандарти відповідають чинним стандартам, які відрізняються від тих, що використовуються в книзі. Недавня стаття детально описує, як використовувати ці діаграми.

Командні топології розроблено з явним визнанням впливу закону Конвея (Conways Law). Прихильники командної топології мають на меті, щоб структура команди сформувала майбутній розвиток архітектури програмного забезпечення у відокремлені компоненти, узгоджені з потребами бізнесу.

Джордж Бокс (George Box) акуратно пожартував: «усі моделі неправильні, деякі корисні». Отже, топології команд неідеальні: складні організації не можна просто розбити на чотири види команд і три види взаємодії. Але такі обмеження роблять модель корисною. Командні Топології — це інструмент, який спонукає людей розвивати свою організацію до більш ефективного способу роботи, який дозволяє потоково вирівняним командам максимізувати свій потік, зменшивши когнітивне навантаження.