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

Поскольку все вокруг говорили только о написании историй, мне пришлось задать Кенту вопрос: не пропустил ли я чего? Во время длинного обсуждения по электронной почте Кент объяснил мне происхождение идеи: «Я хотел развить известную ситуацию, когда пользователи сами излагают истории работы крутых функций, которые умеет выполнять их рабочая программа. [Например,] когда я впечатываю в поле почтовый индекс, а программа автоматически заполняет город и штат, мне не приходится нажимать ни одной кнопки.

Я думаю, именно этот пример натолкнул меня на мысль. Если вы можете рассказывать истории о том, что делает программа, вызывая интерес и живой отклик у слушателя, почему же не рассказать эти истории еще до того, как программа сможет это делать?» (Кент Бек в личной переписке, август 2010 года).

Как видите, идея – в рассказе, и вы сами знаете: если рассказ правильный, то у слушателей пробуждаются интерес и энергия, предмет рассказа предстает перед ними как живой. Не правда ли, здорово? Да и звучит намного интереснее, чем просто чтение типичного документа с требованиями[13].

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

Если вы не собираетесь вместе, чтобы всесторонне обсудить свои истории, то на самом деле вы не используете истории.

Рон Джеффрис и три «П»

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

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

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

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

1. Пишем

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

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

2. Проговариваем

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

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