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

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

Вот что мы обсудим:

Начало Agile

Вероятно, вы слышали о Agile-разработке и пользовательских историях. Но если нет, давайте проведем краткий урок по истории:

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

Методологии Agile существуют с 2001 года, когда 17 уважаемых инженеров-программистов встретились на горнолыжном курорте в Юте и создали теперь уже печально известную Манифест Agile.

Если имена таких людей, как Роберт Мартин, Мартин Фаулер и Кент Бек, вам ничего не говорят, по окончании этой статьи идите и изучайте их. У них огромные знания, и благодаря им миру программного обеспечения был предоставлен более гибкий способ доставки проектов, называемый Agile.

Что такое Agile?

Agile — это скорее способ мышления, чем прописанный метод. Существуют прописанные методы, такие как Scrum и Kanban, но Agile — это концепция.

Agile поощряет сотрудничество, быструю обратную связь и постоянное предоставление ценности пользователю.

Способ мышления Agile поощряет гибкость в планировании проекта, что резко контрастирует с его конкурентом на тот момент — планированием проекта Waterfall, которое было очень жестким в отношении того, что и когда должно быть доставлено.

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

Гибкая методология продвигает быструю и частую доставку чего-то ценного, обычно в виде доставки кода в продукцию в конце каждых двухнедельных “спринтов”. Это, в свою очередь, сильно отличается от традиционного водопадного планирования, которое часто требует месяцев разработки, прежде чем какое-либо изменение, видимое пользователю, может быть доставлено в продукцию.

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

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

Представляем Пользовательскую Историю.

Что такое Пользовательская История?

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

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

Структура Пользовательской Истории

Как [тип пользователя], когда я [выполняю действие], [ожидаемый результат]

В своей самой базовой форме, это и есть все.

Вы делаете акцент на конечном пользователе и “ценности”, которую вы предоставите.

Давайте углубимся в входные данные:

  • Тип пользователя: Нет универсального “пользователя”. У вас есть “администраторы”, у вас есть “авторизованные пользователи”, у вас есть “пользователи с разрешением X” или “пользователи в роли Y”. Это конкретизация того, кто выполняет действие

  • Выполнить действие: Что делает пользователь? Нажимает кнопку “войти”? Удаляет запись? Отправляет форму?

  • Ожидаемый результат: Как только ваш пользователь выполнил действие, что должно произойти? Если они нажали “войти” с правильным адресом электронной почты и паролем, куда они должны быть направлены? Если они нажали “войти” с неправильным адресом электронной почты и паролем, что должно произойти?

Пример пользовательских историй:

Давайте рассмотрим примеры пользовательских историй для страницы входа.

Ничто не сравнится с примерами.

Давайте создадим ситуацию. У вас есть страница входа с полем для ввода адреса электронной почты и полем для ввода пароля. У вас есть кнопка отправки. Вот и все.

Какие различные варианты могут произойти на этой странице с точки зрения пользователя?

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

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

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

Я пользователь, который еще не вошел в систему, и я ввел неверные данные. Я не должен быть авторизован.

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

Снова. Я не вошедший пользователь. Я ввел неверные данные, я не должен быть авторизован.

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

На этот раз я еще не вошел в систему, я ввожу правильные данные и нажимаю Войти. Я вошел в систему.

Вы видите, как все это сосредоточено на пользователе?

Вы можете заметить, что некоторые из «ожидаемого поведения» выше не полностью определены. Мы рассмотрим это позже в критериях приемки.

Как создать хорошие Пользовательские истории

Существует хорошая модель, называемая моделью INVEST, которая очень просто показывает, как узнать, являются ли ваши пользовательские истории хорошими.

Модель INVEST:

  • IндеПендентная: Может разрабатываться отдельно.

  • Nегозиабельная: Открыта для обсуждения и изменений.

  • Vажная: Приносит ценность пользователю.

  • Eстимируемая: Может быть оценена по усилиям.

  • Sмаленькая: Умещается в спринт.

  • Tестируемая: Имеет четкие критерии приемки.

Давайте применим эту модель INVEST к одному из примеров пользовательских историй выше:

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

(Я собираюсь сделать некоторые предположения здесь, так как это теоретическая кодовая база и теоретический проект)

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

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

Эта история определенно ценна. После внедрения пользователь сможет войти. Если бы история была:

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

Это было бы бесполезно. Пользователь ничего бы из этого не получил.

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

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

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

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

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

Похоже, что мы создали хорошую пользовательскую историю!

Если вы используете структуру, которую я определил выше, и история соответствует критериям модели INVEST, это, вероятно, хорошая история.

Распространенные ошибки при создании пользовательских историй

Я видел, как пользовательские истории ошибались в прошлом, когда люди упускали несколько ключевых аспектов пользовательской истории:

Сосредоточение на технических аспектах

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

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

Как только ваша история перестает быть понятной конечному пользователю, вы ошиблись.

Сосредоточьтесь на том, что пользователь собирается сделать, и что пользователь собирается увидеть.

Давайте посмотрим на пример истории с техническим фокусом:

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

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

Давайте исправим это:

Как незарегистрированный пользователь, когда я нажимаю на ссылку “Забыли пароль” с правильным адресом электронной почты, на указанный адрес электронной почты отправляется письмо со ссылкой для сброса пароля.

Непрофессиональные пользователи могут понять это, и это ставит акцент на пользователе, а не на продукте.

Сотрудничество заинтересованных сторон

Agile — это сотрудничество.

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

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

Если, например, только команда инженеров разработает пользовательские истории, они могут выглядеть примерно так:

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

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

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

И это здорово. Но теперь давайте вовлечем контроль качества, который приходит с другой точки зрения, так как у них другой опыт работы с программным обеспечением:

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

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

Отлично. Мы получаем более полную подборку пользовательских историй, охватывающих больше ситуаций. Но что произойдет, если мы вовлечем продукт?

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

Команда продукта знает своих пользователей. Они знают, что люди действительно используют менеджеры паролей. Мы должны убедиться, что когда пользователь на самом деле ничего не вводит (поскольку текст загружается менеджером паролей), вход все равно работает корректно.

Неопределенные истории пользователей

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

Если вы написали историю пользователя, которая может быть интерпретирована 10 разными способами 10 разными людьми, вы немного ошиблись.

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

Давайте еще раз рассмотрим следующую историю пользователя:

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

Здесь есть неопределенность.

Какое сообщение должно появиться? Когда страница перезагружается после неудачной попытки входа, должно ли поле для ввода имени пользователя возвращаться к пустому значению или быть предварительно заполненным ранее введенным значением? Что значит “неверный адрес электронной почты”? Адрес электронной почты, который никогда не был зарегистрирован, или адрес электронной почты, который в данный момент недействителен (не оплаченная подписка, отмененная подписка и т.д.)

Как видите, детали имеют значение.

Эта история пользователя является довольно надуманным простым примером, и мне удалось найти много вопросов по ней.

Давайте исправим проблему:

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

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

Введите критерии приемки.

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

Такие вещи, как:

  • Сообщение об ошибке: “Неверный адрес электронной почты или пароль”

  • Текстовые поля для адреса электронной почты и пароля сбрасываются на пустые при перезагрузке

  • Пользователь не может получить доступ к страницам, где требуется вход в систему

  • Пользователю предлагается вариант “забыл пароль”.

Критерии приемки определяют, что ожидается от реализации.

Как начать с пользовательских историй

Начните с малого.

Сначала вы не будете идеальны в уточнении и создании пользовательских историй.

Создание пользовательских историй — это искусство, равно как и наука. Практика делает совершенство.

Создание пользовательских историй должно происходить в группе. Часто это делается с использованием подхода “3 Амидо”, где инженер, продуктовый специалист и QA собираются вместе и проводят мозговой штурм различных вариантов, которые вам нужно поддерживать.

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

Заключение

Agile — это сотрудничество. Scrum — это сотрудничество. Создание пользовательских историй — это сотрудничество. Помните об этом.

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

Пользователь — в центре внимания. Если вы когда-либо используете терминологию, которую ваш пользователь не понимает, пересмотрите пользовательскую историю.

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

Посмотрите мои блоги на моем сайте, Just Another Tech Lead, или подпишитесь на мою еженедельную электронную рассылку здесь.