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