В сфере бизнес-аналитики существует множество различных инструментов. Одним из них является User Story, помогающий специалистам описывать задачи и функции, которые необходимо реализовать на проекте.
Что такое User Story
На русский данный термин переводится как пользовательская история. С ее помощью можно взглянуть на функции продукта с точки зрения конечного пользователя. User Story не должна содержать излишних подробностей и большого количества технических деталей. Она пишется кратко и лаконично. Внимание акцентируется только на потребностях и целях пользователей.
Как правило, пользовательская история содержит:
- категорию пользователя;
- действие, которое ему необходимо совершить;
- ожидаемый результат.
Кроме этого история должна содержать определенные условия, при соблюдении которых она будет считаться выполненной. Предположим, компания занимается разработкой мобильного приложения для ветеринарной клиники. В этом случае пользовательская история может звучать следующим образом: «Хозяин домашнего питомца хочет иметь мобильное приложение, в котором можно записаться на прием, посмотреть историю посещений и назначений, а также увидеть результаты анализов и других исследований».
Зачем использовать User Stories в работе над проектами
Благодаря пользовательским историям разработчики могут увидеть ценность определенных функций, а также решить ряд задач.
Разделение требований на небольшие и понятные блоки
Чаще всего пользовательские истории содержат описание не всего продукта, а его отдельных компонентов и функций. Благодаря такому подходу решать объемные и сложные задачи становится проще. Возвращаясь к примеру с мобильным приложением для ветклиники, можно выделить следующие подзадачи:
- разработка удобной процедуры регистрации в приложении;
- разработка модуля для создания профиля животного, в котором можно указать возраст питомца, его породу, сделанные прививки и прочие сведения;
- добавление возможности оплаты услуг непосредственно через приложение.
Иными словами, здесь работает принцип декомпозиции. Любую сложную задачу намного проще реализовать, если разделить ее на небольшие блоки. После чего, каждый из них можно представить в формате пользовательской истории.
Упрощение оценки ресурсов
Если все требования описаны в рамках единой структуры, то сравнивать задачи между собой становится намного проще. Также это позволяет анализировать их сложность и время, необходимое для поиска оптимального решения.
Внесение ясности в процесс разработки
С помощью User Story разработчики могут более предметно обсуждать между собой вопросы, связанные с будущим продуктом. Как минимум, у них будет понимание того, для кого они это делают и зачем. Поскольку пользовательские истории написаны простым языком, их сможет понять даже сторонний специалист, не имеющий прямого отношения к техническим вопросам. Это улучшает взаимодействие между разными отделами, принимающими участие в реализации проекта.
Сильные и слабые стороны пользовательских историй
В первую очередь User Story ориентирована на конечных пользователей. Формирование базы знаний начинается с опросов и интервью. Таким образом разработчики быстро получают обратную связь. Пользователь рассказывает о своих потребностях и пожеланиях относительно определенного продукта.
Чаще всего пользовательские истории обсуждаются в команде. Это помогает сформулировать их таким образом, чтобы любой участник мог предложить свой вариант. User Story способствуют поэтапной разработке проекта. В них описываются функции, которые создаются и тестируются в рамках всего одной итерации. Именно поэтому данный инструмент часто используют команды, придерживающиеся методологии Agile.
Однако не нужно воспринимать пользовательские истории, как полноценную документацию. Если необходим соответствующий документ, User Story будет явно недостаточно. Они не отражают требования, предъявляемые к безопасности или производительности. Как правило в них не получится найти информацию, связанную с не функциональными особенностями проекта.
При этом User Story должны быть написаны так, чтобы в дальнейшем не возникало разночтений. Они могут появиться, если в тексте отсутствовали важные детали или они были описаны недостаточно точно. В итоге, это может привести к серьезным ошибкам в конечном продукте.
Как правильно составлять User Story
Стандартная пользовательская история содержит несколько частей. Каждая из них выполняет свою определенную функцию и имеет ряд особенностей, о которых нужно знать.
Основная часть User Story
Чаще всего, при ее написании используют шаблон. Работая с ним, специалист должен соблюдать два ключевых правила: всегда определять целевую аудиторию продукта и не перебарщивать с подробностями в описании.
Анализируя цель, важно понимать, что ею может быть не только задача, но и конкретная проблема, которую требуется решить. К примеру, специалисты ветеринарной клиники проанализировали пожелания клиентов, и пришли к выводу, что в приложении должна быть функция переноса или отмены записи ко врачу.
Что касается описания, то в нем должна быть только суть. Обилие лишней информации, которая не несет в себе никакой смысловой нагрузки, только сбивает разработчиков. В результате они могут не увидеть качественного решения поставленной проблемы и остановят свой выбор на менее эффективном. Чтобы подобного не происходило, следует выделять самое главное, то есть какая функция необходима и для чего.
Критерии INVEST
Обычно готовые User Story оцениваются согласно нескольким критериям правильности INVEST:
- independent – пользовательская история должна содержать описание одной или нескольких независимых друг от друга функций, которым предстоит решить конкретную пользовательскую задачу. При этом они не должны прибегать к помощи сторонних инструментов. Например, разработка личного кабинета не зависит от других опций приложения, поэтому данный процесс может быть протестирован и описан в рамках одной пользовательской истории;
- valuable – каждая функция, описываемая в формате пользовательской истории, должна быть полезна конечному пользователю. Не имеет никакого смысла описывать все имеющиеся функции, используемые на проекте;
- negotiable – все пользовательские истории должны пройти этап обсуждения внутри команды. Это необходимо для внесения последних правок и дополнений. Если данный процесс будет пропущен, разработчики могут получить информацию не в полной мере;
- small – название говорит само за себя, история должна быть небольшой и емкой. Чрезмерно обширные описания сложнее воспринимать;
- estimable – если пользовательская история сделана качественно, то по ней можно понять, как долго будет реализовываться функция и сколько ресурсов для этого потребуется;
- testable – наличие критерий приемки позволяет значительно упростить процесс создания функций. Тестирование историй также лучше проводить за один прием, именно поэтому в них стоит избавляться от всех лишних деталей.
Критерии приёмки и ограничения
Они добавляются ко всем пользовательским историям, независимо от их формата. Иными словами, это условия, без выполнения которых история не будет завершенной. Критерии приемки – это перечень требований, предъявляемых к системе. Они помогают разработчикам создавать необходимые функции.
Предположим, сотрудники ветеринарной клиники поняли, что было бы удобно заказывать в приложении медицинские препараты, который прописал врач. Данная пользовательская история может содержать следующие критерии приемки:
- пользователь переходит в соответствующий раздел и в строке поиска вводит название нужного препарата;
- приложение показывает доступные позиции и цены;
- в приложении хранится детальная история всех оформленных заказов, включая чеки.
Чаще всего в таком виде формулируется большинство критериев приемки для пользовательских историй. Существует несколько способов их описания. Подробность зависит исключительно от целей и потребностей разработчиков.
Что касается ограничений, то их задача состоит в демонстрации предела возможностей определенной истории. Проще говоря, они показывают, что можно реализовать в рамках функции, а что нельзя. К примеру, функция заказа медицинских препаратов может иметь следующие ограничения:
- оплатить заказ можно только безналичным расчетом;
- в приложении не работают карты, выпущенные иностранными банками.
Простые советы, которые помогут сделать пользовательскую историю лучше
Прежде всего не стоит забывать о преимуществах для пользователя. Довольно часто в пользовательских историях описывается исключительно функциональность, при этом совершенно непонятно для чего это нужно конечному пользователю. Без этого важного уточнения разработчикам будет очень трудно понять, зачем они создают конкретную функцию. Из-за этого может возникнуть недопонимание, которое в конечном итоге приведет к ухудшению конечного результата. Исправить ситуацию в этом случае будет очень сложно, поэтому лучше заранее все обдумать.
Как уже было сказано выше, не стоит создавать объемные и сложные User Story. Они требуют большого количества времени и ресурсов. Процесс разработки идет тяжело и долго. Если стоит задача создать личный кабинет, ее необходимо разбить на несколько подзадач. Также необходимо учесть возможные проблемы, с которыми может столкнуться пользователь. Например, добавить кнопку для быстрого обращения в техподдержку, в случае невозможности зайти в аккаунт.
Любые дополнительные детали указываются в критериях приемки. В главной части функции описываются в общих чертах, без упоминания дизайна и других второстепенных моментов.
Сразу следовать всем советам довольно сложно. Поэтому если на первых этапах что-то не получается – ничего страшного. Как и в любых других аспектах – ключевую роль играет опыт. Кроме этого важна насмотренность, без которой сделать качественную и продуманную User Story весьма трудно. Для начала стоит ориентироваться на критерии INVEST. Они помогут не забыть ничего важного и сохранить структуру в норме.
