Книга: Пользовательские истории. Искусство гибкой разработки ПО
Назад: Глава 7. Как нужно рассказывать истории
Дальше: Шаблонные зомби и снегоочиститель
Классный шаблон Connextra
Это моя подруга Рэчел Дэвис. У нее в руках карточка историй.
В конце 1990-х Рэчел работала в компании под названием Connextra, которая была одним из первых адептов экстремального программирования, процесса Agile, откуда берут свое начало истории. Когда работники Connextra начали использовать истории, почти сразу обнаружились несколько распространенных проблем. Большинство людей, которые составляли в Connextra истории, работали в отделах продаж и маркетинга, поэтому они были склонны просто записывать функциональности, нужные пользователям. Но когда приходило время дискуссий между разработчиками, им приходилось искать того, кто предложил функциональность, и начинать настоящее обсуждение, включающее все «Для кого?» и «Почему?». Простая запись названия функциональности никак не помогала им понять, с какими людьми следует поговорить, или начать правильное обсуждение. Кроме того, в то время не было достаточного количества информации о том, что может или должно быть на карточках. Шаблон развивался в Connextra постепенно, с течением времени. Он был детищем не одной Рэчел, а скорее являлся следствием желания всей организации создавать по-настоящему значительные вещи.
Ребята из Connextra использовали этот шаблон некоторое время, а потом захотели поделиться своим замечательным изобретением с другими. Они напечатали стопку карт-образцов, которые продемонстрировали на XPDay 2001, небольшой конференции в Лондоне. На фотографии Рэчел держит именно такую карточку. Это последняя карточка из того набора и, возможно, последняя из существующих, поэтому ее можно назвать историческим памятником.
Вот как выглядит этот шаблон:
Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду].
Ребята из Connextra использовали этот простой шаблон для составления описаний своих историй. Они обнаружили, что написание этого небольшого дополнения перед началом изложения истории помогает им остановиться на минуту и сформулировать для себя: для кого, что, почему. И если выяснится, что данных недостаточно, составление истории оказывается под вопросом.
Когда приходит время начать обсуждение истории, ребята берут эти карточки и читают описания, которые дают отправную точку для дискуссии.
Используйте простой шаблон историй, чтобы открыть обсуждение.
Если у вас есть отдельная карточка, не принадлежащая карте историй, то шаблон – отличный способ завязать обсуждение. Помните, в главе 1 я упомянул одну из карточек в карте Гэри, где было написано: «Загрузить изображение»? Эта карточка была одной из деталей шага «Отредактировать рассылку». Я всегда пишу на карточках, составляющих карту, такие короткие глагольные фразы – они означают действия, которые люди выполняют, используя мой продукт. Но когда я рассматриваю какую-то карточку в отдельности, мне нужно увидеть историю внутри большого путешествия пользователя по продукту, которое представляет собой карта. Поэтому я могу сказать: «Как администратор музыкальной группы, я хочу загрузить изображение и отредактировать свою рассылку таким образом».
Это очень эффективный прием. Выше карты могут находиться листочки с действиями разных типов пользователей, а цель пользователя записывается на карточке, находящейся выше той, на которую вы смотрите в данный момент.
Но не забывайте, это только запуск обсуждения. Продолжиться оно должно примерно так.
• «Почему администратору группы может понадобиться отредактировать рассылку?»
• «Ну, наверное, потому, что на рассылке должно быть фото группы, а оно там не появляется автоматически. Кроме того, администратор, вероятно, хочет, чтобы его рассылка выделялась и привлекала внимание – кому интересны стандартные рекламки?»
• «Это звучит разумно. А где, как вы думаете, люди наподобие администраторов хранят такие фотографии?»
• «Да где угодно. Они могут быть на жестком диске компьютера, в аккаунте Flickr и вообще в любом месте в Интернете».
• «Да? Признаться, я об этом не думал, я предполагал, что они хранят их только на жестких дисках».
• «Нет, много людей, с которыми мы говорили, хранят фотографии в самых разных местах. Наверное, стоит это учесть».
Именно так и выглядели большинство моих дискуссий с Гэри. По мере обсуждения мы делали записи на доске или на самих карточках, а вскоре начали даже рисовать эскизы наших идей.
Как видите, этот короткий шаблон совершенно не годится для того, чтобы служить спецификацией. Но когда мы используем его, чтобы начать обсуждение, оно идет куда живее и активнее, чем если бы мы просто начали говорить о загрузке файлов.
Как вновь открыть для себя ценность коротких обсуждений
Мэт Кроппер, ThoughtWorksЯ работал в компании ThoughtWorks бизнес-аналитиком на проекте для правительственного агентства Великобритании. Мы несли ответственность не только за предъявление продукта, но и за обучение команды клиента некоторым практическим приемам методологии Agile. Это было не так-то просто, ведь у нас была большая команда – около 25 технологических или бизнес-специалистов. Представьте себе 25 человек в одной комнате, у каждого свои пожелания о режиме кондиционера, и вы поймете, в какой ситуации мы оказались.Мы с владельцем продукта договорились, что напишем истории, а потом в начале двухнедельной итерации вся команда соберется и распланирует разработку. В силу необходимости на этом совещании присутствовало очень много людей, что и привело к полному провалу.«Почему мы должны делать вот так?»«Эти истории слишком длинные/короткие».«В этом нет никакого смысла!»«Я настаиваю, чтобы техническая реализация данного аспекта выполнялась вот так и никак иначе».Это был долгий и утомительный спор. Честно признаюсь, уходя с совещания, я чувствовал себя ужасно и воспринял все происходившее как личное поражение.Однако следовало что-то предпринять, чтобы все исправить, и мы решили от одного общего совещания, где обсуждалось бы все и сразу, перейти к небольшим, более фокусированным обсуждениям. Например, на первой неделе итерации мы привели в порядок бэклог. Это сделала небольшая группа людей (владелец продукта, менеджер проекта, бизнес-аналитик и технический архитектор), которые выступали в роли пользователей различных историй. В результате, когда мы позднее формировали итоговый бэклог с участием всей команды, недоумения и недовольства было куда меньше. На этих встречах мы скорректировали и усовершенствовали наши истории, а, например, расстановку приоритетов и оценку сложности реализации проигнорировали. Это сработало.Мы также старались, чтобы процесс создания историй был более конструктивным. Если у меня возникали какие-то идеи по поводу истории, над которой я работал, я размещал их в верхней части доски с карточками в колонке «Анализ». Каждый день на совещании нашей команды я рассказывал о своей работе над конкретной историей и мог попросить кого-то из команды разработчиков уделить мне время. Мы садились и обсуждали, в каком направлении пойдет работа, как правило затрагивая технические аспекты, а затем записывали все это на бумаге. Мы не использовали Trello, где обычно хранилась наша доска с карточками в электронном виде, а вместо этого концентрировались на личных обсуждениях, иногда с помощью доски для записей. Работа в маленькой группе с глубоким погружением в детали очень полезна, а поскольку это обсуждение редко продолжалось больше 20 минут, оно никому не доставляло неудобств. Всем очень понравилось сотрудничать, содействуя общему делу.К счастью, огромные совещания по наполнению бэклога ушли в прошлое. Кроме того, мы обнаружили, что размер историй постепенно становится постоянным. В результате этого планирование итераций проходило куда легче, а обсуждения стали более активными. Соответственно, возросло качество документирования историй и качество всей нашей работы.
