User story – инструмент разработчиков и система координации проектов

13.05.2018 Категория: Управление проектами Просмотров: 41 Комментариев:

User stories — это одна из методологий описания требований к разрабатываемому IT-проекту. Составляется user story командной разработчиков, в которой желательно наличие проектного менеджера и тестировщика, осуществляющего конечную проверку и анализ выполненного веб-продукта. Пользовательские истории составляются на понятном для пользователя и разработчиков языке, не включая в себя сложные технологические термины. User stories ограничены в объемах и в сложности. Поэтому на практике их часто составляют на небольшом листке бумаги.

Для чего используют пользовательские истории в IT-сфере

User stories предназначены для корректного, информативного и объективного описания пожеланий и требований клиента в отношении того или иного проекта. Это позволяет сэкономить время на составление плана и структуры работы команды разработчиков.

Пишутся пользовательские истории по-русски, по четко отлаженной структуре, состоящей из трех пунктов:

  1. Ситуация (описание представителя целевой аудитории).
  2. Действие (действие ЦА в приложении или в другом типе веб-продукта).
  3. Цели (назначение пользователя для ПО или наоборот).

Исходя из этой информации можно выделить следующие особенности пользовательских историй:

  • user stories позволяют сделать наброски по проекту еще до составления полноценного технического задания;
  • истории создаются всей исполнительной командой, поэтому коллективная работа позволяет сразу определить возможные недостатки в проекте;
  • истории содержат примерный сценарий поведения пользователя с веб-продуктом, который необходим для качественного тестирования.

Многие заблуждаются, считая, что записки (истории) являются аналогом ТЗ и одним из этих элементов можно пожертвовать при подготовке к созданию IT-проекта.

Примеры user stories отображают реальное назначение, которое заключается в формировании правильного виденья проекта для разработчика со стороны пользователя. Техническое задание — это не аналог пользовательских историй, так как в нем содержится более строгая терминология.

Как правильно составляется user story

Чтобы лучше оценить описываемый формат, предлагаем пример user story, написанной для создания мобильного приложения:

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

В примере описана история пользователя для приложения городской службы такси. Именно на основании простых предложений можно понять, на что сделать уклон в пользовательском интерфейсе. Такой пример описания user story показывает структуру, где нужно изобразить ЦА, пожелание и мотивацию.

Переде тем, как писать user story, стоит ознакомиться с факторами, на основании которых эти истории составляются:

  • лучше написать не 1, а больше записок к одному проекту (точное чисто не регламентируется);
  • так как story — это мозговой штурм, они составляются не по шаблону (существуют лишь описанные выше критерии);
  • в среднем, одна история должна затрагивать до четырех рабочих дней команды разработчиков (соответственно, если команда работает 40 дней, то нужно составить от 10 записок);
  • в записках составляются критерии приемки для тестировщиков.

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

Пользовательские истории как мощный инструмент команды разработчиков

User story mapping входит в перечень инструментов, используемых профессиональными разработчиками и проектными менеджерами. В частности, компания TZ Profi активно применяет эту методику в реализации практически всех IT-проектов.

Так называемый «mapping» является собой карту, построенную на сформированных записках (историях). Они структурируются по дате или по важности. Соответственно, это упрощает процесс разработки, позволяя видеть важные моменты от ЦА на каждом этапе разработки. Как только соберется необходимое количество историй, формируется полноценный Backlog. Он и является основание для старта проекта.

Актуальным является также сравнение пользовательских историй и сценариев (так называемые cases). Отличия use и case user story заключаются в том, что сценарии всегда прописывают функциональную часть задачи и только ее. А вот истории могут касаться элементов веб-дизайна, оформления, взаимодействия приложения с другим ПО. «Examples» пользовательских сценариев позволяют оценить их эффективность для ряда технологически сложных задач. Например, легко при помощи такого сценария описать импорт данных из одной файловой системы в другую. Но вот структурировать пожелания по мобильному приложению лучше все же через user story.

Высокое качество услуги от специалистов TZ Profi

Составление и ведение пользовательских историй должно вестись профессиональной командой, которая занимается реализацией самого проекта. Компания TZ Profi специализируется на предоставлении ряда IT-услуг, среди которых и непосредственное составление пользовательских stories с применением гибкой методологии Agile (в нее же входят Scrum, Канбан, ХР, Lean).

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

  • «Для чего создается этот веб-продукт?»;
  • «Нужна ли эта функция мне, как потенциальному пользователю?»;
  • «Кто кроме меня будет пользоваться веб-продуктом или конкретной функцией?».

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

Реализация каждого IT-проекта становится для команды TZ Profi новой возможностью проявить собственные умения и навыки, улучшив опыт работы в локальных или международных проектах. Многие используемые идеи подчеркнуты с известных методологий, прописанных в базовых книгах по пользовательским историям: «User Stories Applied» и «Four Steps to the Epiphany». Соответствие модели INVEST каждой story — еще один залог успеха реализации задуманных идей.

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

Оставить комментарий