Мене звати Богдан Новиков, я Solution Architect в одній з компаній від venture builder SKELAR. Вже 8 років ми будуємо продукт для контент-креаторів та стрімерів-початківців, який стане місцем, де легко заводити нові знайомства та спілкуватись з цікавими людьми зі всього світу.

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

‍

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

‍

‍

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

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

‍

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

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

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

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

• Команда з розроблення втрачає знання предметної області. Коли команда розробки фокусується на технічному розвʼязанні задачі, втрачається контекст альтернативних рішень та знання, які можна було отримати при розборі вимог.
• Бізнес-експерти не розуміють якою мовою розмовляє команда розробки. Таблиці, транзакції, RPC, ідемпотентність, API, ETL, індекси –– не до кінця зрозуміло як ці речі вирішують бізнес-проблему.
• Бізнес втрачає стратегічні доменні знання. Команда розробки робить багато технічних рішень, проте не всі з цих рішень розв'язують проблему та дають перспективи стратегічного розвитку бізнесу.

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

‍

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

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

‍

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

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

• 1Запланувати зустріч та запросити на неї ключових спеціалістів. На зустрічі мають бути люди, які вміють ставити правильні питання (наприклад, розробники) та люди, які можуть давати відповіді (наприклад, доменні експерти, клієнти).
• 2Підготувати інструменти –– вайтборд та стікери, якщо зустрічаєтесь офлайн. Для онлайн-сесій я рекомендую використовувати ось такий шаблон в Miro.

‍

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

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

‍

‍

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

‍

‍

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

‍

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

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

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

• Команди –– це дії, які можна робити в нашій системі. Приклад команди: «add to cart». Команди записуємо на синьому стікері та додаємо лівіше події, яка генерується заданою командою.
• Актори –– це користувачі, які запускають команди. Приклад актора: «user». Актори записуємо на жовтому стікері та додаємо до кожної команди.
• Зовнішні системи –– це системи, які не є частиною вашого домену, але призводять до важливих подій.  Зовнішньою системою може бути платіжна система, наприклад paypal. Зовнішні системи записуємо на рожевому стікері.

Ми зафіксували актора «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» необхідно зберігати актуальний стан кошика користувача, включно з датою останнього додавання товару в кошик.

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

‍

Що отримуємо в результаті сесії

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

‍

‍

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

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

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

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

‍

*Цей матеріал написаний спеціально для SPEKA.media.