Training “Agile Mindset in systems design. Requirements, architecture, process.”
Eugene Krivosheyev

Eugene Krivosheyev

SkillTrek, Russia

Eugene helps Russia IT companies from TOP-50 to become more flexible and effective. He supports Agile processes from bottom to top, implementing engineering practices and good approaches to design/architecture. At the moment involved into SkillTrek project, where he trains engineers for practical skills in real-life projects.

Speaker's activity

Training “Agile Mindset in systems design. Requirements, architecture, process.”

October 21-22nd

9:30 - 18:30

Training

Russian

6000 hrn ($250)

Инженерный agile mindset – это бизнес-обоснованность инженерии плюс частые поставки just in time.

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

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

Для кого

  • Для инженеров: архитекторов и разработчиков.
  • Для техменеджеров: тимлидов и техлидов.
  • Для менеджеров: проектных менеджеров и продуктовых менеджеров

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

  • Ожидаемый уровень участников: базовый и уверенный.
  • Желателен опыт промышленной разработки от 1 года.

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

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

Программа

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

В чем отличие от других тренингов по архитектуре и проектированию в Agile

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

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