Джей Сазерленд - Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Приведу пару примеров. Один касается аппаратного обеспечения, другой – программного, но мышление в основе примеров идентично.

Существует некая частная космическая компания, которую я назову Stealth Space Company (Незаметная космическая компания). Так они называют себя на своей странице в LinkedIn, в любой нежелательной публикации в СМИ и постоянно всем повторяют: «Мы не хвалимся, мы не говорим – мы делаем». Они располагаются на заброшенной морской авиационной станции на краю залива Сан-Франциско у побережья США. Военные базы вроде этой отличаются в зависимости от расположения и основавшей их службы, но у них есть одна общая черта – жесткая, бескомпромиссная архитектура, в которой функциональность доминирует над формой.

Крис Кемп – СЕО этой компании. У него светлые волосы, он обычно носит черные футболки, пиджаки и брюки. Его мантра – скорость. Приведу отрывок из его письма, в котором он анонсировал первую попытку запуска.

В воскресенье мы планируем запуск ракеты. Ее с нуля спроектировала команда, которой 18 месяцев назад не существовало. Мы сделали работу в пять раз быстрее, в пять раз дешевле, чем кто-либо до нас. Это первый тестовый запуск серии, и он позволит нам достичь земной орбиты, поскольку мы создаем команду и меняем свои действия на основании того, что узнали из каждой попытки.

Он смотрит на компанию SpaceX Илона Маска и видит цель, которую не просто превзойдет, но превзойдет громко: в пять раз быстрее и в пять раз дешевле. И он использует Scrum, чтобы добиться того, чего хочет. Его цель – стать космическим FedEx [17] Американская грузовая авиакомпания. , ежедневно отправляя небольшие целевые нагрузки на низкую орбиту. Армии необходим комплекс разведывательных спутников над новой проблемной зоной? Без проблем; спутники будут там через 30 минут, а не через три года.

Беседуя с его сотрудниками, вы чувствуете их стремление к успеху. Один из его лидеров всю свою карьеру посвятил космическому бизнесу: SpaceX, Virgin Galactic, Boeing. Он сказал, что некоторые члены его команды полагали, будто фреймворк Scrum подходит только для программного обеспечения.

«Для меня это все в новинку, – сказал он мне. – Но я увидел, насколько плохи старые способы работы. Я говорю новым инженерам, что они пока не знают, как им повезло, и я полностью вовлечен в общее дело. Я ясно дал им понять: либо они тоже вовлечены, либо им нужно искать другую работу».

Ракета, как я узнал здесь, включает три системы: двигатель, который превращает топливо в силу; авионику, которая управляет движением ракеты, и структурные компоненты, оболочку, которая держит все вместе. Поначалу все они были плотно связаны и в рамках каждой отдельной системы, и между системами. Так разработчики пытались избавиться от лишнего веса. Именно поэтому каждый интерфейс разработан индивидуально, у него свои детали и соединения. Это имеет смысл, если думать только о весе. Проблемы начинаются тогда, когда что-то нужно починить.

Приведу простой пример. В их первой ракете комплекс бортового оборудования контролировался рядом специальных монтажных схем, которые были соединены друг с другом и с ракетой, а переключатели выполнялись из очень редкого унобтаниевого [18]материала. Если одна схема ломалась, нужно было снимать все и восстанавливать сотни коннекторов вручную, используя невероятно дорогие материалы. В какой-то момент редкоземельные элементы, которые они применяли для коннекторов, просто ушли с рынка: Apple и Samsung смели мировой запас для производства нового поколения телефонов. Чтобы раздобыть материалы, потребовалось двенадцать недель. Кемп был в ярости и выругался: «Три месяца, чтобы достать коммутатор Ethernet? Подобное [непотребство] нас в могилу сведет!»

Мой коллега Джо Джастис сел вместе с Итаном, руководителем отдела авионики, и объяснил проблему. «Во-первых, – сказал Джо, – у вас есть все эти схемы со специальными коннекторами и все они разные, каждая передает свою информацию. Вам нужно снизить запутанность, заменить их другими коннекторами, с лучшим дизайном. Но если демонтировать один, сломаются все. Поэтому наладим стабильный интерфейс между комплексом бортового оборудования и другими системами ракеты. Перестроим их так, что они могли передавать все виды данных, больше, чем вам нужно, но с общими коннекторами, которые можно купить готовыми и недорого. Ограничим проблему, сделаем выборку элементов, которые не изменятся. Убедимся, что остальные проектировщики ракеты знают, как нужно подсоединять свой интерфейс, используя одну сторону коннектора, а проектировщики радиоэлектронных систем в курсе, что им нужна вторая. Так вы сможете менять что угодно в любой части системы; пока общий интерфейс сохраняется, неважно, где будет происходить изменение. Нужно сделать задачи модульными. По принципу конструктора LEGO. Чтобы части легко соединялись и разъединялись».

Такой подход упростил формирование критериев готовности: элемент должен работать и подходить известному стабильному интерфейсу. Теперь вы можете решать проблемы одну за другой. Лишний вес из-за самого интерфейса? Займетесь этим позже, когда решите остальные проблемы.

Теперь возьмем пример гибкой архитектуры из сферы программного обеспечения. Схема та же. Spotify – музыкальный сервис. Его цель, как и цель аэрокосмической компании, – скорость. Когда компания еще была стартапом, ее CEO Дэниел Эк как-то сказал Scrum Inc.: «Apple, Google и Amazon хотят нас убить. И это умные, крупные компании со множеством навыков. Единственный способ выжить для нас – скорость. Нам надо быть быстрее, чем они».

Так Spotify разделился на модули, подобно ракете. Есть система воспроизведения, рекомендательный движок, функции плейлиста, мобильное приложение и т. д. И точно так же, как Stealth Space Company, они разработали стабильные интерфейсы между частями. Команды, занимающиеся плейлистами, могут вносить столько инноваций, сколько хотят, менять столько, сколько пожелают, пока их участки укладываются в нужные рамки, передают и получают нужные данные и не ломают ничего другого. Так они могут быстро двигаться вперед и не беспокоиться о том, что повредят другие части системы.

Не нужно менять всю систему, чтобы изменить ее часть. Интерфейс избавляет сотрудников от множества проблем. Во многих системах зависимости между элементами так велики, что любое изменение практически невозможно, а скорость разработки падает до черепашьей, поскольку инженерам приходится использовать все больше рискованных исправлений и честных слов, чтобы удержать от распада неповоротливую и хрупкую систему.

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