/architecture-agile-mindset

Воркшоп «Agile Mindset в проектировании информационных и производственных систем» 32hrs

Agile Mindset в проектировании систем. (3 дня)

Архитектурный agile mindset – это обоснованность инженерных решений плюс инструменты работы с неопределённостью.

Ожидания от аудитории

  • Доступ к github.com

Программа

Знакомство (0.5)

  • Контекст: потребность формировать и развивать функцию системной архитектуры и сообщество
  • Формат: 10:00 – 15:00
  • Перерывы: 10:50 – 11:05, 12:00 – 13:00, 13:50 – 14:05
  • Материалы
  • Обзор тренинга
  • Разбивка на команды (по трое)
  • Знакомство и сбор проблем участников

Зачем нужна архитектура – как не угробить проект, продукт, компанию? (1)

  • Что такое архитектура?
  • Где граница дизайна, микро-дизайна и архитектуры?
  • Кто является потребителем архитектурных артефактов? (PoV)
  • На какие вопросы должна отвечать выбранная архитектура?

Кто порождает архитектурные решения? (0.5)

Архитектурный чек-лист (0.5)

  • Пример из SEMAT
  • Начинаем описание DoD
  • Неявная тренировка time boxing и инкрементальной работы (при обсуждении результата командами)
  • Критерии чеклиста:
  • отчуждаемость от авторов
  • декларативность
  • приземленность на специфику вашего конкретного проекта
  • Сценарий "архитектор уезжает в отпуск"

Архитектура как план адресации проектных рисков – как компенсировать неопределенность будущего? (1)

  • Какие требования предъявляет к архитектуре PM/РП?
  • Какие источники проектных рисков мы можем выделить?
  • Как можно по архитектуре создать план проекта?
  • Как на ранних этапах можно адресовать внешние риски в своей архитектуре?
  • Как на ранних этапах можно адресовать внутренние риски в своей архитектуре?
  • Границы системы и способы их фиксации – кто возьмет на себя риски
  • Параллельность работ и критический путь
  • Архитектор определяет границы будущего

Архитектурный чек-лист

  • Продолжаем описание DoD

Архитектурные точки зрения и документирование архитектуры – как тратить ресурсы сфокусированно и рано адресовать риски? (1)

  • Какую картинку видите при слове «архитектура»?
  • Что важнее – схема БД или concurrency design?
  • Примеры: 4+1, модель Захмана, ArchiMate, Rozansky&Woods, C4
  • Какие еще PoV можете выделить?
  • В каком виде можно документировать архитектурные решения? Какие артефакты можно выдавать?
  • Как увидеть характеристики за диаграммами в PoV
  • Типовые PoV

Архитектурный чек-лист

  • Продолжаем описание DoD

Архитектура как требования к компонентам – как обеспечить гибкость и снизить стоимость поддержки? (1)

  • Принятые термины: модуль=функция, компонент=конструкция, размещение, время
  • На какие предположения мы опираемся при проектировании с использованием готовых компонентов или внешних систем?
  • Как можно сформулировать наши ожидания от внешних компонентов?
  • Как адресовать риски несоответствия нашим ожиданиям?
  • Инкрементальная архитектура через заглушки

Архитектурный чек-лист

  • Продолжаем описание DoD

Системная инженерия: как принимать обоснованные и прозрачные для бизнеса инженерные решения? (1)

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: архитектура как функция от требований – как делать что нужно, снизить rework и повысить удовлетворенность клиентов? (1)

  • Какие виды требований можно выделить?
  • Как можно определить «критические пути» в требованиях?
  • Как требования определяют границы системы?
  • Какие знаете типовые переходы «профиль требований → типовая архитектура»?
  • Отдельно про масштабируемость
  • Типовые профили: «High-Load», учетные и интеграционные системы. Характерные риски.
  • Отдельно про внутренние требования. Фитнес-функция.

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Как принимать решения в случае конструктивного конфликта требований? (1)

  • В каком соответствии находятся требования?
  • Как инженерными решениями адресовать эти связи между требованиями?
  • «Trade-off», «Специализация», «Компромисс»
  • Как относиться к шаблонам проектирования – их ценность и проблемы

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: как проектировать в условиях внешней неопределенности (требований)? (1)

  • Что вы делаете, если не знаете что делать: требований сейчас и будущих изменений?
  • Как меняется внутренняя модель качества?
  • Процесс: BDUF vs YAGNI/KISS/Emergent design
  • Инкапсуляция изменчивости
  • Lean SWD: делегируй и откладывай
  • Все уже придумано до нас: Cynefin Framework
  • Поставки инкрементально vs итеративно
  • Шаблоны декомпозиции требований: по сценариям и по шагам
  • Процесс: Формальные vs самоорганизованные компании
  • Процесс: Кросс-фунциональность и T-shaping

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: как проектировать в условиях внутренней неопределенности (решения)? (1)

  • Что вы делаете, если не знаете, как делать?
  • Процесс: Формальные vs самоорганизованные компании
  • Ключевые ожидания к компонентам, исходя из требований

Работа с инженерными гипотезами

  • Ранние проверки ключевых контрактов
  • Внешняя и внутренняя экспертиза
  • Тесты как ранняя проверка контракта

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: архитектура как функция от производственной системы (1)

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: архитектура как функция от культуры компании – как проектировать без сопротивления? (1)

Культура

  • Как мы ведем себя, когда никто не видит, “дефолтное” поведение?
  • Прокликаете ли фичу, даже если нет четкого указания?
  • Культуры по Шнайдеру
  • Самовоспроизводство культуры
  • Управление культурой

Культурный аспект: совместная деятельность - коммуникации и ответственности

  • Роли (деятельности) четко сфокусированы на участниках?
  • Или роли (деятельности) "размазаны" по участникам?
  • Раздеялем роль/деятельность/функцию и должность и участника команды
  • В гибких компаниях какой подход более производителен?

Архитектурный чек-лист

  • A = F(?)
  • Продолжаем описание DoD

Системная инженерия: архитектура как функция от бизнес-модели (1)

  • Как бизнес может зарабатывать на IT?
  • Зачем система нужна бизнесу?
  • Какие потоки ("валют") можете выделить в процессе бизнес-деятельности?

Как мы заработаываем валюты - контрактные модели

  • Fix-price/scope/time vs T&M
  • Проекты vs Сервис

Шаблоны бизнес-моделей:

  • Зарабатывать самим vs Развитие под поглощение
  • B2C vs B2B vs B2G
  • Стартап vs Зрелая
  • Заказ vs Продукт
  • Outsource vs In-house

Частные бизнес-модели

Архитектурный чек-лист

  • A = F(?)
  • Какие метрики процесса ожидает бизнес?
  • Продолжаем описание DoD

Гибкость в принятии архитектурных решений – что еще мы не учитываем, убивая проекты и продукты? (1)

  • Архитектура как функция от доверия менеджмента команде
  • Архитектура как функция от доверия команды менеджменту
  • Архитектура как функция от структуры компании
  • Архитектура как функция от партнеров
  • Архитектура как функция от корпоративной политики

Архитектура как функция от унаследованных систем: Solution Architecture

  • Reuse
  • Специализация vs обобщение
  • Роль документации и тестов

Recap: Характер agile design и ожидания от производственной системы (0.5)

Характер современной продуктовой разработки: recap

  • Неопределённость
  • Инновационность
  • Тиражируемость
  • Воспроизводимость конкурентами
  • Снижение лояльности клиентов

Agile Design: recap

  • "Марафон", сервис для бизнеса
  • Четко обоснованный – сфокусированный на бизнес-результате
  • Результат открытого честного общения
  • Архитектурная деятельность размыта по команде
  • Time-boxed
  • Инкрементальный
  • Известные риски адресованы рано, реализация отложенная
  • Не делаем «в пустоту»
  • Четкое понимание, кому и зачем передается работа дальше
  • Характерная для сервисных отношений модель внутреннего качества

Манифестируем себя как продуктовые agile команды

  • Какую производственную структуру выберете?
  • Какую культуру манифестируете бизнесу?
  • Какие метрики своего процесса манифестируете бизнесу?

Итоговая ретроспектива: что применить на производстве уже завтра (0.5)