Как видите, идея – в рассказе, и вы сами знаете: если рассказ правильный, то у слушателей пробуждаются интерес и энергия, предмет рассказа предстает перед ними как живой. Не правда ли, здорово? Да и звучит намного интереснее, чем просто чтение типичного документа с требованиями
[13].
Однако многие из тех, кто начинает использовать истории в разработке программного обеспечения, но все еще подразумевает традиционную модель процесса, стараются больше фокусироваться на этапе написания. Мне случалось видеть команды, которые заменили написанием историй традиционный процесс составления документов с требованиями и, конечно, впадали в бешенство, стараясь с помощью историй точно сформулировать, что должно быть реализовано в программе. Если сейчас то же самое происходит у вас, остановитесь.
Если вы не собираетесь вместе, чтобы всесторонне обсудить свои истории, то на самом деле вы не используете истории.
Рон Джеффрис и три «П»
В книге «Утвержденное экстремальное программирование»
[14] Рон Джеффрис с соавторами описывают, как работать с историями наилучшим образом.
Пишем. Запишите то, что вы хотели бы видеть в программном продукте, на нескольких карточках.
Проговариваем. Соберитесь вместе и всесторонне обсудите программный продукт, который создаете, и все, что будет в нем реализовано.
Подтверждаем. Договоритесь о способе подтвердить то, что программный продукт готов.
1. Пишем
Допустим, вы ответственны за работу команды, которая получила задание создать какой-то программный продукт. Представьте этот продукт как можно яснее. Затем запишите на карточке каждое действие, которое пользователи могли бы проделать с применением вашего продукта. В результате вы получите стопку карточек. Сначала Кент предлагал делать записи на картотечных карточках, потому что проще расположить их на столе, расставить в соответствии с приоритетом или составить из них структуру, которая позволит увидеть общую картину – это, разумеется, карта историй.
Набор карточек, который целиком описывает продукт или все изменения, которые мы хотим внести в уже существующий продукт, называется продуктовым бэклогом. Этот термин произошел из процесса Scrum в методологии Agile. Один мой знакомый однажды признался: «Я ненавижу термин “бэклог”. Это слово звучит так, будто мы, даже не начав работать над программным продуктом, уже все завалили!»
[15] У меня, к сожалению, нет лучшего названия для этой пачки историй, но если вы можете придумать что-то более позитивное, пожалуйста, используйте свой термин и напишите мне об этом.
2. Проговариваем
Обсуждение начинается, когда вы описываете свои идеи и задумки, а слушатели осмысливают их, основываясь на том, что слышат. Зачастую дать идеальное описание нелегко, а вот вообразить на основе услышанного нечто основанное на собственном прошлом опыте легче легкого, поэтому слушатель чаще всего представляет себе что-то совершенно отличное от того, что подразумеваете вы. Но все-таки волшебство происходит именно сейчас.
Как всегда при обсуждениях, слушатели могут задавать вопросы. Эти уточнения скорректируют их восприятие и помогут в конце концов прийти к верному единому пониманию.
В традиционном процессе разработки программ человек, составляющий требования, обычно хочет лишь корректно записать их на бумаге, а тот, кто собирается приступить к разработке программного продукта, должен их правильно понять. А если процесс управляется историями, у всех есть совершенно другая общая цель. Ваша цель – работать вместе, чтобы разобраться в проблеме, от которой можно избавиться с помощью программного продукта, а затем решить ее наилучшим из возможных способов. Разумеется, вы все должны договориться, что именно будете создавать и что, по вашему мнению, наиболее полезно тем, кто станет работать с продуктом.
Разрешите мне повторить это важное утверждение.
Обсуждать истории нужно для того, чтобы, работая вместе, найти наилучшее решение проблемы, которую мы все понимаем одинаково.
3. Подтверждаем
Все эти разговоры хороши, но все-таки рано или поздно надо начать программировать, верно? Что ж, когда мы, кажется, нашли правильное решение, нужно сконцентрироваться на следующих вопросах.
Если мы реализуем то, что мы все согласились делать, как проверить готовность и правильность полученного продукта?
Ответ на этот вопрос обычно представляет собой короткий список проверок. Его еще иногда называют критериями приемки или тестами историй.
Когда придет время показать результат нашей работы на демонстрации продукта, как это сделать?
Чаще всего ответ на этот вопрос выявляет несколько пробелов в планировании. Например, вы можете закончить разработку, но для демонстрации нужны какие-то реальные данные. Обсуждение демонстрации может добавить еще несколько пунктов в список критериев приемки.
Слова и картинки
На пути к соглашению недостаточно вооружиться одной карточкой и много размахивать руками. Обсуждение идет лучше всего, если у вас есть множество подручных средств, например простые изображения персонажей, диаграммы рабочего процесса, наброски интерфейса и прочее, что обычно используется в традиционном подходе к разработке ПО для того, чтобы лучше объяснить что-то. Таким образом, вы не будете просто размахивать руками, а конкретно укажете на предмет обсуждения. Что бы ни стало предметом обсуждения, это всегда можно пометить, записать, скорректировать или изменить. Мы можем создать множество разных вещей прямо на ходу, во время обсуждения. Активно используйте доску или большие листы бумаги. Не забудьте также сделать несколько «фото из отпуска» перед тем, как команда разойдется. Снимки того, что вы сделали, помогут вам припомнить все детали обсуждения, записать которые на бумаге нелегко.
