В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

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

Рассмотрим Agile-подход к решению этой проблемы.

Для начала разберемся с концепцией CCC, которая расшифровывается как Card, Conversation, Confirmation.

Card (Карточка)

Идея состоит в том, что вся User Story должна поместиться на небольшую бумажную карточку или стикер. Много на ней не напишешь, да это и не нужно.

Главное предназначение карточки – служить напоминанием, приглашением к обсуждению (placeholder for conversation).

Цель – сместить фокус с написания требований на их обсуждение. Ибо живое обсуждение более важно, чем написанный текст.

Карточка должна коротко, но емко отражать суть задачи. Предлагаемый формат:

Мне как {роль} нужна {функциональность}, чтобы достичь {цели}.

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

При написании User Story рекомендуется сосредоточиться на пользователе нашего приложения (focus on user needs and benefits).

Функциональность лучше описывать не абстрактно, а с использованием живых примеров (by example).

Первоначальная формулировка User Story делается умышленно нечеткой. Добавление подробностей откладывается до последнего момента, когда продолжать без них уже нельзя.

User Story может ссылаться на развернутые требования, например, протокол взаимодействия или формулу расчета.

Карточка User Story служит также для отслеживания статуса задачи, например, на канбан-доске.

Conversation (Обсуждение)

Обсуждение – наиболее важная часть.

Между разработчиками и Product Owner действует соглашение: разработчики обязуются задавать вопросы, а PO обещает, что будет для них доступен.

Общение, в идеале, происходит лицом к лицу (face to face), так как это наиболее эффективный (high bandwidth) способ передачи информации. Важные аспекты живого общения – это его интерактивность (возможность уточнить и удостовериться), а также обратная связь (один из фундаментальных принципов Agile).

Живое обсуждение позволяет преодолеть или свести к минимуму недостатки, присущие документации:

• к моменту использования она уже устарела
• написанный текст часто неоднозначен,
• неполон,
• не проверяем,
• скучен (кто-то его вообще читает?),
• статичен (нет возможности задать вопрос, нет уточнений и новых требований возникающих в ходе обсуждения),
• может, даже ошибочен (сообщите ли вы кому-либо о своих сомнениях?)
• документация создает ложное чувство достоверности и полноты
• документация часто навязывает конкретное, быть может, не самое эффективное решение

Confirmation (Подтверждение)

Третий важный аспект User Story – это подтверждение того, что задача выполнена.

Условия приемки (acceptance criteria), а также Definition of Done, оговоренные заранее, позволят вовремя прекратить работу, оценить, достигнута ли преследуемая бизнес-цель.

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

Насколько же детальной должна быть User Story?

Вернемся к исходному вопросу и рассмотрим две крайности:

1. User Story непроработаны совсем. В этом случае в начале спринта могут возникнуть такие вопросы, получение ответов на которые сильно задержит начало разработки. Задержит ее настолько, что задача не будет выполнена в рамках запланированного спринта. Простой и ожидание снизят нашу эффективность.
2. User Story проработаны максимально, т.е. Product Owner заранее подготовил ответы на все возможные вопросы. В этом случае мы не сможем взять в спринт задачи до тех пор, пока PO их не проработает. Это увеличит нагрузку на PO (стремление предвидеть все возможные вопросы, повторная проработка меняющихся требований, проработка требований по задачам, которые будут отложены или отменены), замедлит его работу, отодвинет разработку важных и срочных требований заказчика, например, полученных в рамках обратной связи.

Очевидно, что мы не хотим впадать ни в одну из этих крайностей. Значит оптимум где-то посередине. Чтобы нащупать его, будем использовать концепции “точно вовремя” (just in time) и “ровно столько, сколько нужно” (just enough).

User Story должна содержать ровно столько подробностей, так что недостача хотя бы одной привела бы к тому, что мы не успели бы выполнить задачу в спринте. Добавление подробностей должно происходить точно вовремя, не позже, и не раньше. Смещение в любую сторону снижает нашу эффективность.

Можно ли достичь такого баланса для каждой User Story? Разумеется нет, но надо постоянно подстраиваться.

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

Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.

Идеи данной статьи почерпнуты из следующих источников:

• https://www.mountaingoatsoftware.com/agile/user-stories (англ.) – введение от Mike Cohn.
• https://www.betteruserstories.com/courses/better-user-stories/videos (англ.) – три весьма полезных бесплатных видео-урока от Mike Cohn.