Блог

LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)

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

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

Выбор Владельца Продукта

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

Создание Бэклога Продукта

Все требования находились в инструменте Redmine. Они состояли в основном из большого количества технических задач для компонентных команд, поскольку на них основывалась текущая организационная структура. Поэтому мы вооружились видением компании и среднесрочными целями, чтобы создать Бэклог Продукта с нуля.
Для этого мы использовали визуальный подход к управлению. Бэклог Продукта стал наглядным и конкретным — он был представлен в виде флипчартов и стикеров.
upload in progress, 0

Попробуйте проанализировать Бэклог Продукта с помощью HitMap!

Один из принципов LeSS — ориентация на клиента. Это означает, что организационная структура в первую очередь помогает создать наивысшую ценность для клиента. Мы не знали, смогут ли все фиче-команды создать её одновременно на пользовательских интерфейсах всех трёх платформ. Возможно, имело смысл сформировать команды в соответствии с сегментами клиентов. Мы хотели получить ответ с помощью HitMap. Это очень простой и надёжный инструмент. Он помогает увидеть архитектурные компоненты, которые используются в каждом элементе Бэклога Продукта. HitMap выглядит так:
upload in progress, 0
Цель совершенства — создать фиче-команды, которые смогут выбирать любой элемент из Бэклога Продукта и самостоятельно выпускать его на рынок по крайней мере один раз за Спринт. Допустим, нам нужны одинаковые фичи продукта для платформы как Android, так и iOS. Нам необходимо создать фиче-команды, чтобы в каждой были разработчики под iOS и Android.
Мы потратили пару часов на создание HitMap. В итоге у нас получилось несколько листов со стикерами. Когда мы закончили, Владельцу Продукта стало ясно, что ему нужны комплексные фиче-команды наподобие пилотной, чтобы достичь максимальной гибкости. Основные фичи продукта, которые он планировал разработать, были необходимы для всех трёх каналов (Web, Android, Windows).
upload in progress, 0

Воркшоп по формированию команд

После создания HitMap Владелец Продукта понял, что ему необходимы комплексные фиче-команды. Я помог ему организовать встречу, на которой он представил окончательную версию HitMap. Аргументы Владельца Продукта были очень сильными, и идея создать фиче-команды не вызвала заметного сопротивления. Все увидели, что кросс-функциональные кросс-компонентные фиче-команды потенциально предоставят компании максимальную гибкость и помогут создавать фичи с наивысшей ценностью из Бэклога Продукта. Потом мы попросили людей создать ограничения для формирования команды, и вот к чему они пришли:
  • кросс-функциональная (все разработки, тестирование, DevOps и пр.);
  • кросс-компонентная (все платформы — Windows, Android, Web);
  • знание UI/UX;
  • от 6 до 9 человек (желательно);
  • расположение в одном офисе;
  • мне ОК работать с этими людьми.
Я не буду подробно описывать процесс формирования команд — лучше прочитать о нём в статье Ахмада Фахми.
Хотелось бы подчеркнуть некоторые интересные моменты, с которыми мы столкнулись. Во-первых, членам пилотной команды разрешили присоединиться к другим командам, но никто этого не сделал. Во-вторых, после двух раундов (по 15 минут каждый) у нас образовались две стабильные команды, которые удовлетворяли всем требованиям, но в третьей команде не хватало специалистов по UI/UX. Мне пришлось организовать довольно длительное обсуждение, итоговыми решениями которого стали:
  • кто-то из членов команды займётся изучением UI/UX;
  • необходимо воспользоваться техникой координирования «Путешественник» (руководство «Путешественник»).
После воркшопа по формированию команд мы провели несколько упражнений:
  • команды выбрали себе названия — «Alfa», «Vegas», «StarCraft» и «Circus»;
  • сыграли в игру «Рынок компетенций»;
  • заполнили таблицы компетенций для всех команд. Разработчики оценили свой уровень и указали, какие компетенции они хотели бы развить в команде.
На следующее утро, когда я приехал в офис, разработчики уже переезжали из комнаты в комнату.
upload in progress, 0

Видение совершенства

Один из фундаментальных принципов LeSS — постоянное улучшение для достижения совершенства. Фреймворк LeSS позволяет бесконечно улучшать работу по созданию ценности для клиента. Например, для координации работы не предусмотрено дополнительных ролей. Если бы фреймворк включал их, какая у людей была бы мотивация к улучшениям сверх фреймворка, если всё уже входит в структуру? Цель LeSS — возможность проведения однокомандного Скрама для нескольких команд без необходимости вводить новые роли и правила.
Совершенство для производственной группы или организации — это состояние, которого никогда не получится достичь. Любой эксперимент по улучшению можно рассматривать в контексте видения совершенства.
Мой коллега Сезарио Рамоc дал мне пример видения совершенства одной организации. Я распечатал его и раздал всем участникам воркшопа в качестве ориентира. Мы попросили команды сформулировать их собственное видение совершенства, а через 20 минут записали все идеи на флипчарте и проголосовали.
После этого мы всегда обращались к видению совершенства при принятии решений на Ретроспективах. Например, однажды возникла идея создать специальную координирующую роль. Она шла вразрез с видением совершенства, и представители команд отвергли идею.
upload in progress, 0

Определение готовности (DoD)

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