Принципы написания эффективных историй от Pivotal Labs

Источник: https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way

Разные команды в разных проектах и компаниях используют разные стили написания историй. В конечном счете, именно вы и команда должны определить, что будет наиболее эффективным с учетом целей и контекста проекта. Однако основные принципы, которыми мы руководствуемся при написании историй в Pivotal Labs, могут быть использованы независимо от стиля или различий в процессе или синтаксисе. Несмотря на то, что различные взгляды на "лучший способ" написания историй могут затруднить определение наиболее эффективного подхода, существует несколько основных принципов, которыми мы руководствуемся при написании историй. В этой статье мы рассмотрим три наиболее распространенных типа историй, которые можно создавать в Pivotal Tracker, а также основные принципы, на которых строится процесс написания историй.

Написание рассказов: основные принципы

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

Важно также помнить, что в историях должно быть указано, что, а не как (например, "Улучшить отклик поиска на 15 секунд" по сравнению с "Не выполнять индексацию всей таблицы при каждом обновлении базы данных"). Истории не должны быть технически предписывающими, т.е. в них не нужно указывать, как именно ваша инженерная команда может реализовать рассматриваемую функциональность. Истории поясняют, зачем нужна функциональность и в чем конкретно она заключается.

Все истории должны следовать модели INVEST

I - Независимые - Истории должны быть самодостаточными

N - Переговорные - Истории не являются явными контрактами и должны оставлять пространство для обсуждения

V - Ценностные - Истории должны приносить пользу заинтересованным сторонам

E - Измеримые - Команда разработки всегда должны иметь возможность оценить размер истории

S - Маленькие - Истории не должны быть настолько большими, чтобы их невозможно было планировать выделять приоритеты с определенной степенью точности

T - Тестируемые - Истории или связанное с ним описание должны предоставлять необходимую информацию, чтобы сделать возможной разработку тестов

Различные типы историй

Фича стори/Юзер стори

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

Фича стори должны включать в себя несколько элементов:

Заголовок: заголовок должен быть кратким, описательным и включать конкретного пользователя/персону. Например, в качестве пользователя/персоны следует указывать либо конкретный тип пользователя (например, редактор), либо имя персоны (например, Джилл), а не просто "пользователь". Это также работает для пользователей, которые являются не людьми, а системами (например, "Purchasing API").
Бизнес-кейс: кому, зачем и с какой целью нужна данная функциональность? Это необходимо для того, чтобы все члены команды понимали, зачем добавляется данная функция. Если вы не можете придумать причину, то стоит пересмотреть вопрос о целесообразности включения функции. Бизнес-обоснование также позволяет другим членам команды задуматься о том, есть ли лучший пользовательский опыт, чем тот, который предоставляется.
Критерии приемки: Здесь определяются действия, которые необходимо выполнить, чтобы убедиться в том, что история завершена. Разработчики, работающие над этой историей, также должны пройтись по критериям приемки перед сдачей. В Pivotal наш начальный шаблон критериев приемки написан на языке Gherkin. Язык Gherkin был изначально создан для Cucumber, пакета тестирования Ruby, и предназначен для "обеспечения жестких, однозначных требований... и сценария для автоматизированного тестирования". Следует помнить, что хорошие функциональные описания не должны, однако, быть предписывающими в деталях реализации. Синтаксис выглядит следующим образом:
GIVEN [необходимый контекст] WHEN [действие] THEN [реакция].
Иногда для определения GIVEN полезно пройтись в обратном направлении (примеры будут приведены ниже). Если в критериях приемки вы обнаружите, что пишете несколько "и", то это тест на запах, указывающий на то, что вам следует разделить историю на две или более частей.
Примечания: Включите дополнительную информацию, необходимую для истории, например, примечания дизайнера (которые могут указывать на изменения в имитаторах) или примечания разработчика (которые могут дать понимание, которое поможет разработчикам реализовать историю).
Ресурсы: Добавьте макеты, эскизы, пользовательские потоки, ссылки и другие ресурсы, которые помогут в работе над материалом.
Метки: Сюда относятся эпики (большие всеобъемлющие функции), номера сборок, пользователи и т.д. Они наиболее эффективно используются для объединения историй в группы.

Баги

Ошибка - это дефект уже принятой функции, независимо от того, когда она была принята. Не следует использовать ошибки для описания новых возможностей и функциональности (например, "Цена должна быть неотрицательной" или "Не работает кнопка входа в систему"). Ошибки напрямую связаны с уже реализованными функциями и не несут никакой новой ценности для пользователя, поэтому они не имеют баллов. Другая причина отсутствия баллов заключается в том, что ошибки невозможно оценить, и их устранение может занять как 30 секунд, так и 30 дней.

Ошибки должны содержать эту информацию:

Название: оно должно быть коротким и описательным.

Описание: что происходит в данный момент? Что должно произойти?

Инструкции: изложите шаги по воспроизведению.

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

Задания

Задания - это история, которая необходима, но не приносит прямой и очевидной пользы пользователю (например, "Установить новый домен и сертификат SSL с подстановочным знаком для создания тестовых сред" или "Оценить инструменты для устранения неполадок в системе"). Задания могут представлять собой технический долг и/или точки зависимости от других команд. Задания не оцениваются (т.е. не указываются), поскольку они не приносят непосредственной пользы пользователю. Это означает, что если кажется, что задания приносит пользу пользователю, то она должна быть включена в функциональную статью. Например, если вы используете аналитический сервис, то дополнительная сложность настройки сервиса должна быть учтена в первом аналитическом материале, а не выделена в отдельную задачу.

Должны содержать следующую информацию:

Название: Должно быть коротким и описательным.

Описание: Зачем это нужно? Поможет ли это команде работать быстрее или это зависимость, которая может вызвать проблемы в кодовой базе, если ее не выполнить?

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