Home

Автор: Алексей Бобок (компания Рафт)

Развитие AI-инструментов на базе современных LLM запустило тренд на автоматизацию всего, что прибито меньше, чем на 2 гвоздя, и первыми адоптерами здесь традиционно выступает IT сообщество. Как Луи Пастер некогда ставил себе и друзьям намешанные на голой коленке вакцины, так сейчас разработчики активно ставят себе Code Copilot-ы, дизайнеры экспериментируют с Midjourney, скромно к этой очереди пристраиваемся и мы, Product Manager-ы.

Меня зовут Алексей, и я более 15 лет занимаюсь управлением b2b-b2c продуктами и руководством командами в энтерпрайзе и стартапах.

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

Грядка, где будем проращивать AI

Многие Product manager-ы и я в их числе грешны тем, что в процессе создания цифровых решений опираются на BDD или Behavior Driven Development методологию, суть которой в налаживании более тесной коммуникации между бизнесом и разработкой с тем, чтобы конечный продукт как можно лучше отвечал интересам первого, следуя при этом передовым инженерным практикам, будучи легко поддерживаемым, устойчивым и масштабируемым.  

Не буду погружаться в описание принципов Agile и деталей данной методологии – это не раз уже делалось, в том числе авторами на Хабре. Я коснусь лишь ключевых аспектов BDD, которые важны для нашего исследования, – ‘Три амиго’ подхода и Gherkin синтаксиса.

Кто такие эти три амиго? Конечно же, тут все в лучших традициях вестернов – это своего рода Хороший, Плохой и Злой продуктовой разработки, представляющие соответственно Бизнес, Разработку и Тестирование. В роли представителя бизнеса обычно выступает как раз таки Product manager, интересы разработки представляет Tech Lead или архитектор системы, за тестирование играет QA-инженер. Задача этих троих – договориться в части требований о том, какой именно продуктовый инкремент в конечном итоге должен быть создан командой.

Память, как известно, - вещь коварная, поэтому все достигнутые договоренности непременно должны быть зафиксированы в доступных каждому из наших трех амиго терминах. Здесь в игру как раз и вступает товарищ Gherkin – это человекочитаемый язык, предназначенный для формального описания пользовательских сценариев (user scenario) и критериев приемки (acceptance criteria). Суть Gherkin довольно проста: для записи используются стандартные синтаксические конструкции Given-When-Then ( Дано-Когда-Тогда), описывающие конкретный пользовательский сценарий таким образом, что учитывается исходное состояние системы, дается описание совершаемых пользователем действий и ожидаемого результата.

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

Scenario: User successfully log in to the System

Given User is on a Login page

When User enter her correct login and correct password, and press “Log in” button

Then the System redirects User to a Home page

В конечном итоге сформированные в таком виде скрипты 'скармливаются' используемому для автотестирования решению( например, Cucumber или Behave), тем самым проходятся все Дантовские круги, и замыкается цикл разработки.

Сорняки на грядке

“Как же классно все придумано в этом вашем BDD! Супер-методология, должна работать, как часы! Надо брать! Заверните две, пожалуйста!” – могли подумать неокрепшие умы, но дьявол кроется в деталях и планы 'блиц-крига' нередко сталкиваются с суровой реальностью.

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

Перечислим некоторые из возможных проблем, с которыми сталкивается команда, осваивающая BDD:

• Команде, незнакомой с методологией в целом и с Gherkin синтаксисом, в частности, может понадобиться много времени на их освоение, что удлиняет learning curve и усложняет adoption-процесс

• Product manаger-ы и Разработчики редко осваивают Gherkin, поэтому генерация скриптов ложится целиком на QA инженеров.

• Gherkin скрипты создаются QA-инженером в конце цикла разработки и не проходят ревью со стороны Product manager-а, порой расходясь с критериями приемки, сформулированными для User Stories

• Отсутствует единый source of truth для ведения существенных артефактов, влияющих на продукт, так, например, User stories могут вестись в одной системе (скажем, в JIRA), а пользовательские сценарии и критерии приемки могут вестись в другой системе (например, в Cucumber) и не синхронизированы друг с другом, вызывая соответственно разрыв в понимании отдельных продуктовых инкрементов со стороны бизнеса, разработки и тестирования

• to be continued…

“И что же – всё тлен?” – Конечно же, нет, доктор Фрейд, решение есть!

И лежит оно, как всегда, на поверхности, до блеска отполированной адептами искусственного интеллекта.

И на Марсе будут яблони цвести!

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

Для решения задачи в рамках проводимого эксперимента мы создали прототип плагина  для JIRA Cloud под рабочим названием AI_JIRA_BDD_Assistant, который на основании описания User Story в Description задачи генерирует пользовательские сценарии и критерии приемки в формате Gherkin скриптов.

Разработка велась на Node.JS и ReactJS на базе созданной Atlassian платформы Forge, предназначенной для разработки JIRA и Confluence приложений и предоставляющей удобный способ обращения к Jira REST API и собственные компоненты для разработки фронтенд части плагина UI kit 2. Для проксирования и последующей обработки запросов с помощью AI был создан Langchain агент, взаимодействующий с LLM-моделью от OpenAI gpt-3.5-turbo посредством следующего системного скрипта:

You are a helpful Product manager assistance agent who help to create user scenarios and acceptance criteria for user stories following the instruction.
INSTRUCTION.
You should treat input text information you got as a Summary of User story.
User scenario for User story should be written following Behavior Driven Development rules. 
Acceptance criteria should be written in Gherkin syntax. 
As a result you need to provide only a user scenario text first and relevant acceptance criteria after that.
Generate user scenario and acceptance criteria strictly based on user story summary you have. Don’t make them up.
If input text you got is in English then you should respond in English too.
I will tip you with 1000 US dollars for best answer. Please make it good because it is very important for my career.

Давайте же теперь посмотрим, как сделанное мини-приложение без регистрации и смс может помочь продуктовой команде в имплементации BDD подхода:

• Product manager продолжает жить свою счастливую жизнь и в привычной манере работать с продуктовым бэклогом, наполняя его User stories точно также, как он делал это ранее. Например, создает User story для входа пользователя в систему, использованную нами для примера ранее:

• Пока все довольно буднично, и вся магия чуть начинается дальше, когда идет подготовка к ‘Три амиго’ сессии: предположим, что созданная в примере выше User story была приоритезирована и отобрана Product maanger-ом для обсуждения на ближайшей запланированной сессии с разработкой и тестированием. Чтобы подготовить данную User story к эффективному разбору в рамках этой встречи, Product manager-у теперь достаточно нажать одну кнопку, ‘призвав’ на помощь AI JIRA BDD Assistant-а – плагин автоматически сформирует сценарии и критерии приемки, придерживаясь правил Gherkin языка:

Таким образом, на ‘Три амиго’ сессии все участники, не тратя лишних усилий, теперь могут проделать ревью задач и критериев их приемки, сформулированных уже в требуемом методологией формате, при необходимости внеся коррективы в подготовленные системой драфты, и в итоге согласовать близкий к конечному результат, убедившись, что у всех сторон единое понимание проблемы с минимальным риском разночтений. Тем самым устраняются споры внутри команды, кто должен инициировать формирование критериев приемки, следующих Gherkin синтаксису, облегчается коллаборация, learning curve для новичков сокращается, появляется единое централизованное доступное всем участникам процесса хранилище артефактов – в общем, много чего хорошего начинает происходить, что сподвигает команду к более активной и, главное, продуктивной совместной работе!

Есть куда расти

Разумеется, до того, чтобы превратить подобный плагин в полноценный рабочий инструмент на службе у практикующей BDD команды потребуется еще немало усилий, так, к примеру, генерацию сценариев и критериев приемки в идеале нужно делать с учетом имеющихся спецификаций и макетов, поэтому вероятно может понадобиться механизм дообучения модели, или, к примеру, Gherkin скрипты в идеале должны сохраняться в специально отведенном месте и формате, позволяющем максимально бесшовно “скармливать” их используемому командой QA решению для автотестирования. В зависимости от требований конкретной организации список тут может быть продолжен.

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

Экспериментируйте, оптимизируйте, и да пребудет с вами сила технологий! !

Обсудить в форуме