Попробуйте организовать Lean Coffee!

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

Кандидатурой на роль Владельца Продукта, естественно, оказался Технический директор, так как он один из основателей компании и знает рынок, бизнес и клиентов лучше, чем кто-либо ещё. Выбор был настолько очевиден, что я не ожидал никаких подвохов, однако они появились через несколько месяцев.

Все требования находились в инструменте Redmine. Они состояли в основном из большого количества технических задач для компонентных команд, поскольку на них основывалась текущая организационная структура. Поэтому мы вооружились видением компании и среднесрочными целями, чтобы создать Бэклог Продукта с нуля.

Для этого мы использовали визуальный подход к управлению. Бэклог Продукта стал наглядным и конкретным — он был представлен в виде флипчартов и стикеров.

Один из принципов LeSS — ориентация на клиента. Это означает, что организационная структура в первую очередь помогает создать наивысшую ценность для клиента. Мы не знали, смогут ли все фиче-команды создать её одновременно на пользовательских интерфейсах всех трёх платформ. Возможно, имело смысл сформировать команды в соответствии с сегментами клиентов. Мы хотели получить ответ с помощью HitMap. Это очень простой и надёжный инструмент. Он помогает увидеть архитектурные компоненты, которые используются в каждом элементе Бэклога Продукта. HitMap выглядит так:

Цель совершенства — создать фиче-команды, которые смогут выбирать любой элемент из Бэклога Продукта и самостоятельно выпускать его на рынок по крайней мере один раз за Спринт. Допустим, нам нужны одинаковые фичи продукта для платформы как Android, так и iOS. Нам необходимо создать фиче-команды, чтобы в каждой были разработчики под iOS и Android.

Мы потратили пару часов на создание HitMap. В итоге у нас получилось несколько листов со стикерами. Когда мы закончили, Владельцу Продукта стало ясно, что ему нужны комплексные фиче-команды наподобие пилотной, чтобы достичь максимальной гибкости. Основные фичи продукта, которые он планировал разработать, были необходимы для всех трёх каналов (Web, Android, Windows).

После создания HitMap Владелец Продукта понял, что ему необходимы комплексные фиче-команды. Я помог ему организовать встречу, на которой он представил окончательную версию HitMap. Аргументы Владельца Продукта были очень сильными, и идея создать фиче-команды не вызвала заметного сопротивления. Все увидели, что кросс-функциональные кросс-компонентные фиче-команды потенциально предоставят компании максимальную гибкость и помогут создавать фичи с наивысшей ценностью из Бэклога Продукта. Потом мы попросили людей создать ограничения для формирования команды, и вот к чему они пришли:

• кросс-функциональная (все разработки, тестирование, DevOps и пр.);
• кросс-компонентная (все платформы — Windows, Android, Web);
• знание UI/UX;
• от 6 до 9 человек (желательно);
• расположение в одном офисе;
• мне ОК работать с этими людьми.

Я не буду подробно описывать процесс формирования команд — лучше прочитать о нём в статье Ахмада Фахми.

Хотелось бы подчеркнуть некоторые интересные моменты, с которыми мы столкнулись. Во-первых, членам пилотной команды разрешили присоединиться к другим командам, но никто этого не сделал. Во-вторых, после двух раундов (по 15 минут каждый) у нас образовались две стабильные команды, которые удовлетворяли всем требованиям, но в третьей команде не хватало специалистов по UI/UX. Мне пришлось организовать довольно длительное обсуждение, итоговыми решениями которого стали:

• кто-то из членов команды займётся изучением UI/UX;
• необходимо воспользоваться техникой координирования «Путешественник» (руководство «Путешественник»).

После воркшопа по формированию команд мы провели несколько упражнений:

• команды выбрали себе названия — «Alfa», «Vegas», «StarCraft» и «Circus»;
• сыграли в игру «Рынок компетенций»;
• заполнили таблицы компетенций для всех команд. Разработчики оценили свой уровень и указали, какие компетенции они хотели бы развить в команде.

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

Один из фундаментальных принципов LeSS — постоянное улучшение для достижения совершенства. Фреймворк LeSS позволяет бесконечно улучшать работу по созданию ценности для клиента. Например, для координации работы не предусмотрено дополнительных ролей. Если бы фреймворк включал их, какая у людей была бы мотивация к улучшениям сверх фреймворка, если всё уже входит в структуру? Цель LeSS — возможность проведения однокомандного Скрама для нескольких команд без необходимости вводить новые роли и правила.

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

Мой коллега Сезарио Рамоc дал мне пример видения совершенства одной организации. Я распечатал его и раздал всем участникам воркшопа в качестве ориентира. Мы попросили команды сформулировать их собственное видение совершенства, а через 20 минут записали все идеи на флипчарте и проголосовали.

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

Мы использовали определение готовности (DoD) пилотной фиче-команды в качестве ориентира, но все равно потратили какое-то время на разработку итогового варианта. Как это часто бывает, разработчики по-разному понимали терминологию тестирования (интеграционное тестирование, E2E-тестирование, функциональное тестирование, нагрузочное тестирование, тест производительности). К тому же их терминология была слишком сложной и запутанной. Поэтому я предложил упростить классификацию (эксперимент «Попробуйте простые классификации для тестирования!»). Это сработало. Пилотная фиче-команда решила использовать более практичную версию Критериев Готовности, которая соответствует правилам LeSS. Их список включал дополнительный код ревью и более строгие правила тестирования.