Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

С точки зрения пользователя размер истории верен, если он удовлетворяет его потребность.

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

С точки зрения команды разработки, размер истории верен, если программирование и тестирование занимает не более пары дней.

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

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

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

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

Воспринимайте истории как камни. Если я возьму очень большой камень, положу его посреди комнаты, а затем разобью молотом на 30 осколков, мы назовем их 30 осколками камня. Если вы возьмете один из этих меньших камней и тоже ударите по нему молотом, он разобьется на более мелкие части. Мы и их можем назвать осколками камня. Или подойти творчески и употребить, скажем, слова «валун» или «щебень». Но я не знаю, когда именно что-то перестает быть валуном и становится просто камнем. Он, может быть, и выглядит как простой камень, пока не упадет вам на ногу – тогда-то вы и почувствуете, что это настоящий валун.

Мой инструмент для разбивания камней – большой молот. И он отлично работает.

Большие истории разбиваются на меньшие истории, и эти меньшие истории тоже могут быть разбиты на совсем маленькие. Но любого размера, даже самого маленького, это все равно история. А какой инструмент лучше всего применить для разбивания историй? Правильно: обсуждение. Иногда достаточно просто немного поразмыслить, но если вы обсуждаете историю и работаете над ней совместно с кем-то еще, то одновременно расширяете одинаковое понимание.

Обсуждение – один из лучших инструментов для разделения больших историй на части.

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