Введение
Создание пользовательских историй, которые ясны, кратки и полезны, имеет решающее значение для успешной разработки проекта. В этом руководстве мы рассмотрим ключевые элементы хорошей пользовательской истории, используя принципы 3C (Карточка, Разговор, Подтверждение) и INVEST (Независимость, Переговороспособность, Полезность, Оценка, Малость, Проверяемость). К концу этого руководства вы получите пошаговое понимание того, как структурировать пользовательские истории, которые приводят к эффективным и эффективным циклам разработки.
Создание эффективных пользовательских историй с использованием 3C и INVEST
Давайте создадим пользовательскую историю для приложения для управления задачами.
Пользовательская история
Как занятый профессионал, я хочу легко приоритизировать и организовать мои задачи чтобы я мог максимально повысить свою продуктивность.
Критерии приемки:
- Создание:
- Условия: Пользователь должен быть авторизован в приложении.
- Критерии: Пользователь может создать новую задачу, указав заголовок, описание и дату выполнения.
- Категоризация:
- Условия: Должна быть создана задача.
- Критерии: Пользователь может назначить категорию или метку задаче (например, работа, личное, срочно).
- Приоритизация:
- Условия: Должна быть создана задача.
- Критерии: Пользователь может установить уровень приоритета для задачи (например, высокий, средний, низкий).
- Сортировка:
- Условия: Должно быть создано несколько задач.
- Критерии: Пользователь может сортировать задачи по дате выполнения или уровню приоритета.
- Редактирование:
- Условия: Должна быть создана задача.
- Критерии: Пользователь может редактировать заголовок, описание, дату выполнения, категорию или приоритет задачи.
- Отметка как выполненная:
- Условия: Должна быть создана задача.
- Критерии: Пользователь может отметить задачу как выполненную, и она должна визуально отличаться от незавершённых задач.
- Уведомления:
- Условия: Должна быть установлена дата выполнения для задачи.
- Критерии: Пользователь получает уведомление, когда задача должна быть выполнена.
Критерии INVEST
- Независимость: Каждая функциональность (создание, категоризация, приоритизация, сортировка, редактирование, отметка как выполненная, уведомления) может быть разработана и протестирована независимо.
- Обсуждаемость: Подробности пользовательской истории могут быть обсуждены между командой разработки и владельцем продукта с учётом приоритетов и ограничений.
- Ценность: История пользователя приносит ценность, предоставляя комплексную систему управления задачами, позволяя пользователям эффективно организовывать, приоритизировать и завершать задачи.
- Оцениваемость: Команда разработки может оценить усилия, необходимые для каждой функции в пользовательской истории.
- Маленький: Каждая функция сфокусирована и достаточно мала, чтобы быть завершенной за один спринт.
- Проверяемый: Критерии приемки предоставляют четкие условия, которые можно использовать для проверки завершения каждой функции.
Пошаговое руководство
- Войдите в приложение:
- Откройте приложение.
- Введите данные для входа.
- Нажмите кнопку «Войти».
- Создать новую задачу:
- Нажмите кнопку «Новая задача».
- Введите название задачи, описание и дату выполнения.
- Нажмите кнопку «Создать».
- Категоризировать задачу:
- Нажмите на созданную задачу.
- Выберите категорию из раскрывающегося меню.
- Нажмите кнопку «Сохранить».
- Установить приоритет задачи:
- Нажмите на созданную задачу.
- Установите уровень приоритета (высокий, средний, низкий).
- Нажмите кнопку «Сохранить».
- Сортировать задачи:
- Перейдите к основному списку задач.
- Нажмите кнопку «Сортировать».
- Выберите сортировку по дате выполнения или приоритету.
- Редактировать задачу:
- Нажмите на задачу, чтобы отредактировать.
- Измените заголовок, описание, дату выполнения, категорию или приоритет.
- Нажмите кнопку «Сохранить».
- Отметьте задачу как выполненную:
- Нажмите на задачу, чтобы отметить её как выполненную.
- Нажмите кнопку «Отметить как выполненное».
- Получайте уведомления:
- Убедитесь, что установлены сроки выполнения задач.
- Дождитесь уведомлений в день выполнения.
Следуя этим шагам, пользователи могут эффективно управлять своими задачами, приоритизировать их и не отставать от сроков.
Пример: Хорошо и плохо
Давайте создадим пользовательскую историю о пользователе, который хочет сбросить свой пароль. Мы сравним хорошо сформированную пользовательскую историю «подтвердить» с плохо сформированной версией «не подтвердить».
Пользовательская история подтверждения
| Пользовательская история подтверждения | |
|---|---|
| Название: | Сброс пароля |
| Как: | Зарегистрированный пользователь |
| Я хочу: | Сбросить мой пароль |
| Чтобы я мог: | Восстановить доступ к своему аккаунту, если я забуду свой текущий пароль |
| Критерии приемки: | 1. Пользователь должен иметь возможность перейти на страницу «Забыли пароль». <br> 2. Пользователь должен получить электронное письмо с ссылкой для сброса пароля. <br> 3. Нажатие на ссылку для сброса должно перенаправить пользователя на страницу, где он сможет ввести новый пароль. <br> 4. После успешного сброса пароля пользователь должен иметь возможность войти в систему с новым паролем. |
Причины для подтверждения
- Пользовательская история ясна и направлена на потребность пользователя сбросить пароль.
- Она включает чётко определённую роль пользователя (зарегистрированный пользователь).
- Критерии приемки конкретны, проверяемы и охватывают весь процесс сброса пароля.
Пользовательская история не подтверждения
| Пользовательская история не подтверждения | |
|---|---|
| Название: | Функция сброса пароля |
| Как: | Пользователь |
| Я хочу: | Иметь улучшенную функцию сброса пароля |
| Чтобы я мог: | Улучшить свой опыт использования приложения |
| Критерии приемки: | 1. Пользователи должны иметь возможность сбросить пароль. |
Причины отказа в подтверждении
- В пользовательской истории отсутствует ясность относительно того, что именно необходимо улучшить в функции сброса пароля.
- Роль пользователя определена неясно как «Пользователь», из-за чего неясно, для кого предназначена функция.
- Критерии приемки слишком неопределённы и не предоставляют конкретных шагов для разработки и тестирования.
- Не указано, как должен происходить сброс пароля, какие шаги в него входят или как будет выглядеть успех.
В примере «Не подтверждено» отсутствие конкретики в пользовательской истории и критериях приемки затрудняет понимание потребностей пользователя командой разработки и предоставление удовлетворительного решения. Это также усложняет тестирование и проверку, поскольку критерии успеха не определены четко.
Краткое содержание
В этом подробном руководстве мы погрузились в искусство создания пользовательских историй, соответствующих принципам 3C и INVEST. Независимо от того, являетесь ли вы владельцем продукта, разработчиком или частью агильной команды, у вас теперь есть инструменты для создания пользовательских историй, которые не только хорошо структурированы, но и приносят ощутимую ценность вашим проектам. Помните, хорошо сформулированная пользовательская история заложит основу для успешного взаимодействия и обеспечит соответствие конечного продукта потребностям его пользователей.