Читать книгу - "Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон"

Для Эрика настало время продемонстрировать свою компетентность.

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

К счастью, у Эрика была небольшая группа как раз таких людей. Это были заказчики и пользователи, с которыми он работал раньше, когда изучал проблему и подтверждал ее существование, – партнеры по разработке со стороны заказчиков. Именно они давали обратную связь по первым прототипам. Из этой группы Эрик выделил несколько человек, которые могли бы помочь в дальнейшем исследовании. Они должны первыми увидеть продукт – первую версию, меньше минимальной, определенно нежизнеспособную. Эрик надеялся, что они станут первыми испытателями.

И вот что сделал Эрик.

Здесь Эрик очерчивает часть существующего бэклога. Когда делалась эта фотография, программный продукт уже был предъявлен партнерам по разработке и Эрик назначил встречу для обсуждения обратной связи. Кроме того, команда добавила в продукт несколько простых метрик, чтобы можно было видеть, действительно ли люди используют программу и что именно они в ней делают.

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

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

Над тем, что находится в верхнем срезе, выше клейкой ленты, Эрик и команда работают прямо сейчас. Этот релиз займет у Эрика два спринта: они используют методологию Scrum, где спринт, как правило, составляет двухнедельный отрезок времени, так что два спринта равны примерно месяцу. Ниже на доске тоже есть несколько срезов. Следующий слайд, по мысли Эрика, содержит то, что должно выйти в следующем релизе, и т. д. Слева от каждого среза точно так же, как было в Globo.com, наклеен стикер с названием релиза и несколькими словами о том, что ребята хотят изучить в нем, – кроме самого верхнего: там был наклеен постер из мультфильма Dilbert – какая-то шутка, понятная членам команды, но неизвестная мне.

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

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

Теперь вы поняли, какие это умные ребята?