Сегодня поговорим о user stories (US) и частых ошибках при их проработке (#23). Я затрагивал некоторые в предыдущих постах (тут и тут), но надежный как швейцарские час план подразумевает посвященный этому отдельный пост. При всем моем стремлении сделать это вкратце, заметка, скорее всего, в очередной раз задавит объемом: ну извините — как вы давно поняли, за форматом инстапостов не сюда 😊

1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.

Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.

2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».

Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.

3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.