Масштабирование Agile в Spotify
| December 24, 2012 | Posted by admin under Практики, Статьи |
Масштабирование Agile с помощью кланов, отрядов, отделов и гильдий
Авторы: Henrik Kniberg & Anders Ivarsson
https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf
(Tribe – клан, Squad – отряд, Chapter – отдел, Guild – гильдия)
Всегда непросто иметь дело с несколькими командами в организации, занимающейся разработкой продуктов!
Один из самых впечатляющий примеров, с которым мы столкнулись – это музыкальный сервис Spotify, в котором был распространен Agile, несмотря на то, что компания разрослась до 30 команд, которые находились в трех городах.
Spotify – это замечательная компания, которая преобразовала всю музыкальную индустрию. Он существует всего 6 лет, при этом у нее уже более 15 миллионов активных пользователей и более 4 миллионов платежей. Сам по себе продукт можно охарактеризовать как «магический музыкальный плеер, в котором вы можете найти и проиграть любую песню в мире».
Алистар Коберн (один из отцов-основателей Agile разработки) зашел на Spotify и сказал: «Прекрасно, я искал кого-нибудь, кто смог бы реализовать этот матричный формат с 1992 года 🙂 , поэтому действительно очень рад увидеть это.»
Итак, как же это организовано?
Мы уже рассказывали об этом на конференциях и участвовали в дискуссиях на эту тему. Многие люди хотят знать, как компания с сотнями разработчиков работает по agile. Поэтому мы решили написать статью.
Замечание: Spotify быстро развивается (как и любая хорошая agile компания). Эта статья показывает, как мы работаем сейчас, но путь еще не пройден до конца. К тому времени, как вы прочитаете об этом, многое уже изменится.
Отряды
Основная единица разработки в Spotify – это Отряд (Squad).
Отряд похож на Scrum команду, она создана так, чтобы было ощущение мини-startup-а. Весь отряд сидит вместе. У них есть все навыки и инструменты для проектирования, разработки, тестирования и сдачи продукта. Они представляют собой самоорганизующуюся команду, и сами определяют, как им лучше работать. Одни используют спринты Scrum, другие используют Kanban, некоторые используют смесь этих подходов.
У каждого отряда есть долгосрочная миссия, такая как создание и улучшение Android клиента, создание радио Spotify, масштабирование серверной части, или создание платежных решений. Картинка ниже показывает, как разные отряды принимают ответственность за разные части пользовательского опыта взаимодействия.
Поощряется применять в отрядах принципы Lean Startup, такие как MVP (minimum viable product – минимальный жизнеспособный продукт) и подтвержденное обучение (validated learning). MVP означает частые и ранние релизы, а подтвержденное обучение означает использование метрик и A/B-тестирования, чтобы понять, что действительно работает, а что не работает. Все это суммируется слоганом: «Подумайте об этом, постройте это, поставьте это и измените это».
У каждого отряда на длительное время есть своя миссия и своя часть продукта, поэтому члены отряда действительно становятся экспертами в своей области. Например, как построить классное радио.
У большинства отрядов есть свое рабочее пространство, включающее письменные столы, гостиную и «личную» комнату. Почти все стены – это доски. Мы никогда не видели лучшего пространства для взаимодействия!
Да, это акула парящая в воздухе, совершенно нормально.
Чтобы стимулировать обучение и инновации, отряды поощряют к тому, чтобы примерно 10% времени отводилось на «хакерские дни». Во время «хакерских дней» люди делают что им хочется, обычно они проверяют новые идеи и обмен мнениями со своими товарищами. У некоторых команд – один хакерский день каждую вторую неделю, другие собирают свои дни в «хакерскую неделю».
Хакерские дни – это не только прекрасное времяпровождение, это также отличный способ узнавать о современных инструментах и практиках, а иногда это ведет к важным инновациям в продукте!
У отряда нет формально назначенного лидера, но есть product owner. Product owner отвечает за приоритезацию работ команды, но он не вовлекается в то, как выполняется сама работа. Product owner-ы разных отрядов взаимодействуют друг с другом, чтобы поддерживать высокоуровневый документ, который показывает, куда же движется Spotify как единое целое. И каждый product owner отвечает за поддержку баклога продукта для своего отряда.
В отряде также есть agile коуч, который помогает двигаться вперед и улучшать то, как работает команда. Коучи проводят ретроспективы, совещания по планированию спринтов, проводят коучинг 1-на-1, и т.д.
В идеале каждый отряд полностью автономен, напрямую общается со своими заинтересованными лицами, и у него нет блокирующих зависимостей от других отрядов. Это мини-startup. Но с 30 командами – это не просто! Мы прошли длинный путь, но многие улучшения еще впереди.
Чтобы помочь в этом, мы запустили процедуру ежеквартального исследования для каждого отряда. Так мы сможем сконцентрировать наши усилия и понять, какая организационная поддержка нужна. Вот как выглядит такое исследование, для пяти отрядов в клане :
Кружочки показывают текущее состояние, стрелочки показывают тенденцию. Например, мы видим, что три отряда отчитываются о проблемах вокруг поставки и что ситуация не улучшается – эта область требует срочного внимания! Также видно, что у отряда 4 есть проблемы с agile коучем, но ситуация улучшается.
- Product owner – У отряда есть выделенный product owner, который приоритезирует работы, принимая во внимание бизнес ценность и технические аспекты.
- Agile коуч – У отряда есть agile коуч, который помогает выявить препятствия и постоянно улучшать процесс разработки.
- Влияние на работу – Каждый член отряда может повлиять на свою работу, быть активным в планировании и выбирать задачи, над которыми он будет работать. Каждый член отряда может проводить 10% своего времени на хакерские дни.
- Легкость поставки – отряд может сделать (и делает!) поставку с минимальными требованиями к синхронизации с другими частями продукта.
- Процесс, который подходит команде – отряд владеет своим процессом и постоянно улучшает его.
- Миссия – у отряда есть миссия, о которой все знают и заботятся, и истории в баклоге относятся к этой миссии.
- Поддержка организации – отряд знает, куда обратиться, если требуется помощь в решении проблемы, по техническим и по другим вопросам.
Клан
Клан (Tribe) – это набор отрядов , которые работают во взаимосвязанных областях, таких как плеер или инфраструктура бэкэнда.
Клан можно представить как “инкубатор” для мини-стартапов-отрядов, у них большая степень свободы и автономии. У каждого клана есть лидер, который отвечает за создание наилучших условий существования отрядов внутри клана. Отряды клана физически находятся в одном офисе, рядом друг с другом, и расположенные рядом гостиные способствуют общению между отрядами.
Размер клана основан на концепции «Числа Данбара», которая говорит о том, что большинство людей не могут поддерживать социальные отношения более чем со 100 людьми или около того (для групп, которые интенсивно борются за выживание это число может быть значительно больше, но это не относится к Spotify, верите вы этому или нет…). Когда группы становятся слишком большими, все больше появляется таких вещей как ограничивающие правила, бюрократия, политика, дополнительные уровни управления, и другие ненужные вещи.
Поэтому кланы сконструированы так, чтобы в них было меньше 100 человек.
В кланах регулярно проводятся собрания, неформальные встречи, где люди показывают, над чем они работают, что они поставили и что может быть интересно другим из их нынешнего опыта. Проводятся демо работающего программного обеспечения, новых инструментов и методов, крутых проектов хакерского дня, и т.д.
Зависимости между отрядами
Во множестве отрядов всегда есть зависимости. Зависимости – это не обязательно плохо. Иногда отрядам нужно работать вместе, чтобы создать что-то действительно необыкновенное. Тем не менее, наша цель – сделать отряды максимально автономными, особенно нужно минимизировать зависимости, которые блокируют или замедляют работу отряда. Мы регулярно опрашиваем отряды, от каких других отрядов они зависят, и до какой степени эти зависимости блокируют или замедляют работу отряда. Вот пример:
Ниже мы обсудим, как убрать проблемные зависимости, особенно блокирующие, а также зависимости между кланами. Часто это ведет к переприоритезации, реорганизации, архитектурным изменениям или техническим решениям.
С помощью этого исследования также можно увидеть шаблоны зависимостей. Например, то что все больше отрядов замедляются из-за зависимости от отряда операций. Мы используем простой граф, чтобы отследить, как разные типы зависимостей увеличиваются или снижаются со временем.
В scrum есть практика «scrum of scrum», синхронизирующее совещание, где собираются по одному от каждой команды для обсуждения зависимостей. Обычно мы не используем «scrum of scrum» в Spotify, в основном потому что большинство отрядов достаточно независимы, и такие координационные совещания просто не нужны. «Scrum of scrum» проводится, если возникает такая потребность. Например, недавно у нас был большой проект, в котором требовалась скоординированная работа множества отрядов на несколько месяцев.
Чтобы это работало, у команд было ежедневное синхронизационное совещание, на котором они идентифицировали и разрешали зависимости между отрядами, и использовали доску с заметками, чтобы отслеживать неразрешенные зависимости.
Во многих компаниях основной источник зависимостей – это взаимодействие разработки и операций. В большинстве компаний, с которыми мы работали, существует связка «разработка-операции», и связанные с этим задержки и трения.
В Spotify есть отдельная операционная команда, но их работа – это не делать релизы для отрядов, их работа – давать отрядам поддержку, с тем что отряды сами выпускали релизы: поддержка в форме инфраструктуры, скриптов, процедур. Они как бы «строят дорогу к выпуску продукта».
Это неформальное, но эффективное взаимодействие, основанное на личном общении, а не на детальной документации.
Отделы и гильдии
Во всем есть обратная сторона, и потенциальная обратная сторона полной автономии – уменьшение экономии. Может быть, что тестировщик в отряде A сражается с проблемой, которую уже решил на прошлой неделе тестировщик из отряда B. Если бы можно было собрать всех тестировщиков из разных отрядов и кланов, они могли бы делиться знаниями и создавать инструменты для пользы всех отрядов.
Если бы каждый отряд был полностью автономен и не общался бы с другими, то зачем вообще их объединять в одну компанию? Spotify можно было бы поделить на 30 разных мелких компаний.
Вот почему у нас есть Отделы (Chapters) и Гильдии (Guilds). Это клей, который держит всю компанию вместе, это дает нам некоторую экономию, не жертвуя автономией.
Отдел – это маленькая семья людей со сходными навыками, работающих в одной сфере компетенции, внутри клана.
Каждый отдел регулярно встречается, чтобы обсуждать их область экспертизы и их специфические проблемы. Например, отдел тестировщиков или отдел web разработчиков.
Руководитель отдела – линейный менеджер для членов этого отдела, с традиционными обязанностями, такими как развитие людей, определение зарплат и т.п. Однако, руководитель отдела- это тоже часть отряда, и также вовлечен в ежедневную работу, что помогает ему оставаться в контакте с реальностью.
Реальность всегда хуже, чем красивые картинки, вроде той, что выше. Например, члены отдела не распределены равномерно по отрядам: в некоторых отрядах много web разработчиков, а в других их нет совсем. Но картинка даст вам общую идею.
Гильдия – это более органичное и более масштабное «сообщество по интересам», группа людей, которые хотят поделиться знаниями, инструментами, кодом и практиками. Отделы всегда внутри клана, а гильдия охватывает специалистов всей организации. Вот некоторые примеры: гильдия web технологий, гильдия тестирования, гильдия agile коучей, и т.д.
Часто гильдия включает все отделы, работающие в этой области. Например, гильдия тестирования включает всех тестировщиков из всех отделов тестирования, но вообще говоря присоединиться к гильдии может любой заинтересованный.
В каждой гильдии есть «координатор гильдии», который координирует работу гильдии :0)
Пример работы гильдии, который у нас был недавно, – «Неконференция web гильдии», событие, на котором все web разработчики Spotify собрались в Стокгольме, чтобы обсудить проблемы и решения, относящиеся к их области.
Другой пример – гильдия agile коучей. Коучи разбросаны по всей организации, но они постоянно обмениваются знаниями и регулярно встречаются, чтобы взаимодействовать в том, что касается высокоуровневых улучшений, которые мы отслеживаем на доске улучшений.
Минуточку, разве это не матричная структура?
Да. Хорошо, что-то в этом роде. Однако, это другой тип матрицы, в отличие от того, к чему привыкло большинство из нас.
Во многих матричных организациях люди с похожими навыками собраны в функциональные отделы, и «выделяются» на проекты, и «отчитываются» функциональному менеджеру.
В Spotify редко делается что-либо подобное. Наша матрица направлена на поставку.
То есть, люди собраны в стабильные отряды, в которых сотрудники с разными навыками взаимодействуют и самоорганизуются для поставки хорошего продукта. Это вертикальное измерение в матрице, и оно основное, люди физически сгруппированы так и так они проводят большую часть своего времени.
Горизонтальное измерение – для обмена знаниями, инструментами и кодом. Работа руководителя отдела – содействовать и поддерживать это.
В терминах матрицы, вертикальное измерение – это «что», а горизонтальное измерение – это «как». Матричная структура обеспечивает то, что каждый член отряда знает «что создавать дальше» и «как делать это хорошо» .
Это похоже на модель «профессор и антрепренер», рекомендованную Mary и Tom-ом Poppendieck. Product Owner – «антрепренер» или «чемпион по продукту», который фокусируется на поставке отличного продукта, а руководитель отдела – это «профессор» или «лидер по компетенции», который фокусируется на техническом мастерстве.
Между этими ролями существует здоровое напряжение, поскольку антерпренер хочет ускориться и срезать углы, тогда как профессор хочет замедлиться и построить все правильно. Нужны оба аспекта, поэтому напряжение «здоровое».
Что насчет архитектуры?
Технология Spotify ориентирована на сервисы. У нас более 100 разных систем, и каждая может поддерживаться и устанавливаться отдельно. Сюда включаются бэкэнд сервисы, такие как управление плейлистом, поиск или оплата, и клиенты, такие как iPad плейер, специфические компоненты,такие как радио, или секция «Что нового?»музыкального плейера.
Технически, любой может редактировать любую систему. Поскольку отряды – это эффективно функционирующие команды, им нужно модифицировать множество систем, чтобы выпустиь новую фичу.
Риском для этой модели является то, что архитектура системы будет похожа на непонятно что, если никто не фокусируется на целостности всей системы.
Чтобы справиться с этим риском, у нас есть роль «System Owner». У каждой системы есть system owner, или пара system owner-ов (мы поощряем парность). Для критичных систем system owner – это Dev-Ops пара, один – со стороны разработки, а другой – со стороны операций.
System owner – это человек, к которому нужно идти по любым техническим или архитектурным вопросам, связанным с его системой. Он является координатором и направляет людей, которые вносят изменения в код системы, чтобы быть уверенными в том, что они не столкнуться друг с другом. Он фокусируется на таких вещах как качество, документация, технический долг, устойчивость, масштабируемость и процесс релиза.
System Owner – это не узкое место и не «архитектор башни из слоновой кости». Он не должен лично принимать все решения, или писать весь код или делать поставлять все релизы. Это обычный член отряда или руководитель отдела, у которого есть обычные ежедневные обязанности, кроме владения системой. Однако, время от времени, он будет брать «День
system owner-а» и выполнять домашнюю работу в своей системе. Обычно мы стараемся, чтобы время на поддержку своей системы было не больше 10% рабочего времени. Однако это может сильно отличаться от системы к системе.
У нас также есть роль главного архитектора, это человек, который координирует работу по высокоуровневым архитектурным вопросам, которые затрагивают множество систем. Он ревьюирует разработку новых систем, чтобы избегать общих ошибок, и чтобы они были созданы в соответствии с нашим архитектурным видением. Результатом его ревью является предложения и рекомендации, финальное решение по дизайну системы принимает отряд, который строит ее.
Как все это работает?
Компания Spotify выросла очень быстро – более чем за 3 года мы выросли с 30 до 250 человек. Эта модель масштабирования – с отрядами, кланами, отделами и гильдиями – была постепенно введена в течение последнего года, поэтому люди все еще привыкают к ней. Но, судя по опросам и ретроспективам, эта модель масштабирования работает достаточно хорошо!
Несмотря на быстрый рост, удовлетворенность сотрудников постоянно растет: в апреле 2012 она составляла 4.4 из 5 возможных.
Однако, как это бывает с любой растущей организацией, сегодняшние решения рождают завтрашние проблемы. Поэтому следите за обновлениями, история еще не окончена :o)
Pingback: Crisp's Blog » Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds()