Методологія EventStorming: як синхронізувати бізнес-експертів та розробницьку команду

Привіт! Мене звати Богдан Новиков, я Software Architect в одній з продуктових компаній венчур білдера SKELAR. Уже вісім років ми будуємо продукт для контент-креаторів та стримерів-початківців, який буде місцем, де легко заводити нові знайомства та спілкуватися з цікавими людьми зі всього світу.

Два роки я працюю разом із бізнес-експертами та розробницькими командами, щоб створювати оптимальні рішення для бізнесу та наших користувачів. 

За цей час у нас було багато викликів, один з яких можна сформулювати наступним чином: як зробити «правильний продукт» з точки зору бізнесу та водночас «зробити продукт правильно» технічно? Це дві сторони одного питання, і швидко дійти єдиного рішення буває складно.

Саме тому я б хотів поділитись однією з технік, завдяки якій ми розв'язуємо це питання, –– методологією EventStorming. 

Що ж таке EventStoriming сесії? По суті, це формат брейнштормінгу, який дозволяє ефективно поєднувати бізнес-експертів та розробників у робочу групу, що здатна здобувати знання та будувати модель предметної області. Під час роботи група синхронізується щодо очікувань, здобуває єдину мову та фіксує свої знання на діаграмі. 

В яких випадках застосовувати EventStorming 

Уявіть наступну ситуацію: команда бізнес-експертів генерує ідеї щодо створення або покращення продукту, ці ідеї передаються команді з розроблення, яка намагається «перекладати» ці ідеї у завдання з технічними деталями. 

Зазвичай це відбувається наступним чином: розробники у взаємодії з PO/PM починають описувати UI/UX продукту, структуру таблиць, API, транзакції, взаємодію UI-компонентів, інфраструктуру бази даних, схему релізів.

Такий формат взаємодії має певні мінуси:

Саме для того, щоб здобувати нові знання, генерувати ефективне рішення для комплексних задач, ми проводимо EventStorming сесії.

Як провести EventStorming-сесію

Розгляньмо як проводити EventStorming на прикладі системи оброки замовлень. 

Етап 1: Підготовка до EventStorming

На цьому етапі вам необхідно провести підготовчу роботу. Треба сфокусуватись на наступному:

Етап 2: Визначення подій на EventStorming

Сесія починається з визначення ключових подій предметної області. Щоб їх сформулювати, необхідно відповісти на питання: «Що важливого відбувається або може відбутись в предметній області?». В процесі обговорення ідей, кожен з групи має занотувати події на помаранчевому стікері та розмістити його на вайтборді. Події записуємо в минулому часі.

Коли події виявлені, необхідно розташувати їх на вайтборді в послідовності дії: від тих, що відбуваються раніше, до тих, що відбуваються пізніше. Якщо події трапляються приблизно в один і той самий час –– розташовуємо їх в колонку. На цьому етапі ми також можемо доповнювати послідовність подіями, які виявили додатково.

Так ми розташували події від «Order information entered» до «Payment processed», що фактично і є нашим шляхом користувача. 

Етап 3: Користувачі, команди, зовнішні системи

Після упорядкування подій, фокусуємось на моделюванні бізнес-процесів. Для цього необхідно переглянути події та поставити собі запитання: «Як виникає ця подія? Що її спричиняє?». 

Таким чином ми виявимо:

Ми зафіксували актора «User», який може використовувати команди «Add to card» та «Checkout».

А також визначили зазначили, що за керування запасами буде відповідати зовнішня система – «Inventory system».

Етап 4: Моделі для читання на EventStorming

Наступним етапом є виявлення моделей для читання. Для цього ставимо запитання: «Яка інформація необхідна для того, щоб користувач прийняв рішення виконати команду?».

В нашому прикладі ми занотували: для того, щоб виконати команду «Add to cart», необхідно мати інформацію про продукт – модель для читання «Product infromation».

В процесі проведення сесії можуть виникати запитання щодо подій, моделей для читання та будь-якого іншого стікера. Питання важливо фіксувати на червоному стікері та кріпити до стікера, якого стосується це питання.

Ми не розуміємо що робити, якщо система обліку товарів недоступна, саме тому занотували питання «What if invetory system unavailable?”

Етап 5: Бізнес-правила на EventStorming

У процесі моделювання ви можете виявити конкретні бізнес-правила. Дуже часто ці правила можна відокремити за патерном «Якщо стається ситуація X, то робимо Y». Ці правила нотуємо на фіолетових стікерах та приєднуємо до команди, яка запускає правило, або до ланки подій, якої це правило стосується.

До команди «Order added to card» ми занотували бізнес-правило: «send a notification to the user if more than 1 hour has passed since the item was add to the cart».

Етап 6: Агрегати на EventStorming

Базуючись на даних, які необхідні для виконання команд і бізнес-правил, ми створюємо агрегати. Агрегати –– це сутності, моделі даних, які потрібні для того, щоб дані залишились узгодженими в процесі виконання бізнес-правил.

Виявлення агрегатів –– цікава та водночас не очевидна задача, яка може мати декілька коректних рішень. Для того, щоб знайти оптимальне рішення, поставте питання: «Які дані необхідні для того, щоб гарантувати коректну роботу команди?».

Наприклад, для виконання команди «Add to cart» необхідно зберігати актуальний стан кошика користувача, включно з датою останнього додавання товару в кошик. 

Агрегати записуємо на темно-жовтих стікерах та розташовуємо над командами та подіями.

EventStorming: що отримаємо в результаті

Після того, як ми виявили події, змоделювали агрегати, відповіли на питання, ми отримуємо «креслення системи». 

Створена діаграма дозволяє команді розмовляти єдиною мовою. Ця схема зрозуміла розробникам (команди, агрегати), UI/UX дизайнерам (моделі для читання), доменним експертам (схема подій, бізнес-правила, актори) та іншим спеціалістам. 

В процесі EventStoriming сесії робоча група в складі бізнес-експертів та розробників повністю синхронізувалася щодо подій, які повинні відбуватися внаслідок тої чи іншої дії користувача, взаємодії зі сторонніми системами та моделями даних. 

Діаграма не містить специфічних технічних деталей –– над цими деталями ще доведеться попрацювати, водночас вона містить значну частину важливої інформації, яка дозволяє команді деталізувати та розробити систему. 

Більш детальну інформацію ви можете знайти на сайті автора методології Альберто.