Давно и успешно мы помогаем самым разным специалистам делиться собственными знаниями во всех возможных областях, в первую очередь – менеджменте и управлении, который становится все более актуален с течением времени. То же касается и разработки, проектирования и архитектуры.

Постепенно мы собрали ключевые техники проектирования из основных методологий и архитектурных стандартов и перевели на человеческий язык. Подключили наш собственный опыт и работающие решения наших многочисленных заказчиков, получив в итоге ряд занятий-тренингов. При этом формат их – практический, поэтому к большинству решений участники придут самостоятельно, что дает колоссальную конверсию навыков в применение на производстве.

Для кого:

Инженеров: архитекторов.
Техменеджеров: тимлидов и техлидов.
Менеджеров: проектных менеджеров и продуктовых менеджеров

Опыт на старте:

Желателен опыт промышленной разработки от 2 лет.
Обязательны навыки проектирования в объеме курса «Agile Mindset в проектировании систем», особенно для участия в продвинутом тренинге: «Agile Mindset в проектировании решений».

Разделив весь имеющийся опыт на две больших составляющих одного целого, картина следующая

Agile Mindset в проектировании систем. Требования, архитектура, процесс

Вспомните, когда в последний раз вам приходилось из последних сил доказывать преимущества архитектурного решения, но так и не достигнуть успеха? Или, когда вы с триумфом внедряли на первый взгляд абсолютно верное решение, терпящее в последствии полное фиаско. Подобные моменты порождают ряд справедливых вопросов: «Что я сделал не так? Как грамотно и логично преподнести свою точку зрения? В чем разница и где грань между осознанными и обоснованными архитектурными решениями и дилетантским подходом?»

Этот тренинг про здравый смысл – про обоснованность инженерных решений в условиях неопределённости. Мы разберем, от чего зависят инженерные решения и научимся четко обосновывать их. Задумаемся, какими должны быть ожидания от архитектуры и есть ли она вообще у вас в проекте. Научимся объективно решать инженерные конфликты, и вы навсегда забудете слово «холивар». Совершенно по-новому взглянем на шаблоны проектирования и теперь выжмем из них максимум. Поймем, как эффективно выстраивать документацию к системе, чтобы она действительно начала работать, а не была «write-only». Научимся фокусироваться в своих решениях и наконец-то выясним, с чего начинать – со схемы БД или «concurrency design». И одна из важнейших вещей тренинга – научимся не делать лишнюю работу.

Программа тренинга Agile Mindset в проектировании систем

Постановка проблем
Знакомство и сбор проблем участников
Обзор тренинга
Разбивка на команды
Зачем нужна архитектура – как не угробить проект
Что такое архитектура?
Где граница микро-дизайна и архитектуры?
Кто является потребителем архитектурных артефактов?
На какие ответы должна отвечать выбранная архитектура?
Архитектура как план рисков – компенсировать неопределенность будущего
Какие источники проектных рисков мы можем выделить?
Как на раних этапах можно адресовать внешние риски в своей архитектуре?
Как на раних этапах можно адресовать внутренние риски в своей архитектуре?
Границы системы и способы их фиксации
Архитектура как план проекта – повысить эффективность производства
Какие требования предъявляет к архитектуре PM/РП?
Как можно по архитектуре создать план проекта?
Видно ли критический путь?
Как параллелить работы?
Архитектура как требования к компонентам – обеспечить гибкость и снизить стоимость поддержки
На какие предположения мы опираемся при проектировании с использованием готовых компонентов или внешних систем?
Как можно сформулировать наши ожидания от внешних компонентов?
Как адресовать риски несоответствия нашим ожиданиям?
Требования к архитектуре: начало чеклиста – что не забыть и не упустить
Архитектурная методология – как принимать инженерные решения в пользу бизнес-потребностей и делать решения прозрачными для бизнеса
От чего зависят решения в дизайне и архитектуре? Где найти ответы, чтобы обосновать их?
Как компенсировать неопределенность требований?
Как обосновать решения по методологии?
Архитектура как функция от требований – как делать что нужно, снизить rework и повысить удовлетворенность клиентов
Какие виды требований можно выделить?
Как можно определить «критические пути» в требованиях?
Как требования определяют границы системы?
Какие знаете типовые преходы «профиль требований → типовая архитектура»?
Отдельно про масштабируемость
«Компромисс» и «Специализация» – как принимать решения в случае конструктивного конфликта ожиданий
В каком соответствии находятся требования?
Как инженерными решениями адресовать эти связи между требованиями?
Как относиться к шаблонам проектирования – их ценность и проблемы
Архитектурные точки зрения и документирование архитектуры – как тратить ресурсы сфокусированно и рано адресовать риски
В каком виде можно документировать архитектурные решения? Какие артефакты можно выдавать?
Что важнее – схема БД или concurrency design?
В какой момент документировать и что?
Требования к архитектуре: продолжение чеклиста
Архитектурная методология – как проектировать в условиях внешней неопределенности
Что вы делаете, если не знаете будущих изменений?
Оси вариативности требований
BDUF vs YAGNI
Инкапсуляция изменчивости
Архитектурная методология – как проектировать в условиях внутренней неопределенности
Ключевые ожидания к компонентам, исходя из требований
Ранние проверки ключевых контрактов
Внешняя и внутренняя экспертиза, каркасные прототипы
Тесты как ранняя проверка контракта
Требования к архитектуре: завершение чеклиста
Итоговая ретроспектива: что применить на производстве уже завтра

Agile Mindset в проектировании решений. Процесс, команда, культура, бизнес

Посмотрите на Вашу производственную систему поставки ПО и архитектуру решения. Вы можете четко обосновать выбор процессных и архитектурных подходов через бизнес-метрики и стратегию компании? То, как структурированы команды, как выстроены коммуникации и устроен архитектурный процесс – дает ли это нужные бизнесу метрики?

Этот тренинг – про проверенные индустрией архитектурные, процессные и оргструктурные шаблоны и их осмысленный выбор. То есть про то, как выстроить архитектурный процесс и структуру производства, чтобы адресовать потребности бизнеса.

Мы поймем, почему слишком ранняя или поздняя архитектура решения – боль и как её измерить и отслеживать её риски. Разберемся, как обеспечить качество продукта на ранних этапах. Научимся выстраивать процессы для снижения времени поставки без увеличения штата и как архитектура должна поддерживать такой процесс. Определим оптимальную структуру команды для повышения скорости поставки и качества продукта. Узнаем, какие факторы имеют важное значение для архитектуры, но мы их упорно игнорируем, собирая грабли.

Поймем, как бизнес-модель нашей компании поможет создавать и поддерживать архитектуру.

Программа тренинга Agile Mindset в проектировании решений

Постановка проблем
Знакомство и сбор проблем участников
Обзор тренинга
Разбивка на команды
Шаблоны зарождения и развития архитектуры – когда нужно и не нужно принимать решения
Метрики архитектуры и дизайна – как померить динамику изменений и «горячие» участки системы
Метрики
Польза от метрик
Sonar demo
Верификация и валидация архитектуры – как поставлять качественный продукт и узнавать о дефектах максимально рано
Архитектура как функция от процесса – как делать успешные проекты
Что такое процесс/методология?
Какие виды решений принимаются на этом уровне?
Как можно бороться с неопределенностью требований?
Как можно снизить cycle time?
Как можно переносить решения на исполнителей?
Как можно коллективно работать с кодовой базой?
Современные процессные шаблоны – на пути к инкрементальной архитектуре
Современные шаблоны проектного управления: матстат, теория реальных опционов, теория ограничений, снижение WIP
Взаимодействие ролей в проекте
Фрактальная природа проектов – почему мы ошибаемся в оценках
Множественные трассы сценариев
Архитектура как функция от структуры компании – как выстроить производственную систему для быстрой и качественной поставки
Матрица vs feature teams
Ахитектура как функция от модели управления командой – как выстроить коммуникации для быстрой и качественной поставки
Коллективное владение системой: шаблоны, в т.ч. DDD
Требования к архитектуре: продолжение чеклиста
Архитекутра как функция от унаследованных систем – Solution Architecture
Reuse
Специализация vs обощение
Роль документации и тестов
Гибкость в принятии архитектурных решений – что мы не учитываем, убивая проекты
От каких факторов зависят обоснованные инженерные решения?
Архитектура как функция от доверия менеджмента команде
Архитектура как функция от доверия команды менеджменту
Архитектура как функция от структуры компании
Архитектура как функция от партнеров
Архитектура как функция от корпоративной политики
Требования к архитектуре: продолжение чеклиста
Архитектура как функция от бизнес-модели компании – как архитектурой помогать бизнесу добиваться результатов
Какие бизнес-метрики бывают?
Какие бизнес-модели бывают?
Требования к архитектуре: завершение чеклиста
Итоговая ретроспектива: что применить на производстве уже завтра

Результаты и полученный опыт/экспертиза по результатам тренинга

После тренинга участники смогут:

Вовремя принимать архитектурные решения – не раньше и не позже, тем самым оптимизируя стоимость и риски проекта
«Ставить диагноз по фотографии» – по архитектурным метрикам понимать статус проекта и архитектурные риски
Осмысленно выбирать инструменты проверки архитектуры – максимально рано и без лишних затрат обеспечивать качество продукта
Настраивать процесс, обеспечивая минимальное время поставки
Настраивать структуру команды и коммуникации, резко улучшая скорость и качество принятия иненерных решений
Снижать стоимость новых решений за счет эффективного переиспользования существующих систем
Лучше понимать бизнес-решения топ-менеджмента и обеспечивать поддержку бизнес-стратегии в архитектуре систем
Проинспектировать существующую архитектуру на предмет соответствия бизнес-задачам и стратегии – выбрать ключевые точки для скорейшего рефакторинга
Обоснованно принимать архитектурные решения и аргументированно отстаивать их
Обеспечить необходимую архитектурную гибкость
Снизить текущие затраты за счет четкой фокусировки на действительно важных вопросах
Снизить затраты и риски будущей поддержки
Легко и эффективно разрешать инженерные конфликты – без ругани, обид и драм
Обоснованно принимать инженерные решения в условиях неопределенности – когда непонятно до конца, что и как делать
Ускорить поставку за счет осмысленного параллелизма работ
Понимать потребности и образ мышления бизнеса – давать бизнесу действительно нужную ему информацию о статусе проекта
Минимальными усилиями перестроить процесс производства для снижения времени поставки и повышения качества

Тренер: Евгений Кривошеев
Имеет семилетний опыт разработки и преподавания технологий на платформах J2SE, J2EE, BEA Systems, IBM, равно как и параллельной разработки. Его опыт позволяет выступать архитектором при разработке крупных коммерческих систем, при этом он способен донести сложные технологические знания самому широкому кругу.

Несколько простых вопросов, касаемо потенциала и стимула к участию в тренинге, Евгению Кривошееву:

— Евгений, кто целевая аудитория инженерных тренингов Agile Mindset в общем, какие специалисты почерпнут из него максимум возможного?

Наши тренинги рассчитаны на средних (regular) разработчиков и более прокачанных специалистов.

Младшим разработчикам тренинг также может быть интересен, но после ознакомления с основами Agile. Второй тренинг, посвященный уже не архитектурам, а конкретным процессам и бизнес-моделям, скорее всего, для джуниора будет сложноват, так как рассчитан он даже не на старших разработчиков, а на архитекторов и PM’ов с опытом разработки.

Так или иначе, суть двух тренингов заключается именно в установке «сквозных» правил для разработчиков, архитекторов, руководителей проекта, ресурсных менеджеров, продуктовых менеджеров и даже, может быть, владельцев. Делается это для получения единой модели принятия решений.

Цель также в том, чтобы инженерия помогала бизнесу, а не мешала. Помогала развиваться, зарабатывать больше денег и решать другие задачи: снижение времени поставки (time-to-market), повышение её предсказуемости и улучшение качества системы.
Для этого критически важно, чтобы инженеры услышали бизнес, а бизнес с готовностью отвечал на вопросы инженеров

Как конкретно принимать инженерные решения? Как строить архитектуру? Как коммуницировать? Именно на эти вопросы призваны ответить и помочь найти решение оба тренинга.

— Какими практическими навыками или методиками можно овладеть в ходе тренинга?

Самое главное – это навыки коммуникации. В ходе тренинга мы учимся общаться на едином языке и понимать то, чем руководствуются другие роли в процессе архитектурного проектирования. Большая часть проблем софтверной инженерии, на наш взгляд, упирается в первую очередь в коммуникацию: роли друг друга не слышат, оперируют различными понятиями, не выходят за рамки «операционных стен».

Второй навык — это конкретный набор приемов и паттернов проектирования систем. Эти навыки могут быть процессными и инженерными.

Как выстраивать работу и архитектуру в постоянно изменяющемся потоке требований? Для этого нужна методологическая поддержка (что?) и конкретные инженерные решения (как?)

— Почему Agile Mindset как «установка ума», и как эта установка помогает в проектировании масштабных архитектур?

Весь этот срез реально существующего мира делится на две, достаточно крупных, части: мир формальных или последовательных методологий и процессов и мир гибких методологий и процессов (меньше формальных изначальных установок, больше реакции на происходящее в реальном времени).

Выгода для участников выражена в следующей метафоре: «Наконец-то задачи будут делаться!». Формальные и последовательные подходы подразумевают большой цикл обратной связи – между задумкой и внедрением проходит много времени, много сил тратиться на коммуникацию и преодоление разнообразных барьеров: бюрократических, коммуникационных, возможно и организационных.
Что важно в мире гибких методологий? Сравнительно небольшой цикл обратной связи с разработчиком. Работник видит, что результат его работы быстро внедряется и способствует положительной мотивации всей команды в целом.

Приходите и внедряйте здравый смысл в своей компании!

Настройка ума на частоту Agile