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

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

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

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

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

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

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

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


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

Детали

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Предисловие

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

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

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

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

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

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


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

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


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

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


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


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

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

Оглавление книги


Генерация: 1.624. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз