Настройка ума на частоту Agile
Давно и успешно мы помогаем самым разным специалистам делиться собственными знаниями во всех возможных областях, в первую очередь – менеджменте и управлении, который становится все более актуален с течением времени. То же касается и разработки, проектирования и архитектуры.
Постепенно мы собрали ключевые техники проектирования из основных методологий и архитектурных стандартов и перевели на человеческий язык. Подключили наш собственный опыт и работающие решения наших многочисленных заказчиков, получив в итоге ряд занятий-тренингов. При этом формат их – практический, поэтому к большинству решений участники придут самостоятельно, что дает колоссальную конверсию навыков в применение на производстве.
Для кого:
- Инженеров: архитекторов.
- Техменеджеров: тимлидов и техлидов.
- Менеджеров: проектных менеджеров и продуктовых менеджеров
Опыт на старте:
- Желателен опыт промышленной разработки от 2 лет.
- Обязательны навыки проектирования в объеме курса «Agile Mindset в проектировании систем», особенно для участия в продвинутом тренинге: «Agile Mindset в проектировании решений».
Разделив весь имеющийся опыт на две больших составляющих одного целого, картина следующая
Agile Mindset в проектировании систем. Требования, архитектура, процесс
Вспомните, когда в последний раз вам приходилось из последних сил доказывать преимущества архитектурного решения, но так и не достигнуть успеха? Или, когда вы с триумфом внедряли на первый взгляд абсолютно верное решение, терпящее в последствии полное фиаско. Подобные моменты порождают ряд справедливых вопросов: «Что я сделал не так? Как грамотно и логично преподнести свою точку зрения? В чем разница и где грань между осознанными и обоснованными архитектурными решениями и дилетантским подходом?»
Этот тренинг про здравый смысл – про обоснованность инженерных решений в условиях неопределённости. Мы разберем, от чего зависят инженерные решения и научимся четко обосновывать их. Задумаемся, какими должны быть ожидания от архитектуры и есть ли она вообще у вас в проекте. Научимся объективно решать инженерные конфликты, и вы навсегда забудете слово «холивар». Совершенно по-новому взглянем на шаблоны проектирования и теперь выжмем из них максимум. Поймем, как эффективно выстраивать документацию к системе, чтобы она действительно начала работать, а не была «write-only». Научимся фокусироваться в своих решениях и наконец-то выясним, с чего начинать – со схемы БД или «concurrency design». И одна из важнейших вещей тренинга – научимся не делать лишнюю работу.
- Постановка проблем
- Знакомство и сбор проблем участников
- Обзор тренинга
- Разбивка на команды
- Зачем нужна архитектура – как не угробить проект
- Что такое архитектура?
- Где граница микро-дизайна и архитектуры?
- Кто является потребителем архитектурных артефактов?
- На какие ответы должна отвечать выбранная архитектура?
- Архитектура как план рисков – компенсировать неопределенность будущего
- Какие источники проектных рисков мы можем выделить?
- Как на раних этапах можно адресовать внешние риски в своей архитектуре?
- Как на раних этапах можно адресовать внутренние риски в своей архитектуре?
- Границы системы и способы их фиксации
- Архитектура как план проекта – повысить эффективность производства
- Какие требования предъявляет к архитектуре PM/РП?
- Как можно по архитектуре создать план проекта?
- Видно ли критический путь?
- Как параллелить работы?
- Архитектура как требования к компонентам – обеспечить гибкость и снизить стоимость поддержки
- На какие предположения мы опираемся при проектировании с использованием готовых компонентов или внешних систем?
- Как можно сформулировать наши ожидания от внешних компонентов?
- Как адресовать риски несоответствия нашим ожиданиям?
- Требования к архитектуре: начало чеклиста – что не забыть и не упустить
- Архитектурная методология – как принимать инженерные решения в пользу бизнес-потребностей и делать решения прозрачными для бизнеса
- От чего зависят решения в дизайне и архитектуре? Где найти ответы, чтобы обосновать их?
- Как компенсировать неопределенность требований?
- Как обосновать решения по методологии?
- Архитектура как функция от требований – как делать что нужно, снизить rework и повысить удовлетворенность клиентов
- Какие виды требований можно выделить?
- Как можно определить «критические пути» в требованиях?
- Как требования определяют границы системы?
- Какие знаете типовые преходы «профиль требований → типовая архитектура»?
- Отдельно про масштабируемость
- «Компромисс» и «Специализация» – как принимать решения в случае конструктивного конфликта ожиданий
- В каком соответствии находятся требования?
- Как инженерными решениями адресовать эти связи между требованиями?
- Как относиться к шаблонам проектирования – их ценность и проблемы
- Архитектурные точки зрения и документирование архитектуры – как тратить ресурсы сфокусированно и рано адресовать риски
- В каком виде можно документировать архитектурные решения? Какие артефакты можно выдавать?
- Что важнее – схема БД или concurrency design?
- В какой момент документировать и что?
- Требования к архитектуре: продолжение чеклиста
- Архитектурная методология – как проектировать в условиях внешней неопределенности
- Что вы делаете, если не знаете будущих изменений?
- Оси вариативности требований
- BDUF vs YAGNI
- Инкапсуляция изменчивости
- Архитектурная методология – как проектировать в условиях внутренней неопределенности
- Ключевые ожидания к компонентам, исходя из требований
- Ранние проверки ключевых контрактов
- Внешняя и внутренняя экспертиза, каркасные прототипы
- Тесты как ранняя проверка контракта
- Требования к архитектуре: завершение чеклиста
- Итоговая ретроспектива: что применить на производстве уже завтра
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 как «установка ума», и как эта установка помогает в проектировании масштабных архитектур?
Весь этот срез реально существующего мира делится на две, достаточно крупных, части: мир формальных или последовательных методологий и процессов и мир гибких методологий и процессов (меньше формальных изначальных установок, больше реакции на происходящее в реальном времени).
Выгода для участников выражена в следующей метафоре: «Наконец-то задачи будут делаться!». Формальные и последовательные подходы подразумевают большой цикл обратной связи – между задумкой и внедрением проходит много времени, много сил тратиться на коммуникацию и преодоление разнообразных барьеров: бюрократических, коммуникационных, возможно и организационных.
Что важно в мире гибких методологий? Сравнительно небольшой цикл обратной связи с разработчиком. Работник видит, что результат его работы быстро внедряется и способствует положительной мотивации всей команды в целом.
Приходите и внедряйте здравый смысл в своей компании!
Автор: Tsybdenova