Training “Agile Mindset in systems design. Requirements, architecture, process.”
Инженерный agile mindset – это бизнес-обоснованность инженерии плюс частые поставки just in time.
Вспомните, когда в последний раз Вам приходилось из последних сил доказывать преимущества архитектурного решения, но так и не достигнуть успеха. Или когда вы с триумфом внедряли на первый взгляд абсолютно верное решение, терпящее в последствии полное фиаско. Подобные моменты порождают ряд справедливых вопросов: «Что я сделал не так? Как грамотно и логично преподнести свою точку зрения? В чем разница и где грань между осознанными и обоснованными архитектурными решениями и дилетантским подходом?»
Этот тренинг про здравый смысл – про обоснованность инженерных решений в условиях неопределенности. Мы разберем, от чего зависят инженерные решения и научимся четко обосновывать их. Задумаемся, какими должны быть ожидания от архитектутры и есть ли она вообще у Вас в проекте. Научимся объективно решать инженерные конфликты, и Вы навсегда забудете слово «холивар». Совершенно по-новому взглянем на шаблоны проектирования и теперь выжмем из них максимум. Поймем, как эффективно выстраивать документацию к системе, чтобы она действительно начала работать, а не была write-only. Научимся фокусироваться в своих решениях и наконец-то выясним, с чего начинать – со схемы БД или concurrency design. И одна из важнейших вещей тренинга – научимся не делать лишнюю работу. Мы научимся сжимать архитектурный этап без потери качества, чтобы как можно быстрее начать поставки.
Поэтому если Вы замучились от неполноты и изменчивости требований, от накопившегося технического долга, от бесконечных холиваров и вообще непонятно, что этот бизнес от Вас хочет – этот тренинг для Вас.
Для кого
- Для инженеров: архитекторов и разработчиков.
- Для техменеджеров: тимлидов и техлидов.
- Для менеджеров: проектных менеджеров и продуктовых менеджеров
Опыт на старте
- Ожидаемый уровень участников: базовый и уверенный.
- Желателен опыт промышленной разработки от 1 года.
После тренинга участники смогут
- Проинспектировать существующую архитектуру на предмет соответствия бизнес-задачам и стратегии – выбрать ключевые точки для скорейшего рефакторинга
- Обоснованно принимать архитектурные решения и аргументированно отстаивать их
- Обеспечить необходимую архитектурную гибкость
- Снизить текущие затраты за счет четкой фокусировки на действительно важных вопросах
- Снизить затраты и риски будущей поддержки
- Легко и эффективно разрешать инженерные конфликты – без ругани, обид и драм
- Обоснованно принимать инженерные решения в условиях неопределенности – когда непонятно до конца, что и как делать
- Ускорить поставку за счет осмысленного параллелизма работ
- Понимать потребности и образ мышления бизнеса – давать бизнесу действительно нужную ему информацию о статусе проекта
- Минимальными усилиями перестроить процесс производства для снижения времени поставки и повышения качества
Программа
- Постановка проблем
- Знакомство и сбор проблем участников
- Обзор тренинга
- Разбивка на команды
- Зачем нужна архитектура – как не угробить проект
- Что такое архитектура?
- Где граница микро-дизайна и архитектуры?
- Кто является потребителем архитектурных артефактов?
- На какие ответы должна отвечать выбранная архитектура?
- Архитектура как план рисков – компенсировать неопределенность будущего
- Какие источники проектных рисков мы можем выделить?
- Как на ранних этапах можно адресовать внешние риски в своей архитектуре?
- Как на ранних этапах можно адресовать внутренние риски в своей архитектуре?
- Границы системы и способы их фиксации
- Архитектура как план проекта – повысить эффективность производства
- Какие требования предъявляет к архитектуре PM/РП?
- Как можно по архитектуре создать план проекта?
- Видно ли критический путь?
- Как распараллелить работы?
- Архитектура как требования к компонентам – обеспечить гибкость и снизить стоимость поддержки
- На какие предположения мы опираемся при проектировании с использованием готовых компонентов или внешних систем?
- Как можно сформулировать наши ожидания от внешних компонентов?
- Как адресовать риски несоответствия нашим ожиданиям?
- Требования к архитектуре: начало чеклиста – что не забыть и не упустить
- Архитектурная методология – как принимать инженерные решения в пользу бизнес-потребностей и делать решения прозрачными для бизнеса
- От чего зависят решения в дизайне и архитектуре? Где найти ответы, чтобы обосновать их?
- Как компенсировать неопределенность требований?
- Как обосновать решения по методологии?
- Архитектура как функция от требований – как делать что нужно, снизить rework и повысить удовлетворенность клиентов
- Какие виды требований можно выделить?
- Как можно определить «критические пути» в требованиях?
- Как требования определяют границы системы?
- Какие знаете типовые переходы «профиль требований → типовая архитектура»?
- Отдельно про масштабируемость
- «Компромисс» и «Специализация» – как принимать решения в случае конструктивного конфликта ожиданий
- В каком соответствии находятся требования?
- Как инженерными решениями адресовать эти связи между требованиями?
- Как относиться к шаблонам проектирования – их ценность и проблемы
- Архитектурные точки зрения и документирование архитектуры – как тратить ресурсы сфокусированно и рано адресовать риски
- В каком виде можно документировать архитектурные решения? Какие артефакты можно выдавать?
- Что важнее – схема БД или concurrency design?
- В какой момент документировать и что?
- Требования к архитектуре: продолжение чеклиста
- Что бизнес хочет от архитектуры?
- Как начать поставлять быстрее?
- Сжатие архитектурного этапа без потери качества
- Архитектурная методология – как проектировать в условиях внешней неопределенности
- Что вы делаете, если не знаете будущих изменений?
- Оси вариативности требований
- BDUF vs YAGNI
- Инкапсуляция изменчивости
- Архитектурная методология – как проектировать в условиях внутренней неопределенности
- Ключевые ожидания к компонентам, исходя из требований
- Ранние проверки ключевых контрактов
- Внешняя и внутренняя экспертиза, каркасные прототипы
- Тесты как ранняя проверка контракта
- Требования к архитектуре: завершение чеклиста
- Итоговая ретроспектива: что применить на производстве уже завтра
В чем отличие от других тренингов по архитектуре и проектированию в Agile
Мы собрали ключевые техники проектирования из основных методологий и архитектурных стандартов и перевели на человеческий язык. Подключили наш собственный опыт и работающие решения наших многочисленных заказчиков.
При этом формат тренинга – практический, поэтому к большинству решений участники придут самостоятельно, что дает колоссальную конверсию навыков в применение на производстве. В итоге участники смогут начать поставлять ПО гораздо быстрее без потери качества.
Фокус на том, как сократить время поставок без потери качества, чтобы разработка и бизнес как можно скорее получили ценность от системы.