ЗефиркииобучениевСкраме

Томас Эдисон и лампочки. Не так давно мы разбирались в таком тонком вопросе, что же такое неудачный Спринт. Я часто замечаю, что, несмотря на кажущуюся простоту Скрама, много его базовых концепций воспринимается неверно. Одно из часто встречающихся заблуждений:

Когда Цель Спринта не достигнута, Спринт считается неудачным.

Когда я слышу это определение, то сразу вспоминаю Томаса Эдисона и его 10 000 экспериментов с лампочкой. Эдисон рассматривал каждый неудачный опыт как устранение очередного неработоспособного решения, которое продвигало его все ближе к успеху. В действительности 9 999 «неудачных» опытов были необходимым условием на пути к конечному результату.
  
Посмотрим на самое первое описание Скрама 1995 года:

Спринты нелинейные и гибкие. По возможности используются явные знания, в противном случае мы пользуемся методом проб и ошибок. Спринты созданы для того, чтобы придти к конечному продукту (Ken Schwaber, SCRUM Development Process).

Давайте еще раз вспомним ключевые выводы:

• Каждый Спринт – эксперимент, который помогает нам приблизиться к конечному продукту.
• Чистота эксперимента определяется тремя составляющими: Инспекцией, Адаптацией и Прозрачностью.
• Неудачным можно считать Спринт, в конце которого мы ничему не научились. Прозрачные результаты не инспектировались, не была проведена адаптация продукта (Беклога) и процессов.

Вернемся к Томасу Эдисону. В каком случае тысячи экспериментов, которые он провел, можно было бы считать неудачными? Наверное, если бы Томас каждый раз забывал фиксировать, какой материал для нити накаливания он использовал (отсутствие адаптации), либо же каждый раз проводил эксперимент в различных условиях (отсутствие прозрачности).

Дисциплинированное обучение. Разрабатывая новый продукт, мы встречаем большое количество неопределенностей. Перечислим некоторые из них:

• Как будет выглядеть конечный продукт?
• Какую проблемы мы решаем?
• Как масштабировать продукт?
• Кто наш клиент?
• Цена разработки?
• Сможет ли команда эффективно работать?
• Верны ли наши технологические предположения?

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

Очевидно, что в Скраме для нас единицей эксперимента является Спринт.

MVP и плата за знания. К сожалению, в этом мире за все нужно платить, в том числе и за знания, которые мы получаем. И будет действительно горько, если мы будем проходить Спринт за Спринтом, сжигая деньги инвесторов впустую. Подтвердить предположения можно получить, создав Minimum Viable Product (MVP) или Minimum Viable Solution (MVS). Существует несколько определений MVP, но мне нравится формулировка Эрика Риса:

Minimum Viable Product – нечто минимальное, что может подтвердить или опровергнуть наше предположение.

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

Кто построит самую высокую башню? Задачка с зефиром – одна из самых известных и популярных игр, обошедшая все страны и континенты. Игра, в которую играли дети и взрослые, представители различных профессий и индустрий. Цель упражнения очень проста – необходимо за 18 минут построить как можно более высокую конструкцию, на вершине которой будет зефирка. Правда, строительные материалы не совсем обычные. Для каждой команды нужно собрать набор, в котором находятся:

• Метр бечевки
• Метр скотча
• Ножницы
• Зефирка (можно заменить мармеладом, но лучше использовать оригинальный Marshmallow весом около 7.5 грамм)
• 20 спагетти

Вывешиваем на флип-чарте правила игры и подробно объясняем их участникам. При необходимости проходим по ним несколько раз.


Запускаем таймер и наблюдаем. Я проводил игру множество раз, и поэтому могу дать несколько советов:

•   Нужен большой и заметный таймер, на который будут смотреть команды.
•   В течение 18 минут не будьте просто пассивным наблюдателем. Наоборот, активно наблюдайте за действиями команд. Ходите между ними и делайте пометки. Лично я люблю формат «время, команда, действие». Затем эти записи послужат важным материалом для обсуждения.

Помним, что

Ценность игры для участников пропорционально качеству проведенного обсуждения после нее.

Задачка с зефиркой уникальна тем, что из нее Скрам Мастеру можно «вытянуть» много разных концепций:

Timebox. Что вы чувствовали? Как отразилось на вас лично и на команде жесткое ограничение по времени? Подстегивал ли вас timebox?

Командная работа и самоорганизация. Команде были поставлены определенные рамки (ресурсы, время, конечная цель). Произошла ли самоорганизация внутри? Что вы при этом заметили? Как распределились роли внутри команды? Появился ли явный лидер? Если нет, то как вы принимали решения?

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

Категория первая. Сразу после начала игры начинается бурное обсуждение.  Кто-то рисует схему на бумаге, а кто-то вспоминает забытые формулы из курсов сопротивления материалов или теоретической механики. На бумаге появляется план, который затем обсуждается и улучшается в течение первых 13-15 минут. Потом приходит понимание того, что время уходит, а ничего еще не сделано. В последние секунды на еле стоящую от напряжения конструкцию, сверху насаживается зефирка, и все неожиданно распадается.
Происходит «big-bang integration & deployment», когда мы получаем знания лишь в самом конце.

Предположения не были проверены и обратная связь была получена слишком поздно.

Категория вторая. После начала игры ребята сразу начинают экспериментировать и пробовать ограничения полученных материалов. Они проверяют на прочность и упругость спагетти, часто ломая некоторые из них. Иногда команды сразу насаживают на спагетти зефирку. Цель подобных экспериментов – подтвердить или опровергнуть предположения, чтобы получить необходимый опыт. Часто уже в течение первых 5-7 минут игры командам удается получить первую рабочую конструкцию. Оставшееся время они тратят, пытаясь улучшить полученный результат. Если не получается, то в последние минуты команда имеет возможность «откатиться» на рабочее решение. Процесс получения знаний выглядит в этом случае так:

Вначале мы вынуждены платить за то, что учимся и получаем знания. Когда после нескольких неудачных попыток (а с первого раза редко, что получается) мы приходим к рабочему решению, дальше мы его расширяем, а в конце «полируем», если остается время.

Если мы признаем, что нашей целью является получение знаний, тогда мы должны стремиться минимизировать объем выполненной работы для поставки. Мы должны фокусироваться на том, что помогает нам учиться. Если делать это умело, то это может значить, что на выходе может быть не “production ready” продукт. Даже наоборот, если первая поставка “production ready”, то это может значить, что вы, скорее всего, проделали лишнюю работу (Jeff Patton, User Story Mapping).

Тяжело для взрослых и легко для детей. Вы можете по этой ссылке посмотреть один из самых популярных Ted Talk (более 2 млн. просмотров), где Том Войец представляет удивительное и глубокое исследование задачки с зефиркой. В одном из эпизодов он рассказывает о том, что по статистике наихудшие результаты показывают выпускники MBA, а наилучшие – дети.

И это неудивительно. Хочется еще раз вспомнить Томаса Эдисона, который ходил в школу три месяца, после чего был назван учителем «безмозглым». Эдисон получил только домашнее образование от матери. Как в известной фразе о том, что по законам аэродинамики шмель не может летать, Эдисон предпочитал не знать мнения экспертов о том, что что-то невозможно.

Назад к Скраму. Рассмотренные концепции являются продуктовыми и замечательно, если Владелец Продукта умело владеет ими, но, к сожалению, это редкость. С другой стороны, одна из обязанностей Скрам Мастера – обучение Владельца Продукта эффективным техникам управления Беклогом Продукта. Давайте перечислим, что может сделать Скрам Мастер:

• Убедиться, что Обзор Спринта и Ретроспектива состоялись.
• Донести до Владельца Продукта необходимость присутствия конечных пользователей продукта на Обзоре Спринта. Это ключевая активность, которая поможет нам ответить на вопрос «Как будет выглядеть продукт?». По возможности, давайте поиграться продуктом пользователям. Вместе с Владельцем Продукта и Командой Разработки наблюдайте за ними. Гарантирую, вы увидите много интересного.
• Скрам Мастер должен обучить участников Обзора Спринта тому, что это нейтральная встреча. Спринт не может быть удачным или неудачным, он просто показывает вам то, на что вы способны.
• Обучить Владельца Продукта эффективным техникам управления Беклогом Продукта, например, User Story Mapping. Она помогает эффективно «разрезать» требования на слои, уходить от плоского Беклога и видеть целостную картину.
• Помочь Владельцу Продукта и Команде Разработке провести идентификацию ключевых рисков и последовательно исключать их. Полезно создать Risk Burndown Chart, который будет показывать, насколько быстро мы от них избавляемся.
• Через 3-4 Спринта, имея эмпирическую информацию (велосити), помочь Владельцу Продукта провести планирование релиза. Таким образом, мы сможем ответить на вопрос «Сколько это будет стоить?». Будьте готовы к тому, что полученный результат будет неудовлетворительным по одной простой причине: ЖЕЛАНИЯ ВСЕГДА ПРЕВОСХОДЯТ НАШИ ВОЗМОЖНОСТИ. Это аксиома в индустрии разработки программного обеспечения, поэтому относитесь к этому философски. Поверьте, если ваша команде начнет «пилить» код в два раза быстрее – скорости все равно будет недостаточно. Появятся новые «хотелки» со стороны заинтересованных лиц. Поэтому советую фокусироваться не на увеличении продуктивности команды, а на том, чтобы было как можно меньше лишней работы. Не забываем, что по статистке более 60% функционала никогда не используется или используется пользователями редко.
• В современном мире окно возможностей для выхода в первый публичный релиз для нового продукта составляет 3-5 месяцев. Если этого не происходит, то риски возрастают экспоненциально. Работаем с Владельцем Продукта в этом направлении.

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

Scrum On!