Story Mapping + BDD = Docs As Code? Способы управления техническими знаниями внутри компании
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-коучей. Но никакой инфо-цыганщины, только практические моменты.
Более 12 лет работает техническим директором. Занимается организационными изменениями, популяризацией и имплементацией в компании промышленных стандартов разработки. Вместе с компанией прошёл путь от точечных допилов на production до стандартизированного процесса разработки и поставки изменений заказчикам.