Эффективное управление содержанием проекта с помощью Agile User Stories

Для успешного выполнения проекта нам сначала нужно понять, что необходимо для достижения цели проекта, и спланировать, как это получить, а затем организовать все необходимые ресурсы. Чрезвычайно важно масштабировать работу с самого начала и
следить за тем, чтобы вся команда не сбивалась с пути все время.
Самый простой способ сделать это — определить объем проекта.

В inCode состав проекта (project scope) состоит из декомпозированных пользовательских историй. При работе над содержанием проекта мы предпринимаем два шага:

1. Истории пользователей (User Stories) и эпики
2. Декомпозиция пользовательских историй

Шаг 1. Пользовательские истории и эпики

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

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

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

Как писать пользовательские истории?

Каждая пользовательская история должна состоять из:

1. Определение пользователя
2. Предположения
3. Пограничные случаи
4. Критерии приемлемости
5. Ссылки на дизайн (если допустимо)

Заявление пользователя

Заявление пользователя состоит из 3 частей и описывает действие с точки зрения пользователя. Вот базовая структура пользовательского оператора с примером ниже:

Как ________________ пользователь, я должен иметь возможность ____________, чтобы я мог ____________
Как пользователь, я должен иметь возможность видеть контактную форму, чтобы я мог легко связаться с компанией и обсудить свои потребности

Предположения

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

• На каждой странице должна быть кнопка «Связаться с нами».
• Кнопка «Свяжитесь с нами» должна иметь фиксированное положение.
• Пользователь должен иметь возможность оставить сообщение через Telegram, WhatsApp, Facebook Messenger и электронную почту.

Пограничные случаи

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

Критерии приемки

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

Ссылки на дизайн

Ссылки на дизайн не являются неотъемлемой частью пользовательской истории и не включаются в нее большинством компаний. Однако включение ссылок на прототипы интерфейсов может сэкономить много времени в будущем. Изучение успешных примеров из отрасли также поможет вам .

Что такое пользовательские эпики

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

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

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

Шаг 2. Декомпозиция истории

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

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

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

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

Хотите получать больше полезной информации? Подпишитесь на наши Linkedin или Facebook, чтобы следить за обновлениями.