Написание пользовательских историй — это фундаментальный навык для любого программиста, вступающего в среду Agile. Хотя многие команды полагаются на цифровые платформы для управления задачами, понимание основных принципов пользовательской истории без зависимости от программного обеспечения формирует более прочную основу. Это руководство фокусируется на ручном процессе, используя физические объекты, такие как стикеры, доски и карточки, для создания четких, выполнимых требований. Цель — ясность мышления, а не удобство экрана.
Когда вы убираете программное обеспечение, вы вынуждены глубоко вникнуть в содержание. Нет функций автозаполнения или заранее заданных шаблонов, за которыми можно спрятаться. Вам необходимо явно сформулировать ценность, исполнителя и потребность. Эта ручная дисциплина гарантирует, что команда понимает проблемную область, прежде чем написать одну строку кода. Ниже мы рассмотрим анатомию истории, критерии принятия и методы уточнения идей без цифровой помощи.
📖 Понимание основного понятия
История пользователя — это легкое описание функции, изложенное с точки зрения человека, желающего получить новую возможность, обычно пользователя или клиента системы. Это не документ спецификаций. Это временный элемент для обсуждения. Физический акт записи истории на карточке или бумаге подкрепляет этот замысел. Она должна быть перемещена, отредактирована, отброшена или объединена. Цифровые системы часто слишком рано закрепляют вас в жесткой структуре. Ручные методы сохраняют историю гибкой.
Зачем использовать ручной метод?
Существует несколько убедительных причин практиковать написание историй вручную, особенно для новых инженеров:
- Фокус на ценности:Без полей для заполнения вы фокусируетесь на реальной ценности.
- Когнитивная нагрузка:Письмо от руки замедляет вас, давая время подумать, прежде чем фиксировать текст.
- Совместная работа:Физические карточки позволяют командам физически переставлять работу, визуализируя поток и приоритеты.
- Независимость:Вы настолько хорошо усваиваете формат, что можете писать корректные требования, даже если инструменты недоступны.
📋 Анатомия ручной истории
Каждая пользовательская история следует определенной структуре. При ручном написании используйте единый формат на карточках или стикерах. Такая последовательность позволяет команде быстро просматривать информацию во время планировочных сессий. Стандартный формат состоит из трех различных частей. Не пропускайте ни одной из них.
1. Персона (Кто)
Определите конкретную роль или тип пользователя. Избегайте общих терминов, таких как «пользователь». Будьте точны. Это «Администратор», «Гость-посетитель» или «Премиум-подписчик»? Персона определяет права доступа и контекст функции.
2. Действие (Что)
Опишите возможность или действие, которое пользователь хочет выполнить. Это глагол. Он должен быть высоким уровнем цели, а не техническим деталям реализации. Например, «искать товары» лучше, чем «ввод запроса в базу данных SQL». Действие отражает намерение пользователя.
3. Выгода (Чтобы)
Это самая важная часть, которую часто пропускают новички. Почему пользователь хочет этого? Какую ценность это приносит? Если вы не можете ответить на этот вопрос, история, возможно, не имеет ценности. Фраза «Чтобы» связывает функцию с бизнес-результатом или результатом для пользователя.
Пример структуры
Напишите это в одной или двух строках. Держите текст кратким.
- Как [Персона],
- Я хочу [Действие],
- Чтобы [Выгода].
📝 Определение критериев приемки
История не является завершенной без критериев приемки. Это условия, которые должны быть выполнены, чтобы считать историю выполненной. При ручной записи эти критерии следует перечислить непосредственно под карточкой истории или на отдельном листе, прикрепленном к ней. Они выступают в качестве тестовых случаев для инженерной работы.
Критерии приемки устраняют неоднозначность. Они определяют границы функции. Без них два инженера могут реализовать разные решения для одной и той же истории. Ручная запись заставляет вас продумать крайние случаи до начала разработки.
Формат Given/When/Then
Для точных критериев используйте структуру Given/When/Then. Это ручной перевод методологии разработки, ориентированной на поведение (BDD). Она четко структурирует логику.
- Дано: Начальное состояние или контекст.
- Когда: Событие или действие, выполненное.
- Тогда: Ожидаемый результат.
Примеры критериев
- Дано, что пользователь авторизован,
- Когда они нажимают кнопку выхода,
- Тогда они перенаправляются на страницу входа.
- Когда они нажимают кнопку выхода,
Таблица типов критериев
Существуют различные типы критериев. Таблица помогает классифицировать их во время ручной записи.
| Тип | Описание | Пример |
|---|---|---|
| Функциональный | Конкретное поведение системы | «Система отправляет письмо после отправки формы» |
| Нефункциональный | Ограничения производительности или безопасности | «Страница загружается за менее чем 2 секунды» |
| Бизнес-логика | Правила, регулирующие данные | «Скидка применяется только к заказам на сумму более 50 долларов» |
| Пользовательский интерфейс | Требования простоты использования | «Кнопка должна быть видна без прокрутки» |
🌐 Проверка по модели INVEST
Как только вы вручную напишете историю, вы должны проверить ее качество. Модель INVEST — это стандартная структура для этого. Вы можете использовать чек-лист на отдельном листе бумаги, чтобы оценить каждую историю перед добавлением в бэклог. Это гарантирует, что работа будет выполнимой и ценной.
Независимость
История должна быть автономной. Она не должна зависеть от выполнения другой истории, чтобы быть ценной. Хотя технические зависимости существуют, ценность должна быть независимой. Если вы должны ждать выполнения Истории А, чтобы начать Историю Б, подумайте, можно ли разделить Историю Б.
Обсуждаемость
История — это обещание обсудить, а не договор. Она позволяет вести диалог между инженером и заинтересованным лицом. Если текст слишком детализирован, он превращается в спецификацию, а не в историю. Оставьте место для технических исследований.
Ценность
Каждая история должна приносить ценность пользователю или бизнесу. Если история не эффективно соответствует требованию «Так чтобы», ее следует отбросить или переработать. Ценность — это главный критерий бэклога.
Оцениваемость
Команда должна иметь возможность оценить необходимые усилия. Если история слишком неясна, ее нельзя оценить. Если она слишком сложна, ее нужно разбить. Ручная запись помогает выявить неясность, поскольку вы должны физически записать все детали.
Маленькая
История должна быть достаточно малой, чтобы быть выполненной за один итерационный цикл или спринт. Большие истории — это риски. Они часто приводят к незавершённой работе. Если история кажется проектом, разбейте ее на более мелкие последовательные истории.
Проверяемость
Вы должны иметь возможность проверить, что история завершена. Если нет критериев приемки, история не проверяема. Ручная запись заставляет чётко определить, как выглядит «готово».
Чек-лист INVEST
Используйте эту таблицу для проверки ваших историй во время планирования.
| Буква | Вопрос для задания | Статус |
|---|---|---|
| I | Может ли эта история быть разработана без других? | [ ] |
| N | Область применения открыта для обсуждения? | [ ] |
| V | Обеспечивает ли она четкую ценность? | [ ] |
| Е | Можем ли мы оценить усилия? | [ ] |
| S | Влезет ли это в спринт? | [ ] |
| T | Есть ли четкие условия прохождения/провала? | [ ] |
🔍 Процесс доработки
Доработка, также известная как выравнивание, — это деятельность по подготовке историй к будущей разработке. Для доработки не нужно программное обеспечение. На самом деле, физическое перемещение карточек по столу может улучшить понимание потока. Сессия доработки включает в себя обзор историй, уточнение деталей и разбиение крупных элементов.
Шаг 1: Обзор
Соберите команду вокруг большого стола. Расположите карточки. Прочитайте каждую историю вслух. Это простое действие позволяет выявить ошибки, которые незаметны при молчаливом чтении. Следите за неоднозначностью в разделе «Так чтобы».
Шаг 2: Разделение
Если карточка кажется слишком тяжелой, разделите её. Напишите новую, более короткую историю на новой карточке. Разместите новую карточку над оригинальной или сбоку. Убедитесь, что оригинальная карточка обновлена, чтобы отразить разделение. Такое визуальное разделение помогает управлять объемом работ.
Шаг 3: Вопросы
Во время обзора команда задает вопросы. Запишите эти вопросы на отдельном листе. Не отвечайте на них сразу. Вопросы указывают на пробелы в знаниях. Они становятся задачами на следующую сессию. Это разделяет планирование и ответы.
Шаг 4: Последовательность
Расположите карточки в порядке зависимости или ценности. Используйте нитки или скотч на столе, чтобы показать связи. Если карточка А должна произойти до карточки Б, проведите линию между ними. Такой визуальный поток помогает выявить узкие места до начала разработки.
📈 Методы приоритизации
Как только у вас появится список историй, вы должны решить, что нужно создать в первую очередь. Ручные методы приоритизации часто эффективнее цифровой сортировки, потому что они предполагают физическое взаимодействие с работой.
Метод MoSCoW
Цветовое кодирование ваших карточек или использование разных форм для обозначения приоритета. Это классический ручной метод.
- M – Обязательно:Критически важно для релиза. Без исключений.
- S – Следует иметь:Важно, но не жизненно необходимо. Может быть отложено при необходимости.
- C – Можно иметь:Желательно, но не обязательно.
- W – Не будет сделано:Согласны не включать в текущую область охвата.
Взвешенный кратчайший первый (WSJF)
Для более математического подхода присвойте числовые значения ценности и времени. Запишите эти числа на карточке. Рассчитайте отношение вручную. Это заставляет команду количественно оценивать ценность, а не полагаться на интуицию. Это ценное упражнение для новых инженеров, чтобы понять бизнес-компромиссы.
⚠️ Распространённые ошибки, которые следует избегать
Даже при ручном подходе ошибки случаются. Новые инженеры часто попадают в определённые ловушки при написании историй без руководства со стороны программной проверки.
1. Техническая лексика
Не пишите истории с точки зрения системы. Избегайте слов, таких как «база данных», «API» или «бэкенд». Пишите с точки зрения пользователя. Система для пользователя невидима. Если вы пишете «Система обновляет кэш», пользователь не интересуется этим. Его интересует скорость загрузки страницы.
2. Отсутствие критериев приемки
Легко написать часть «Я как…» и забыть «чтобы…» или критерии. История без критериев — это просто пункт в списке дел, а не пользовательская история. Это создаёт неоднозначность. Всегда требуйте критерии, прежде чем карточка будет считаться завершённой.
3. Слишком много деталей
Написание истории — это не написание спецификации. Если вы пишете пять абзацев на одной карточке, вы, скорее всего, избыточно детализировали. Держите карточку маленькой. Детали должны обсуждаться в ходе доработки, а не находиться на самой карточке.
4. Пренебрежение крайними случаями
Ручное написание часто фокусируется на «счастливом пути». Вам нужно явно записать, что происходит, когда что-то идёт не так. Добавьте критерии для состояний ошибок. «При отсутствии сети, когда пользователь отправляет форму, он видит сообщение о повторной попытке».
5. Отсутствие сотрудничества
Написание истории в одиночку — это потеря времени. Истории — это старт для обсуждения. Если вы пишете историю без обсуждения с коллегой, она, скорее всего, будет неправильно понята. Всегда проверяйте её вручную вместе с коллегой.
👩💻 Переход к цифровым системам позже
Хотя этот гид фокусируется на ручных методах, команды в конечном итоге переходят к цифровым системам для отслеживания и отчетности. Навыки, которые вы здесь освоите, напрямую переносятся. Когда вы в конечном итоге будете использовать цифровую платформу, вы будете писать более качественные истории, потому что понимаете основную структуру. Вы не будете полагаться на программное обеспечение, чтобы определять ценность за вас.
Переход будет плавным, если основа прочная. Цифровой инструмент становится хранилищем для ручной работы, которую вы уже продумали. Вы просто копируете содержимое карточки в систему. Логика остаётся той же.
📝 Практическое упражнение для новых инженеров
Чтобы закрепить эти концепции, попробуйте следующее упражнение. Для него не требуется программное обеспечение, только бумага и ручка.
- Шаг 1:Выберите функцию, которую вы используете ежедневно (например, строку поиска на веб-сайте).
- Шаг 2:Напишите пользовательскую историю на карточке, используя стандартный формат.
- Шаг 3:Напишите три критерия приемки с использованием Given/When/Then.
- Шаг 4:Примените чек-лист модели INVEST к карточке.
- Шаг 5: Запишите два вопроса, которые у вас возникли по поводу истории, на которые задаст вопрос разработчик.
- Шаг 6: Просмотрите карточку с коллегой. Попросите его критиковать раздел «Так чтобы».
💬 Заключительные мысли о дисциплине ручного труда
Овладение искусством пользовательской истории — это точность и эмпатия. Вам нужно встать на место пользователя. Вам нужно быть ясным и кратким. Ручной процесс устраняет шум интерфейсов программного обеспечения и оставляет только суть. Эта дисциплина делает вас лучшим инженером. Она делает вас лучшим коммуникатором.
Когда вы устраняете инструменты, у вас остается логика. Именно эта логика движет программным обеспечением. Практикуясь вручную, вы убеждаетесь, что ваша логика правильна, прежде чем просить компьютер выполнить её. Такой подход снижает повторную работу и повышает качество. Это тихая уверенность в вашей способности определять ценность.
Помните, цель не в заполнении цифрового бэклога. Цель — решить проблему для человека. Держите человека в процессе. Держите историю простой. Держите критерии ясными. Эти принципы будут служить вам хорошо, независимо от того, какие инструменты вы в конечном итоге используете.
📊 Обобщение ключевых выводов
- Структура: Всегда используйте: Как пользователь / Я хочу / Так чтобы.
- Критерии: Определите «Дано/Когда/То» для ясности.
- Проверка: Проверьте по критериям INVEST перед окончательным утверждением.
- Совместная работа: Просматривайте карточки вручную вместе с командой.
- Фокус: Ставьте ценность для пользователя выше технической реализации.