Пользовательские истории. Искусство гибкой разработки ПО - [16]
«А что сейчас? – спросил я у Гэри. – У нас есть и другие пользователи, и решить они хотят другие задачи. Хочешь обсудить их? Только, по-моему, если мы будем продолжать, то нам потребуется другая комната, побольше. И еще, Гэри: даже на разработку всего вот этого уже понадобится куча денег. Мы можем обсудить и все остальное, но у нас уже есть довольно много. По-моему, даже если запустить продукт только с этой частью, он будет классным».
Гэри согласился: «Давай на этом остановимся».
В этой истории есть и грустный эпизод. Я знал, что разработчики, нанятые Гэри, уже сделали довольно много, поэтому спросил, соответствует ли хотя бы часть созданного ими программного обеспечения нашей карте.
«Почти ничего, – ответил Гэри, – потому что, когда я составил список функций и расставил их в порядке значимости, я был убежден, что мы должны начать с другого. Я думал о картине в целом, думал, что мне потребуются годы, чтобы реализовать ее. Но сейчас, после того, как мы все обсудили, я, конечно, начинал бы не с этого».
Самое важное в картах историй – это старое доброе обсуждение, а затем его изложение в форме карты. Обычно в центре внимания находится карта – последовательное, слева направо, изложение шагов, с помощью которых можно рассказать историю. Детали шагов располагаются сверху вниз. Но самое важное, что формирует продукт и дает больше всего контекста, обычно находится вне карты – это цели продукта, информация о заказчиках и пользователях. Если ваша карта располагается на стене, то будет очень хорошо разместить рядом с ней эскизы пользовательского интерфейса (UI) и другие заметки.
Всего за день совместной работы мы с Гэри пришли к одинаковому пониманию продукта, который он хотел создать. Правда, над нашими головами уже собирались тучи, и мы оба их прекрасно видели: каждая карточка заключала в себе множество деталей и требовала длительного обсуждения. А с точки зрения Гэри, все эти детали и обсуждение требовали денег на разработку программного обеспечения – денег, которых у него не было. Он получил один из самых фундаментальных уроков, которые дает разработка программ: времени на создание всего, что нужно, никогда не бывает достаточно.
Кроме того, Гэри предположил, что еще многие люди могли бы работать с его продуктом, если бы действительно хотели или были способны использовать его так, как он представлял. Но сейчас его беспокоило не это. В первую очередь нужно было хорошо поработать, чтобы сузить идею продукта до чего-то реалистичного и осязаемого.
В конце концов история Гэри завершилась благополучно. Но в следующей главе я расскажу о другой организации, которая тоже пыталась взять на себя больше, чем могла, а затем использовала карту историй, чтобы найти жизнеспособное решение.
Сиди (Клэр) Дойл, менеджер продуктов и тренер Agile (Assurity Ltd, Веллингтон, Новая Зеландия)
Предисловие
The Learning Connexion (TLC) – колледж искусств в Веллингтоне, Новая Зеландия. Там изучают искусство и творчество. Программы TLC уникальны, так как они основаны на обучении действием, то есть изучении теории одновременно с практикой. Под руководством преподавателей студенты трудятся над работами на темы, которые сами выбрали для исследования.
TLC был типичной небольшой организацией, которая разрабатывала IT-системы по мере надобности, чтобы обеспечивать нужды, возникающие в определенный момент. Информация для студентов, например, располагалась в пяти разных местах и в каждом из них отличалась от хранящейся в других! TLC очень нужен был какой-то способ руководить студентами, которые будут здесь заниматься, поддерживающий кардинально иной принцип обучения, чем в большинстве образовательных учреждений.
У сотрудников TLC не было никакого опыта работы с IT-проектами. Все маленькие приложения, применяемые в колледже, когда-то были написаны чьими-то братьями, друзьями, соседями с использованием простых технологий вроде Microsoft Excel или Access. Единственное коммерческое приложение, используемое для составления официальных отчетов, повторно обрабатывало данные из других четырех источников.
Как бывшая студентка, я поддерживала контакты с сотрудниками колледжа, и поэтому, когда им понадобилась помощь, они обратились ко мне. К 2009 году я имела девятилетний опыт работы в IT, а в последние три года, с того самого момента, как впервые услышала о методологии Agile, мечтала сделать какой-нибудь проект, применив ее. И вот наконец звезды сошлись: правильное место, правильный проект и правильный момент, чтобы осуществить мечту!
Проект «Феникс»
Изначально были запланированы два заседания длительностью в полдня с участием наиболее значимых лиц из числа сотрудников колледжа. Я работала с большой разношерстной группой, поэтому первым делом хотела добиться одинакового понимания. Начала с обзора метода составления карт историй, а также выявления основных шагов в процессе руководства студентами колледжа.
До того как я показала членам команды картинку (основу карты историй), каждый из них имел собственное представление о том, что
