Это стартовая вики-страница учебного репозитория «Три поездки Ильи Муромца». Здесь можно прочесть, зачем понадобился такой репозиторий и как он устроен, ниже – откуда возникла его идея, а справа через меню “Pages” можно перейти на нужную статью по этапам разработки «Рассказа».

Невыразительные примеры прошлого

Наиболее популярным способом представления техник определения функций и свойств продукта, к которым можно отнести и технику «Рассказов пользователя», традиционно было рассмотрение примера взаимодействия клиента банка с банкоматом. Первыми этот пример использовали авторы языка UML в середине 90-х годов, его же использовали Карл Вигерс (Karl Wiegers) и Алистер Кокбёрн (Alistair Cockburn) в 2000-х для представления техники «Способов использования» (Use Cases). Далее этот пример крайне распространился по различным учебным пособиям и стал поистине хрестоматийным. Скорее всего, по этой причине его и использовал Дэн Норт (Dan North) для презентации техники «Рассказов пользователя» в своей статье “What’s in a story?” в 2007 году. Этот же пример впоследствии перекочевал в книгу “The Cucumber Book” 2012 года, в которой Мэтт Уинн (Matt Wynne) и Ашлак Хеллесой (Aslak Hellesøy) раскрыли тему реализации BDD в рамках разработанного ими фреймворка Cucumber. Также крайне популярными примерами для представления техник подобного рода являются регистрация и вход пользователя в систему, которые нашли распространение не только в книгах и учебных пособиях, но и в многочисленных статьях на персональных сайтах и в блогах отдельных специалистов.

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

Ключевая проблема всех этих примеров для представления техники «Рассказов пользователя» заключается в их крайней тривиальности и детерминированности, которые не свойственны для проектов гибкой разработки. Заранее известное читателю конечное количество состояний системы не позволяет понять реальные преимущества описания действительно сложного и часто меняющегося поведения на сценарном языке Gherkin. Также статичность и предсказуемость примеров не позволяет в полной мере описать процесс эволюции «Рассказа» при прохождении им трёх основных фаз жизненного цикла Card, Conversation и Confirmation, на которых оказываются важны различные новаторские особенности данной техники. Для демонстрации подобных аспектов нужны более сложные примеры, с большей вариативностью сценариев и большей повествовательной составляющей.

Второй проблемой, актуальной уже для неангоязычных специалистов, является языковой барьер, который выражается не столько в сложности прочтения и понимания самих статей и книг (большинство неангоязычных ИТ специалистов владеют, как минимум, техническим английским), сколько в сложности перенесения особенностей техники на реалии своего языка. Дело в том, что, для возможности вовлечения заказчика и конечных пользователей в процесс определения функций и свойств продукта, Gherkin предполагает написание сценариев на их родном (или, по крайней мере, отлично им известном) языке. Поскольку большое количество русскоязычных ИТ специалистов работает и с русскоязычными заказчиками, остро встаёт вопрос качественной адаптации этой техники к особенностям русского языка. Иначе крайне высок риск неэффективного использования техники или вовсе отказа от её использования ввиду того, что нетехнические специалисты не будут понимать неестественные языковые конструкции.

Метафора как альтернатива

Для решения обеих проблем предлагается использование одного из исконных приёмов гибкой разработки – метафоры. Повсеместность использования метафор в мире ИТ упоминается ещё Кентом Беком (Kent Beck) в контексте объяснения этого приёма, как одной из ключевых практик Экстремального программирования, в книге “Extreme Programming Explained”. В этой же книге Кент Бек сам использует метафору своего обучения вождению для объяснения того, как Экстремальное программирование решает основные проблемы разработки ПО. Поэтому, следуя духу Экстремального программирования и гибкой разработки в целом, предлагается в качестве примера для презентации техники «Рассказов пользователя» рассмотреть описание сценариев поведения одного из самых известных русских литературных персонажей. А именно речь идёт об использовании в качестве источника сценариев различных вариантов былины «Три поездки Ильи Муромца».

Идея такого решения пришла во время обсуждения особенностей техники «Рассказов пользователя» с известным русским системным аналитиком и консультантом Денисом Бесковым. Денис высказал предположение, что сценарии, используемые в языке Gherkin, не могут считаться сценариями как таковыми, поскольку не содержат таких последовательностей действии, которые характерны, к примеру, для литературных произведений. Также Денис привёл пример надписи на «латырь-камне» из упомянутой выше былины в качестве «элементов управления потоком». Данные предположения являются одним из примеров искажённого восприятия техники «Рассказов пользователя», возникающих из-за локальных толкований особенностей техники в местных сообществах и недостаточной выразительности примеров, через которые она представлялась ранее. Таким образом, представление полного текста былины на языке Gherkin может доказать ошибочность таких предположений и показать реальную природу и ключевые особенности техники для всех заинтересованных русскоязычных специалистов.

Ещё одним источником вдохновения можно считать ту форму и манеру, в которой Крэйг Уолс (Craig Walls) и Райан Брейденбах (Rayan Breidenbach) описали возможности снижения сцепления (Coupling) кода с помощью принципа внедрения зависимостей (Dependency Injection) и аспектно-ориентированного программирования в Java-фреймворке Spring. В качестве примера авторы использовали задачу о рыцарях круглого стола, отправившихся на поиски Святого Грааля, и менестрелей, воспевающих каждый их подвиг. Как можно убедиться из текста соответствующей главы, пример с персонажами британского эпоса был выбран не для развлечения, а ввиду его достаточной сложности для возможности моделирования тех проблем, которые решаются с помощью представленных в книге технологий.

Былина в качестве метафоры

Былина – песенное произведение, то есть произведение, рассчитанное на пение. Однако напев былины скорее напоминает речитатив, поэтому к былинам традиционно применяют глагол «сказывать», а не «петь». Эта повествовательная природа очень близка к повествовательной природе «Рассказов пользователя». С литературной точки зрения и те, и другие произведения можно отнести к эпическому (повествовательному) жанру, в противопоставление драматическому жанру, в котором пишутся сценарии к театральным постановкам и кинофильмам (в виде реплик персонажей и авторских ремарок).

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

Былина, как и «Рассказ пользователя», строится в большинстве случаев на изображении одного героя, стоящего в центре повествования. И изображается чаще всего один конкретный эпизод. Однако былина «Три поездки Ильи Муромца» является исключением, поскольку в ней сплетены сразу три эпизода. Эта особенность позволяет показать динамику появления и преобразования новых сценариев в изначально односценарном «Рассказе».

Кроме того, поскольку былины – фольклорные произведения, у них не может быть конкретного изначального автора. Для исследований и печати былины записываются со слов так называемых сказителей, каждый из которых одновременно является хранителем сюжета былины и автором различных особенностей конкретной версии. Это позволило найти в фундаментальной электронной библиотеке «Русская литература и фольклор» (ФЭБ) целых 7 ощутимо отличающихся друг от друга версий былины, на основе которых появляется возможность варьировать поведение героя в процессе эволюции «Рассказа». При этом сам сюжет былины, особенно касающийся эпизода с камнем, знаком практически каждому русскоязычному человеку, что обуславливает наличие единого контекста, необходимого для возможности понятного описания сложного поведения.

Наконец, использование художественного произведения в целом позволяет абстрагироваться от технологий и сосредоточиться на фактической части «Рассказа», на поведении персонажа и обуславливающей это поведение мотивации, как и предполагается в BDD. Подобные условия создают прекрасную среду для мышления в стиле гибкой разработки, вместо сухого функционального мышления в терминах ролей и компонентов системы.