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

Мы оба можем прочитать один и тот же документ, но понять его по-разному.

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

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

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

Название «истории» произошло от того, как они должны использоваться, а не из-за того, что вы должны их записывать.

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

Просто – не значит легко

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

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

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

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

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

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

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

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

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

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

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

1. Пишем

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

Набор карточек, который целиком описывает продукт или все изменения, которые мы хотим внести в уже существующий продукт, называется