1. Создание карточки Рассказа - VadimMustyatsa/three_trips GitHub Wiki

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

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

Если, в духе книги “Spring in action”, перенести эту ситуацию в наше время, то можно представить, как некая известная личность на склоне лет решает увековечить память о своей деятельности с помощью финального яркого биографического произведения. Хотя это и не очень соответствует характеру персонажа, но представим себе в такой роли богатыря Илью Муромца. Он обращается в литературное агентство с просьбой написать последнюю былину о себе, в которой был бы зафиксирован его финальный самый яркий подвиг. Чтобы зафиксировать свою идею, Илья создаёт соответствующую карточку «Рассказа»:

Былина: Последний подвиг Ильи Муромца

  Как постаревший богатырь Илья Муромец
  Я хочу совершить свой финальный яркий подвиг
  Чтобы наверняка прославиться в веках

Данное состояние «Рассказа пользователя» называется Card, поскольку во времена зарождения техники адепты Экстремального программирования записывали название и нарратив для новой функции в системе на бумажных карточках, которые вешались на специальные доски для возможности отслеживания их статуса и дальнейшей обработки. На сегодняшний день некоторые команды продолжают использовать бумажные карточки, но в рамках подхода BDD предполагается коллективное участие в работе над репозиторием проекта, поэтому можно представить, что автор идеи (будь то сам заказчик, менеджер, аналитик или даже кто-то из разработчиков) создал в репозитории новый “.feature” файл, записал в нём вышеприведённый текст и сделал примерно такой коммит. В результате карточка «Рассказа» выглядит примерно так.

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

Название самого «Рассказа», как правило, совпадает с названием файла или немного расширяет его за счёт возможности использования большего количества символов. В реальных “.feature” файлах для указания названия используется специальное слово «Функция» с двоеточием (в англоязычной версии “Feature:”). В примере используется слово «Былина» для соответствия метафоре.

Текст нарратива записан на основе шаблона «Голос пользователя» (User Voice), но это не является требованием ни одного фреймворка. Текст, следующий за названием, как и сам текст названия, не подвергается никакой автоматической обработке. Это документация исключительно для людей. Использование шаблона удобно именно на начальной стадии работы с «Рассказом», пока он не реализован и не превратился в реальную функцию. В дальнейшем «Голос пользователя» заменяют, как правило, на более конкретное описание назначения функции и основных правил, на основе которых она работает.

Каждая часть нарратива несёт в себе конкретный вид информации о «Рассказе». В первой строке, указывающей на автора, важно отметить не только использование имени и социальной роли персонажа, но также указание на его преклонный возраст, которое делает более понятным последующий текст. Так всего одно слово может ощутимо повысить уровень отражения контекста «Рассказа». Зачастую же многие команды в этой части пишут просто «Как пользователь» (“As a user”), что полностью лишает такой «Рассказ» возможности достичь своей изначальной цели – помочь разработчикам взглянуть на новую функцию глазами того человека, которому она действительно нужна. Обезличенные «Рассказы» ничем не отличаются от сухой формальной спецификации.

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

Третья же строка, содержащая мотивационную часть, традиционно считается самой важной в «Рассказах пользователя». Она содержит информацию, находящуюся не в зоне контроля команды (то, что команда способна сделать своими силами), как в предыдущей строке, а в зоне влияния (то, на что команда может лишь повлиять). Кроме того, это не просто указание на желаемое поведение, а указание на изменение в поведении, которого хочет достичь автор карточки и которое команде необходимо каким-либо образом проверить, чтобы убедиться, что «Рассказ» был реализован успешно. Не просто указано, что необходимо так повлиять на читателей произведения, чтобы они надолго запомнили персонажа, поскольку с большой вероятностью такое поведение будет достигнуто и без этой дополнительной былины. Указано, что этого необходимо достигнуть «наверняка», то есть с вероятностью близкой к 100%. Соответственно, проверка этой гипотезы может включать в себя прочтение разного набора былин двумя тестовыми группами читателей. Первая группа прочтёт все былины об Илье Муромце, за исключением этой последней, а вторая группа прочтёт в том числе и её. Сравнение результатов тестирования двух групп позволит выяснить, какое влияние оказывает дополнительная былина на читателей и оправдалось ли предположение автора. Данная информация о результатах проверки может быть использована при разборе последующих «Рассказов» и планировании последующих итераций, оказывая влияние на развитие продукта. Именно эта возможность движения вперёд через постоянные эксперименты и отличает, в сущности, гибкую разработку от более традиционных подходов.

Весь комплекс перечисленных выше мер позволяет сделать карточку «Рассказа» весьма лаконичной и при этом достаточно информативной, чтобы стать отличным напоминанием и вводной в обсуждение, которое происходит на дальнейших стадиях работы над «Рассказом». Что является её прямым предназначением.