Посмотрите, я собираюсь сказать кое-что, что может привести к тому, что меня не пригласят на следующую конференцию по Agile: истории пользователей не всегда являются решением. Вот, я это сказал. Прежде чем вы закроете эту вкладку и напишете гневный комментарий о том, что я «не понимаю Agile», выслушайте меня. Я годами наблюдал, как команды религиозно превращают каждое требование в священный формат «Как… Я хочу… Чтобы…», даже когда это было абсолютно неуместно.
Проблема не в самих историях пользователей. Они — вполне подходящий инструмент. Проблема в том, что к ним относятся как к Единому Кольцу, управляющему всеми требованиями. И в отличие от кольца Толкина, это кольцо даже не делает вас невидимым на стендапах, когда вы не выполнили свои задачи.
Неудобная правда о догматизме историй пользователей
Мы создали культ вокруг историй пользователей. Я присутствовал на совещаниях, где умные инженеры изо всех сил пытались втиснуть миграцию базы данных в формат истории пользователя. «Как база данных, я хочу нормализовать свою схему, чтобы я могла… существовать должным образом?» Нет. Просто нет.
Типичная история пользователя следует шаблону Connextra, который выглядит элегантно на бумаге. Но вот что происходит на практике: в итоге у вас получается бэклог, полный историй, которые читаются как «Сумасшедшие либы», написанные человеком, который никогда на самом деле не пользовался программным обеспечением. Половина из них не содержит критически важных технических деталей, потому что «мы обсудим это во время уточнения», что становится оправданием для вечной неопределённости.
Позвольте мне показать вам, что я имею в виду, на реальном примере, с которым я столкнулся:
# История пользователя #437
Как пользователь
Я хочу, чтобы система была быстрой
Чтобы я мог быстро выполнять свою работу
Эта история прошла через три сеанса уточнения, прежде чем кто-то наконец спросил: «Что означает „быстрая“?» Оказалось, что нам требовалось время отклика менее секунды для поисковых запросов в наборах данных с миллионами записей. Это не проблема истории пользователя — это требование к производительности, которое нуждается в конкретных цифрах, технических ограничениях и архитектурных решениях.
Когда истории пользователей становятся активно вредными
Давайте поговорим о нефункциональных требованиях. Это нелюбимые дети Agile — вещи, которые заставляют ваше программное обеспечение работать в продакшене, но не вписываются аккуратно в формат истории пользователя. Безопасность, производительность, масштабируемость, поддерживаемость, наблюдаемость. Ну, знаете, скучные вещи, которые определяют, будет ли ваша система работать в 3 часа ночи в Чёрную пятницу.