Не мое изобретение ни разу, гуглите, да вам нагуглится. Была задача запустить каты в одном биг-техе, при условии, что организатор я один и вот, что из этого вышло.
Книжка: https://www.oreilly.com/live-events/architectural-katas/0636920097101/
Нативные каты: https://github.com/TheKataLog
Организация Architectural Katas для соревнования двух команд в разработке системной архитектуры — это увлекательный и образовательный процесс. Он позволяет участникам прокачать навыки системного мышления и подходы к проектированию архитектуры.
Цель:
- Повышение навыков архитектурного проектирования.
- Сравнение разных подходов к решению одной задачи.
- Укрепление командного взаимодействия и обмен опытом.
Целевая аудитория:
- Разработчики от middle +
- Системные аналитики
- Продуктовые архитекторы
Необходимые навыки:
- Минимальный опыт проектирования системной архитектуры
- Владение IDE
опционально:
- Знание OpenAPI 3.0
- Опыт работы с plantUML
Формат проведения:
Формат проведения Architectural Katas должен быть увлекательным, динамичным и соответствовать уровню участников. Вот примерный формат мероприятия, включая этапы и тайминг:
Общий формат
Соревнование длится от 4 до 6 часов и включает несколько этапов: подготовка, проектирование, презентация решений и финальная оценка.
Этапы проведения
Сами каты разбиты на три занятия по два часа.
1. Введение и разъяснение правил (30–40 минут)
Цель: Убедиться, что все участники понимают задание, правила и критерии оценки.
- Приветственное слово организаторов.
- Раздача задания и пояснение кейса (например, создание архитектуры для e-commerce платформы, логистической системы или банковского приложения).
- Объяснение критериев оценки.
- Ответы на вопросы участников.
2. Рабочая сессия: проектирование архитектуры (2–3 часа)
Цель: Каждая команда разрабатывает архитектурное решение.
- Выдача вспомогательных материалов (бумажные схемы, шаблоны, маркеры, онлайн-доски).
- Команды работают над проектированием:
Определяют ключевые компоненты.
Рисуют архитектурные диаграммы.
Прописывают обоснование выбранных технологий и подходов.
Учитывают риски, нефункциональные требования и ограничения.
- Наставники (если они есть) могут давать подсказки, но не вмешиваются в процесс.
Рекомендации:
- В середине сессии можно сделать небольшой 10-минутный перерыв.
- Предупредите команды за 30 минут до окончания времени.
Сессию, для команд имеет смысл разделить на этапы:
- Первая сессия (60 минут): Анализ задания и проработка требований .Определение границ системы.
Выделение основных компонент. - Вторая сессия (60–90 минут): Проработка архитектурных деталей. Диаграммы компонентов, последовательности и развертывания.
Учет нефункциональных требований и рисков. - Третья сессия (30 минут): Финализация и подготовка к презентации.
3. Презентация решений (1–1.5 часа)
Цель: Команды представляют свои архитектурные решения жюри.
- Каждая команда получает 15–20 минут:10 минут — презентация архитектуры.
5–10 минут — ответы на вопросы жюри. - Жюри фиксирует оценки по каждому критерию в процессе презентации.
4. Оценка и обратная связь (40–60 минут)
Цель: Подведение итогов, обсуждение и награждение.
- Жюри подсчитывает баллы и определяет победителя.
- Объявление результатов.
- Жюри дает подробный фидбек:Плюсы и минусы каждого решения.
Общие рекомендации по улучшению навыков. - Награждение победителей (и небольшой приз для второй команды в знак участия).
Тайминг мероприятия (пример)
Введение и правила 30–40 минут
Рабочая сессия 2–3 часа
Презентации 1–1.5 часа
Оценка и обратная связь 40–60 минут
Дополнительно:
- Интерактивность: Организуйте стенд вопросов, чтобы участники могли задавать вопросы по кейсу в ходе работы.
- Развлекательная пауза: Добавьте короткий кофе-брейк с неформальным общением, чтобы снять напряжение.
- Призы: Например, сертификаты, сувениры, книги по архитектуре или просто командные фото для памяти.
- Команды могут запросить ментора о проведение сессий event-shtorming'а.
Предварительная подготовка участников.
- Можно провести вводный вебинар, чтобы выровнять уровень знаний по темам:Принципы архитектурного проектирования.
Основы работы с OpenAPI 3.0 или PlantUML (если это важно для задачи).
Обзор кейса или примеры подобных задач. - Шаблоны и инструменты: предоставьте командам доступ к заранее подготовленным ресурсам (например, Miro, шаблоны PlantUML или OpenAPI).
Роли внутри команды.
Чтобы участники эффективно распределили задачи, предложите разделить роли:
- Технический лидер: координирует работу команды.
- Архитектор системы: отвечает за ключевые архитектурные решения.
- Документатор: создает и визуализирует диаграммы.
- Специалист по DevOps: отвечает за эксплуатацию, CI/CD и мониторинг.
Оценка результатов.
Оценка результатов команд в Architectural Katas должна быть объективной, структурированной и охватывать ключевые аспекты архитектурного проектирования. Для этого используются заранее определенные критерии с четкой системой баллов.
Критерии оценки
- Соответствие требованиям (25%)Учитываются функциональные и нефункциональные требования.
Насколько предложенное решение отвечает бизнес-кейсу.
Полнота охвата всех аспектов задания. - Качество архитектуры (30%)Логичность и ясность архитектурного решения.
Модульность и масштабируемость.
Выбор технологий и их обоснование.
Наличие резервирования и отказоустойчивости. - Управляемость и эксплуатация (15%)Учет аспектов DevOps (мониторинг, логирование, CI/CD).
Простота поддержки и расширения системы.
Наличие стратегий для обновления и миграции. - Учет рисков и ограничений (15%)Идентификация и анализ рисков.
Предложение стратегий по их снижению.
Учет временных и ресурсных ограничений. - Презентация решения (15%)Понятность и структурированность презентации.
Способность команды четко обосновать свои решения.
Умение отвечать на вопросы жюри.
Касательно презентации, там должно содержаться:
- Диаграммы (например, C4-модель: контекст, компоненты, контейнеры, коды).
- Сценарии отказов и стратегии восстановления.
- План внедрения и эксплуатации.
Система оценки
- Каждое из направлений оценивается по шкале от 1 до 10.
- Баллы умножаются на вес (в процентах) каждого критерия.
- Итоговый результат — сумма всех баллов.
Пример таблицы оценки:
- Баллы за креативность: команда может получить дополнительные баллы за нестандартные подходы.
- Награды за отдельные достижения: например, «Лучшая презентация» или «Самое инновационное решение».
- Звание/роли: победившая команда может получить титул "Архитекторы года".
Процесс оценки
- ЖюриКаждый член жюри выставляет оценки независимо.
Результаты усредняются для получения окончательного балла по каждому критерию. - Фидбек командам
После завершения оценки жюри предоставляет обратную связь:Что было сделано хорошо.
Какие аспекты можно улучшить.
Дополнительно
- Публикация критериев до начала соревнования: это помогает командам сфокусироваться на важных аспектах.
- Призы: даже символические награды мотивируют участников.
- Обсуждение решений: после соревнования можно организовать сессию обсуждения, чтобы все участники узнали сильные и слабые стороны обоих подходов.
Способы стимулирования взаимодействия между командами
- Перекрестные ревью: после проектирования команды могут обменяться решениями и дать друг другу фидбек перед презентацией жюри.
- Дополнительные задания или вызовы: Например, предложите каждой команде проанализировать архитектуру соперников на риски и предложить улучшения.