Карты историй – невероятно простая идея. Применяя простую карту, вы можете работать с другими людьми, чтобы изложить историю использования продукта и увидеть результат своей работы в целом. Затем вы дробите эту цельную картину на части, чтобы правильно распланировать разработку. Основу всего составляет простая концепция историй в Agile.

 

Убийственно простая идея Кента

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

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

Давайте задержимся здесь на минуту. Я имел удовольствие работать с множеством команд. Очень часто работа начиналась с обсуждения наших самых больших затруднений. И разумеется, чаще всего я первым делом узнавал о «неудачных требованиях». Каждый тычет пальцем в этот несчастный документ. Автор документа готов сгореть со стыда – наверняка он должен был написать больше или меньше либо, может быть, использовать какие-то новейшие техники составления документации. Те, кто подписал этот документ, ощущают себя не лучше и поэтому занимают оборонительную позицию: «Вы что, ожидали, что я вчитаюсь в каждую деталь? В конце концов мы обсуждали это целыми днями! Я думал, вы поняли, что я сказал. Я вообще не понимаю, откуда взялся этот дурацкий документ!» А те, кто работал над самим программным продуктом, и вовсе сбиты с толку – они выполнили свою задачу, руководствуясь этим злосчастным документом, но оказалось, что все по-прежнему неправильно. В общем, все хотят отправить эти бумаги в печку и немедленно написать новую, лучшую документацию.

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

 

1. Пишем

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

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

 

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

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

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

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

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

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

 

3. Подтверждаем

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

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

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

 Когда придет время показать результат нашей работы на демонстрации продукта, как это сделать?

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

 

Слова и картинки

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

Хорошее обсуждение историй всегда требует множества слов и картинок.

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

 

Вот и всё

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

А если нет?

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

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