Про те самые Story

Термин "история", как синоним фичи, думаю, известен всем. Спасибо джире. Но вот что за этим словом кроется, как я вижу, понимают далеко не все.

Я очень люблю рассказывать вот такое. В 90-е наш любимый Кент Бек садился с заказчиком и просил рассказать свою историю. Что не так, что нужно починить. И вот это и есть та самая история, unit of work.

Я часто вижу, что работа бьётся так: таска на подключение к базе, таска на то, чтобы приделать Кафку, сделать "движок", "ядро", "фабрику", "стейт-машину", "скелет", "заводик", "конвейер" или что там ещё любят делать. Оно понятно, как так получается: все сели, подумали, как решать проблему, нарезали на более-менее независимые куски, создали под них задачи и раздали программистам.

Это, конечно, никакие не пользовательские истории. Трудно представить, что ты приходишь к таксисту, оператору или, не знаю, врачу, спрашиваешь, что у него болит, а он в ответ: "ну, в базе данных нет того-то, Кафка не подключена, ядра нет".

Вроде бы и пофиг, да? В целом, да, отчасти. Это работает, но кое-что ломается. Сделав так, вы потеряли интент, намерение, заменив его инструментом. Мой последний пост был как раз про это: вы заменили цель средством. Если со средством все ок, то и цель будет достигнута. Поэтому обычно и работает.

А вот что не работает. Потерянное на этапе реализации намерение приводит к тому, что самые умные люди в процессе, инженеры, задают не те вопросы. Обычно вопрос звучит так: "мать твою, да как же это сделать". Хотя, если намерение не было потеряно, то этот вопрос меняется на: "блин, зачем так сложно, можно же по-другому". И свои драгоценные мозги инженер тратит не на покорение горы, а на ее обход.

Это одно из мест, где тот самый Lean, про который я говорил много раз, начинает выдавать те самые иксы в темпах разработки, которые иначе не получить ни архитектурой, ни тестами, ни оргкультурой.

В общем, технические детали - это первое, что выдаёт "неправильную историю" или, если корректнее, проблемную постановку задачи.

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

Но опять же, воспользуемся все той же проверочной эвристикой. Представьте себе, что пользователь формулирует свою боль так: я хочу войти и загрузить картинку. Нифига! Пользователь хочет просто удалить фон. А если это ещё можно сделать без авторизации и загрузки картинки, он будет только рад.

И вот эти детали реализации, как раз, опять приводят разработчика к вопросу, как победить авторизацию и загрузку, а не к вопросу, нужны ли они вообще. Где-то нужны, где-то, а где-то, весьма вероятно, нет.

Так что правильнее всего так: обычно история - это какая-то боль.

Ну хорошо, но тогда как делать, например, оплату? Представляете себе пользака, который хочет удалить фон, но при этом хочет обязательно за это заплатить. Ещё и не просто заплатить, а подписку за тыщу рублей купить. В неделю.

Это явно не боль пользователя. Но ответ элементарный: истории бывают не только у пользователей, но и у маркетологов, аналитиков, админов, начальников. И даже у разработчиков.