Бас Водде - Масштабированный скрам. Как организовать гибкую разработку в крупной компании

Мы сидели в переговорной комнате и пили горячий кофе. За окном – типичное для Северной Европы пронизывающее холодом зимнее утро. Вскоре вошел наш новый клиент и пожал нам руки. «Спасибо, что приехали, – сказал он. – Начнем с того, что у нас довольно небольшая группа разработки, человек 80, плюс-минус».

Однажды мы помогали с внедрением гибкой разработки в команде, которая мечтала вырасти до очень большого размера: до 12 человек.

У людей разные шкалы того, что значит «большая» продуктовая группа [2] Методология скрама (и эта книга) применима к разработке продуктов как для внешнего рынка, так и для внутреннего пользования. . Для кого-то это 50 человек или даже меньше. Для других – в разы больше. Мы обычно работаем с однопродуктовыми группами, насчитывающими 100–500 человек (которые внедряют принципы скрама, бережливого мышления и гибкой разработки, как правило, в области программно-интенсивных встраиваемых систем). Вот наш подход: «Если собрать всю группу в одной комнате, вы сможете вспомнить имена всех ее членов? Если нет, значит, у вас большая группа». Таково наше определение «большой» продуктовой группы, основанное на фундаментальном критерии: нашей ограниченной памяти.

Наша ключевая рекомендация: проработав много лет с большими, распределенными и офшорными (удаленными) продуктовыми группами, мы проанализировали наш опыт и сделали следующий вывод: не работайте с такими группами !

Есть гораздо более эффективные способы разработки больших продуктов, чем задействовать рой разработчиков, рассеянных по разным местам. Лучше создать небольшую группу из крутых разработчиков и других специалистов, способных работать командами, хорошо им платить и разместить их в одном месте с продуктовым менеджером, который выступает в качестве «голоса клиента».

Но мы знаем, что вы не прислушаетесь к нашему совету и все равно будете использовать большие, распределенные и офшорные группы разработки. Причина в том, что ваша существующая система уже структурирована таким образом, или в том, что вы придерживаетесь (пред)убеждения, будто «большие системы требуют большого количества людей». Наши клиенты регулярно спрашивают нас: «Как рассчитать, сколько людей нам может потребоваться?» Мы всегда советуем: «Начните с небольшой группы сильных специалистов и увеличивайте ее только тогда, когда без этого действительно невозможно обойтись». Такая необходимость возникает редко.

Раз уж вы все равно будете использовать большие, распределенные и офшорные группы, мы хотим поделиться с вами нашим собственным и чужим опытом по применению принципов и практик бережливой и гибкой разработки в такой рабочей среде [3] В книге «Практики масштабирования бережливой и гибкой разработки: Масштабированный скрам для больших, рассредоточенных и офшорных продуктовых групп» содержатся детальные практические советы касательно масштабирования и планирования, продукт-менеджмента, распределенной и офшорной разработки, контрактов, требований, проектирования и архитектуры, координации, унаследованных кодов, тестирования и многого другого. .

Когда Бас входил в руководящую команду одной большой продуктовой группы, он постоянно во время совещаний спрашивал: «Почему мы делаем это именно так? Что будет, если мы сделаем это иначе?» Через несколько месяцев один из членов команды признался Крэгу: «Первое время эти вопросы выводили меня из себя. Но потом я оценил их значение». Бас не стремился вывести людей из себя; он хотел побудить их к системному мышлению , позволяющему: 1) увидеть более глубокую динамику организационной системы в целом; 2) понять, как система стала такой, какая она есть; и 3) пересмотреть предположения, лежащие в основе существующей организации.

Когда люди впервые слышат о скраме с его короткими, ограниченными по времени итерационными циклами разработки, они поначалу воспринимают это как локализованную практику инкрементального создания продукта за счет небольших управляемых шагов с использованием обучения и корректировки, которые ведут к поставленной цели. Поэтому они говорят: «О, аджайл меня не касается. Это для разработчиков ». Но запуск таких циклов обучения на нижнем организационном уровне потенциально способен оказать гораздо более масштабное воздействие: как правило, это требует запуска аналогичных «петель» обучения и на более высоком уровне – создания обучающейся организации, где люди будут постоянно пересматривать структуры и правила, которые определяют и окружают разработку продуктов. Внедрение принципов скрама или бережливого подхода в очень больших продуктовых группах неизбежно ведет к такой высокоуровневой организационной трансформации.

Пример.Представим компанию, в которой подразделение разработки внедряет скрам, чтобы повысить адаптивность. Но отдел продаж продолжает работать по старинке: его сотрудники стремятся увеличить личные комиссионные и ежеквартальные продажи, с почти безграничным оптимизмом расписывая клиентам то, что «могут сделать наши самые лучшие разработчики», и обещая им достать звезды с неба. В результате подразделение разработки сталкивается с «обязательствами», которые оно не давало и не в состоянии выполнить; в компании его обвиняют в неисполнении « наших обещаний» и делают вывод, что «скрам не работает».

Если бы эта книга была посвящена внедрению скрама в небольшой однопродуктовой команде из двух десятков человек, системное мышление и организационные инструменты были бы интересными, но не критически важными темами. Однако они играют ключевую роль для успешного внедрения скрама, если данная методология масштабируется на однопродуктовую группу, скажем, из 400 человек, которая, возможно, работает в составе крупной компании-разработчика, насчитывающей тысячи сотрудников, и совершает переход к скраму в тесном сотрудничестве с отделами продаж и доставки в условиях ограничений, налагаемых традиционными корпоративными правилами в отношении управления человеческими ресурсами, структуры команд, отчетности, оценки эффективности, управления проектами, контрактов и вознаграждения.

Следовательно, эта книга утверждает, что один из краеугольных камней успешного масштабирования скрама и гибкой разработки – люди, которые готовы учиться и применять необходимые инструменты мышления [4] Термин «инструменты мышления» был популяризирован в [Reinertsen97]. , включая системное мышление, анализ ментальных моделей, бережливое мышление, теорию массового обслуживания и распознавание ложных дихотомий (но не ограничиваясь этим).