Story Mapping + BDD = Docs As Code? / Денис Олейник (Один Сервис. Внедренческий центр)

• Денис Олейник и Федор Латыпов обсуждают методику разработки, основанную на использовании BDD и Stariopping.  

• Они обсуждают, что в современной платформе OneС есть инструменты для управления юнит-тестами и манипулирования OneС.  

• Они также обсуждают, что в OneС существует сообщество энтузиастов, которые разработали BDD фреймворк, похожий на Cucumber.  

• Денис и Федор обсуждают, что не всегда люди, которые говорят о том, что у них есть, имеют то же самое, что и в их голове.  

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

• Денис и Федор обсуждают, что проблема не только в их домене, но и в мире в целом.  

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

• В видео обсуждается проблема с пониманием методики "Три друга", которая может привести к проблемам с внедрением и передергиванию информации.  

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

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

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

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

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

• Также рассматривается пример, когда программист пытается использовать методику, но неправильно понимает ее, добавляя циклы и условия в язык геркин, что может привести к проблемам с читаемостью кода.  

• Gherkin не жизнеспособен для общего взаимодействия бизнеса, программиста и тестировщика.  

• Перекос, когда тестировщик занимается Gherkin, приводит к написанию сценариев, которые не описывают бизнес-логику.  

• Gherkin не работает при изменении продукта, так как интерфейс и названия контролов меняются.  

• Многие коллеги из сообщества пишут юнит-тесты на Gherkin, ожидая, что это будет полезно.  

• В результате получается карго-культ, когда люди увлеченно пишут фичи-файлы, но это не приносит пользы.  

• Gherkin должен быть применен во всем процессе разработки, начиная с бизнес-анализа и заканчивая валидацией продукта заказчиком.  

• Это помогает команде и бизнесу, так как критерии приемки формализованы и автоматизированы.  

• Заказчики приходят с базами, которые сложно поддерживать из-за отсутствия документации, исходных требований и пользовательских инструкций.  

• Сторипинг может помочь решить эту проблему, позволяя команде лучше понимать и поддерживать базу.  

• Стори мапинг - это инструмент для работы с требованиями, который позволяет формализовать и автоматизировать процесс разработки.  

• Он может быть использован для объединения различных инструментов и артефактов, связанных с требованиями.  

• Команда провела эксперимент по использованию стори мапинга для проекта электронной коммерции.  

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

• В процессе разработки используется стори мапер для отслеживания выполнения задач и требований.  

• Стори мапер состоит из иерархии пользовательских активностей, пользовательских историй, критериев приемки и конкретных примеров.  

• Аллюр формируется на основе результатов выполнения сценариев и отражает картину по проекту.  

• Живая документация создается с помощью пикли и отражает изменения в фичи-файлах.  

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

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

• Необходимо избегать карго культа и адаптировать рабочий процесс поэтапно.  

• Важность прозрачности процессов для бизнеса, чтобы он мог понимать и платить за услуги.  

• Финансовая метрика на верхних уровнях фич помогает оценить соотношение услуг и бизнес-ценности.  

• Необходимо напоминать бизнесу о ценности, которую вы приносите, чтобы он не забывал о ней.  

• В докладе обсуждается, что пользовательские сценарии должны быть обязательно включены в продукт, чтобы убедить пользователя в его использовании.  

• Сценарии должны быть ограничены и не должны быть перенасыщенными, чтобы не перегружать пользователя.  

• Продукты, которые позволяют последовательность действий для пользователя, лучше подходят для реализации пользовательских сценариев.  

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

• В случае изменений, необходимо общаться с заказчиком и обсуждать, какие сценарии нужно изменить.  

• Если изменения касаются условий бизнеса, то добавляются новые шаги и автоматизация.  

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

• В итоге, бизнес-аналитик или программист автоматизирует пользовательские сценарии.  

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

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

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

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

• Денис обсуждает использование своей платформы для работы с требованиями, которая позволяет собирать, формализовать и проверять требования.  

• Он также упоминает, что его платформа универсальна и может быть использована для работы с различными инструментами, такими как Jira и Confluence.  

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

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