В книге «Утвержденное экстремальное программирование» Рон Джеффрис с соавторами описывают, как работать с историями наилучшим образом.

 Пишем. Запишите то, что вы хотели бы видеть в программном продукте, на нескольких карточках.

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

 Подтверждаем. Договоритесь о способе подтвердить то, что программный продукт готов.

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

Набор карточек, который целиком описывает продукт или все изменения, которые мы хотим внести в уже существующий продукт, называется продуктовым бэклогом. Этот термин произошел из процесса Scrum в методологии Agile. Один мой знакомый однажды признался: «Я ненавижу термин “бэклог”. Это слово звучит так, будто мы, даже не начав работать над программным продуктом, уже все завалили!» У меня, к сожалению, нет лучшего названия для этой пачки историй, но если вы можете придумать что-то более позитивное, пожалуйста, используйте свой термин и напишите мне об этом.

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

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

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

Разрешите мне повторить это важное утверждение.

Все эти разговоры хороши, но все-таки рано или поздно надо начать программировать, верно? Что ж, когда мы, кажется, нашли правильное решение, нужно сконцентрироваться на следующих вопросах.

Ответ на этот вопрос обычно представляет собой короткий список проверок. Его еще иногда называют критериями приемки или тестами историй.

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