DevOps для Product Owner
На этом тренинге мы посмотрим на DevOps с точки зрения экономики, процесса и культуры, лишь слегка касаясь технических деталей в необходимом для понимания DevOps объеме.
Вы поймете, как продукт доходит до пользователя, почему не так быстро как вам бы хотелось и что с этим можно сделать.
Узнаете, какие инструменты из арсенала DevOps может использовать Product Owner и какие практики и как открывают новые возможности в исследовании поведения пользователей для принятия более осведомленных продуктовых решений.
Разберем ключевые препятствия при запуске DevOps-инициатив и как их устранить или снизить их негативное влияние.
Изначальная идея DevOps — сближение разработчиков и службы эксплуатации. То есть, с одной стороны — тех, чьей целью является развитие продукта, что потенциально снижает стабильность системы, а с другой — тех, кто головой отвечает за надежность и стабильность, из-за чего всячески изменениям сопротивляется.
Product Owner’у важно понимать концепции DevOps хотя бы потому, что в современном мире именно практики DevOps позволяют максимально эффективно повышать бизнес-показатели и одна из причин, по которой производительность IT коррелирует с производительностью бизнеса, заключается в том, что чем меньше время внесения изменений и чем выше частота развертываний, тем больше и чаще проходят эксперименты, направленные на поиск функциональности, увеличивающей доход.
Для кого:
- Product Owner
- Product Manager
- Project Manager
Программа:
- Что такое DevOps?
○ Выгоды DevOps
○ Рассчет DevOps ROI
○ Модель навыков и компетенций DevOps
○ Изменения в роли Product Owner - Как появляется работающий продукт?
○ Практика создания карты текущего потока создания технологической ценности
○ Практика создание Deployment Pipeline (конвейер поставки) - Что в DevOps значит «Работающий продукт»?
○ Практика формализации критериев готовности задач с точки зрения DevOps
○ Практика формулировки эксплуатационных (ops) требований - Как измерить эффективность процессов разработки и поставки продукта?
○ Практика поиска паттернов снижения эффективости и принятие решений на основе метрик потока создания ценности - Что снижает эффективность процессов разработки и поставки?
○ Практика выявления потерь; все дальнейшие практики будут направлены на устранение обозначенных потерь, что задает каркас для понимания DevOps - Как выглядит организационная структура DevOps-компании и как ее спроектировать?
○ Практика выявления влияния структуры и типов команд (продуктовые/компонентные/платформенные) на архитектуру, организацию рабочего процесса и процесс поставки через подход Team Topologies
○ Практика создание плана формирования внутреннего сообщества - Как сформировать DevOps-культуру в компании/команде?
○ Практика анализа существующей культуры и подбор организационных практик для интервенции в существующую систему с целью задания ей курса в сторону «производительной» (генеративной) по культуры по Рону Веструму
○ Совместный разбор модели трансформационного лидерства Рафферти и Гриффина, характерной для высокоэффективных команд и организаций - Какие возможности в развитии продукта открывают практики DevOps?
○ Применение шаблонов непрерывной интеграции к потоку создания технологической ценности для снижения T2M и повышения качества поставок
○ Применение шаблонов непрерывной поставки и отделение поставки от релиза для снижения T2M, сокращение времени на получение обратной связи от рынка и повышения гибкости в реакции на изменения рыночной ситуации
○ Использование стратегий поставки со сниженным риском для ускорения проверки продуктовых гипотез (Blue/Green, Canary Releases, A/B, Feature Toggles) - С чего начать в зависимости от типа продукта и организации?
Групповые скидки:
- От 2 до 4 участников - скидка 5%
- От 5 и больше участников - скидка 10%
Оплата тренинга возможна:
- По счету от юридического лица (выдается акт об оказании услуг)
- Банковской картой (выдается электронный кассовый чек)
Тренер
Сергей Баранов
Сергей имеет более чем 15-летний практически опыт в области проектирования и развития архитектур систем и управления продуктами различной степени сложности. В 15 лет написал первое коммерчески успешное приложение, что и послужило толчком к дальнейшему развитию. Долгое время проработал архитектором в проекте для Boeing, в котором были задействованы десятки систем и сотни людей. Был архитектором банковского многоканального решения, после чего занимался развитием направления по информационной безопасности в качестве консультанта.