Модель Spotify

Spotify Model (модель Спотифай) — набор организационных методик, используемый для разработки программного обеспечения, позволяющий масштабировать команду разработки в соответствии с принципами Agile. Впервые использован при разработке музыкального сервиса Спотифай^[1][2][3][4].

Модель Спотифай стала результатом длительного эксперимента, проводимого внутри компании. Получившаяся система масштабирования для разработки программного обеспечения не основана на каком-то из известных фреймворков (SAFe, Disciplined Agile и пр.), а базируется на чётких определениях принципов, ролей и стратегий совместной работы. Оригинальный выбор ролей и принципов позволил команде разработчиков Спотифай создать гибкую методологию разработки, которая решила многие проблемы, присущие гибким командам, работающим в масштабе предприятия.

С организационной точки зрения Спотифай заменил общепринятые скрам-команды гибкими «отрядами» (англ. squad), вольными в определении собственных методов и практик и не сдерживаемые навязанными сверху «только скрамом» или «только канбаном»^[5]. После того, как «отряд» демонстрирует свое понимание гибких методологий и способность к самоорганизации, команда получает возможность самостоятельно выбирать или отвергать общепринятые события или процессы скрама или экстремального программирования: например, в некоторых командах могут использоваться ежедневные «стоячие совещания», а в остальных — нет. Вместо следования конкретным практикам от команд требуется фокус на следующих принципах: автономность, соответствие миссии компании, высокая мотивация, доверие к идеям сообщества. Каждый из «отрядов» сфокусирован на отдельной части функциональности продукта, как то поиск или плейлисты, что позволяет им становиться экспертами в своих областях^[2].

На следующем уровне взаимодействия «отряды» Спотифай с общей или схожей миссией объединяются в «племена» (англ. tribe). «Племена» периодически собираются для обсуждения и минимизации количества зависимостей, а также чтобы убедиться, что «отряды» работают над одной и той же миссией. Большая часть совместных собраний носит спонтанный характер, а не запланированы заранее.

Для объединения членов различных команд, работающих в одной и той же дисциплине (что часто происходит, когда функциональные команды заменяются кросс-функциональными), Спотифай использует «отделы» (англ. chapter) и «гильдии» (англ. guild). Под «отделом» подразумевается группа сотрудников из разных команд внутри одной и той же дисциплины, области знания (например, тестировщики или верстальщики), которые регулярно встречаются, чтобы убедиться в использовании новейших трендов и технологий, обмениваться знаниями и эффективно переиспользовать существующие решения. «Гильдия» же представляет собой менее формальную и включающую в себя большее количество людей группу: так, гильдия тестировщиков состоит не только из широкого круга тестировщиков (включая и автоматизаторов, и специалистов по мануальному тестированию), но и из программистов, которые хотят лучше понимать процессы тестирования и вносить свой вклад в деятельность в этом направлении^[2].

Используемая в подходе модель масштабирования была постепенно внедрена в Спотифай на протяжении 2011—2012 годов. Команда разработки стремительно выросла в размерах — за три года с 30 до 250 инженеров. Несмотря на подобный рост, удовлетворённость сотрудников также постепенно повышалась, и в апреле 2012 года составила 4.4 из 5 баллов^[5][6].

Компания Спотифай стала не единственным местом, в котором используется данная модель. За её пределами модель Спотифай использовалась, например, компанией Tech Mahindra^[англ.] для работы над крупным проектом в банковской и страховой сфере^[4].

Существует мнение, что Модель Spotify является фреймворком масштабирования команд, которые занимаются разработкой программного обеспечения согласно принципам Agile. Однако, учитывая факт, что модель Spotify не основана на каком-либо существующем фреймворке (напр., Scaled Agile Framework или LeSS), не имеет официальной системы сертификации и разрабатывалась исключительно как способ организации разработки программного обеспечения внутри компании Spotify с учетом её организационных и культурных особенностей, то некорректно считать данную модель фреймворком масштабирования для команд разработки, следующих принципам Agile.

Хенрик Книберг, один из соучастников разработки организации работы внутри компании Spotify, в ответ на распространяющуюся известность модели Spotify и ее копирование в других компаниях утверждал, что модель Spotify не является фреймворком масштабирования команды, а также, что модель Spotify, строго говоря, не является "моделью" как таковой, но отображает пример организации работы в конкретной компании.^[7]