Текст книги "Пользовательские истории. Искусство гибкой разработки ПО"

Гэри Левитт и плоский бэклог

Несколько лет назад я познакомился с Гэри Левиттом. Гэри был бизнесменом и как раз запускал новый веб-продукт. Этот продукт и сейчас работает, он называется Mad Mimi, что согласно задумке Гэри означало «маркетинговый интерфейс музыкальной индустрии»[6]6
  Mad Mimi, или Music Industry Marketing Interface. – Примеч. пер.


[Закрыть]. Гэри музыкант, и у него есть собственная группа. Он самостоятельно занимался административными делами, а кроме того, помогал управляться с ними и другим, работал в музыкальной студии и делал записи для клиентов.

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

Гэри нужно было, чтобы кто-то разработал этот продукт, поэтому он сотрудничал с другим человеком, и этот другой человек работал в Agile. Он попросил Гэри написать список всего, что он хотел бы видеть в продукте, и расставить элементы списка по важности. Затем они бы обсудили верхние, самые важные элементы и начали создавать их один за другим. В Agile такой список функций обычно называется бэклогом, и, по мнению Гэри, было вполне разумно так и поступить: составить список и начать с самых важных вещей. Так он и сделал.

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

Я был знаком с человеком, работавшим с Гэри. Мой друг видел, что Гэри вне себя от беспокойства, и очень хотел ему помочь. Кто-то из наших общих знакомых спросил меня, не хочу ли я поговорить с Гэри и помочь ему организовать его идеи. Мы познакомились и договорились встретиться в его офисе на Манхэттене.

Говорите и пишите

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

Говорите и пишите: записывайте тезисы на карточках или стикерах, чтобы зафиксировать свои мысли по мере того, как рассказываете истории.

Мы начали раскладывать карточки на письменном столе, но очень скоро место на нем закончилось. Во время моего визита Гэри занимался переездом в другой офис и большая часть мебели уже находилась в лофте в Нью-Йорке. Так что мы недолго думая перенесли разросшуюся карту пользовательских историй прямо на пол.

Вот как в конце дня выглядел пол.

Мысль – запись – объяснение – место

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

Выработайте привычку кратко записывать свою мысль перед тем, как ее озвучить.

1. Если вы используете карточки или стикеры, запишите на них несколько слов об идее, как только она придет в голову.

2. Расскажите о своей идее остальным, как только запишете ее на стикер или карточку. Объясняйте подробно и доходчиво. Рисуйте много картинок. Рассказывайте истории.

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

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

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

Оформите свою идею

Предметом первого обсуждения стала сама идея продукта. Мы говорили о бизнесе Гэри и его целях. Зачем вы это создаете? Сформулируйте, какие преимущества даст этот продукт вам и другим людям, которые будут его использовать. Какие задачи он будет решать для этих людей и для вас? Читая это, вы, наверное, догадались, что я думал о модели «до и после». Я пытался понять, какие результаты хочет получить Гэри, а не какую работу он планирует проделать.

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

Опишите своих пользователей и заказчиков

Мы с Гэри продолжили обсуждение. Следующей темой разговора стали заказчики, которые купят продукт, и пользователи, которые будут непосредственно с ним работать. Мы перечислили различные типы пользователей. Обсудили преимущества, которые они получат, задались вопросом, почему они будут использовать продукт, а также что, как мы предполагаем, будут с ним делать. Что продукт должен включать в себя с точки зрения пользователей? Ответы записали на целую груду бумажек. Карточки, на которых были указаны наиболее важные пользователи, сами оказались на верхних позициях. Забавно, что иногда это работает и таким образом – без явного намерения.

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

Гэри выбрал одну, и после этого мы наконец приступили к составлению историй.

Типы пользователей в Mad Mimi

Вот разные пользователи Mad Mimi, которых описал Гэри. Уже простое перечисление их типов и краткие списки задач помогли понять, что тут многовато всего. Даже не начав обсуждать функциональность, мы решили отложить разработку для некоторых типов пользователей.

Изложите свои истории

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

И мы составили историю, расположив ее на полу справа налево. Иногда возвращались назад и вставляли какие-то элементы в середину, ведь карточки, на которых изложены идеи, очень легко перемещать.

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

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

По мере того как мы говорим и пишем, а я фиксирую обсуждение, мы создаем нечто по-настоящему важное. Нет, не просто множество карточек на полу. А то, что по-настоящему важно, – единое понимание! Мы находимся, так сказать, на одной волне. У Гэри никогда не было такого взаимопонимания по поводу идеи своего продукта ни с кем другим, во всяком случае, не на таком уровне детализации. Даже он сам никогда не обдумывал продукт так углубленно. Он представлял лишь ключевые моменты, что-то вроде фрагментов основных сцен фильма, которые показывают в трейлерах.

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

Составление карты пользовательских историй поможет вам обнаружить пробелы в ней.

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

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

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

Гэри жил в Нью-Йорке и при обсуждении листовок представлял себе все те крутые штуки, которые постоянно видел на стенах и фонарных столбах города. Одни выглядели так, словно кто-то склеил вместе текст и журнальные фотографии, а потом размножил полученное на ксероксе, но другие и в самом деле смотрелись эстетично и элегантно. Записав какое-то количество деталей, я предложил Гэри оставить их в покое, чтобы вернуться к ним позже, а сейчас продолжить обсуждение истории и продвинуть ее дальше. Утонуть в деталях очень легко, особенно если вам очень интересен предмет обсуждения. Но когда нужно получить общую картину, очень важно добраться до конца истории, прежде чем погружаться в мелочи. Еще одна мантра, которую я использую при работе с историями: «Мысли на милю вперед и на дюйм вглубь». Для тех, кому привычнее метрическая система: «На километр вперед и на сантиметр вглубь». Дойдите до конца истории, прежде чем тонуть в деталях.

Сосредоточьтесь на протяженности истории, прежде чем погружаться в ее глубину.

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

«А сейчас, – сказал я, – давай вернемся назад, проработаем детали, а также рассмотрим некоторые альтернативы».

Основная история Mimi

Просмотрев карту Гэри, вы можете заметить такие основные действия, как:

• регистрация;

• изменение набора сервисов;

• просмотр статистики моей группы;

• работа с календарем концертов;

• работа с аудиторией;

• публикация анонсов шоу;

• подписка на рассылку группы;

• просмотр предложений онлайн.

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

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

• запустить рекламу представления;

• просмотреть автоматически созданную Mimi рекламную рассылку;

• отредактировать рекламную рассылку;

• проверить созданную рассылку.

Обратите внимание на то, как ясно короткие глагольные фразы, написанные на карточках, говорят, что хочет сделать определенный тип пользователя. Такие формулировки облегчают воссоздание цельной последовательной истории: «Теперь администратор группы хочет опубликовать анонс о представлении. Чтобы сделать это, он должен запустить рекламу представления, затем просмотреть автоматически созданную Mimi рассылку, затем отредактировать ее, потом…» Достаточно просто вставить «а потом» в промежутке между двумя карточками, чтобы получить связную историю.

Займемся вариантами и деталями

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

• В чем особенности действий пользователя на данном этапе?

• Какие альтернативные вещи они могут сделать?

• Как можно сделать этот этап по-настоящему крутым?

• Как исправить ситуацию, если что-то пойдет не так?

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

Детали

Если бы вы заглянули в историю шага, например, «Отредактировать рассылку», то увидели бы такие детали:

• загрузить изображение;

• прикрепить аудиофайл;

• разместить видео;

• добавить текст;

• изменить разметку;

• использовать ранее созданную рассылку как шаблон.

Как видите, для проработки всех подробностей даже этих меньших шагов требуется дополнительное долгое обсуждение. Но начать мы можем с простого их перечисления.

Заметьте, что и на этих карточках использованы простые глагольные фразы, которые облегчают изложение историй. Мы можем составить из этих карточек историю, применяя связку «или он может», например, вот так: «Чтобы отредактировать рассылку, он может прикрепить аудиофайл, или добавить видео, или…» Очень удобно!

«А что сейчас? – спросил я у Гэри. – У нас есть и другие пользователи, и решить они хотят другие задачи. Хочешь обсудить их? Только, по-моему, если мы будем продолжать, то нам потребуется другая комната, побольше. И еще, Гэри: даже на разработку всего вот этого уже понадобится куча денег. Мы можем обсудить и все остальное, но у нас уже есть довольно много. По-моему, даже если запустить продукт только с этой частью, он будет классным».

Гэри согласился: «Давай на этом остановимся».

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

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

Самое важное в картах историй – это старое доброе обсуждение, а затем его изложение в форме карты. Обычно в центре внимания находится карта – последовательное, слева направо, изложение шагов, с помощью которых можно рассказать историю. Детали шагов располагаются сверху вниз. Но самое важное, что формирует продукт и дает больше всего контекста, обычно находится вне карты – это цели продукта, информация о заказчиках и пользователях. Если ваша карта располагается на стене, то будет очень хорошо разместить рядом с ней эскизы пользовательского интерфейса (UI) и другие заметки.

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

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

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

Артджайл – творчество в искусстве встречается с творчеством в IT

Сиди (Клэр) Дойл, менеджер продуктов и тренер Agile (Assurity Ltd, Веллингтон, Новая Зеландия)

Предисловие

The Learning Connexion (TLC) – колледж искусств в Веллингтоне, Новая Зеландия. Там изучают искусство и творчество. Программы TLC уникальны, так как они основаны на обучении действием, то есть изучении теории одновременно с практикой. Под руководством преподавателей студенты трудятся над работами на темы, которые сами выбрали для исследования.

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

У сотрудников TLC не было никакого опыта работы с IT-проектами. Все маленькие приложения, применяемые в колледже, когда-то были написаны чьими-то братьями, друзьями, соседями с использованием простых технологий вроде Microsoft Excel или Access. Единственное коммерческое приложение, используемое для составления официальных отчетов, повторно обрабатывало данные из других четырех источников.

Как бывшая студентка, я поддерживала контакты с сотрудниками колледжа, и поэтому, когда им понадобилась помощь, они обратились ко мне. К 2009 году я имела девятилетний опыт работы в IT, а в последние три года, с того самого момента, как впервые услышала о методологии Agile, мечтала сделать какой-нибудь проект, применив ее. И вот наконец звезды сошлись: правильное место, правильный проект и правильный момент, чтобы осуществить мечту!

Проект «Феникс»

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

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

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

Нам повезло, что на заседании собрались творческие люди, привычные к методу позитивного исследования[7]7
  Позитивное исследование (appreciative enquiry) – модель организации изменений, в которой участники фокусируются не только на том, что плохо, что не работает, что нужно изменить (как это принято в традиционном методе решения проблем – problem solving), но и на том, что достигнуто, что хорошо в настоящем благодаря действиям в прошлом. Иначе говоря, здесь ценят интересы не только новаторов, но и консерваторов. – Примеч. пер.


[Закрыть], поэтому обмен мыслями о том, что должна делать система, был для них обычным процессом.

Согласно диаграмме, основными этапами процесса были Запрос – > Допуск – > Вступительные экзамены – > Классы – > Итоговая работа – > Завершение – > Выпуск.

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

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

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