Story Mapping + BDD = Docs As Code? Способы управления техническими знаниями внутри компании

Доклад принят в программу конференции
Денис Олейник
Один Сервис. Внедренческий центр

Более 12 лет работает техническим директором. Занимается организационными изменениями, популяризацией и имплементацией в компании промышленных стандартов разработки. Вместе с компанией прошёл путь от точечных допилов на production до стандартизированного процесса разработки и поставки изменений заказчикам.

1cto@1service.ru
Тезисы

BDD как концепция существует с 2006 года. За это время методика, по идее, должна была бы уже прижиться и стать стандартом де-факто.

Казалось бы, что может быть проще: слушай стейкхолдера в три пары ушей, обсуждай, да записывай фичи на Gherkin, набрасывай код и автоматизируй сценарии.

Но вот почему-то в нашем домене ERP-систем истории BDD-успеха на поверку оказываются очередным набором UI-тестов, написанных постфактум.

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

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

P.S.
По ходу доклада я буду использовать такие слова, как: BDD, Living Documentation, "Docs As Code", Impact Mapping, Story Mapping, Scrum, Kanban, Jenkins, Allure и другие термины из лексикона Agile-коучей. Но никакой инфо-цыганщины, только практические моменты.

Другие доклады секции Способы управления техническими знаниями внутри компании