Бесплатный онлайн-курс Scrum Master Fundamentals

В первой лекции мы поговорим о том почему в мире разработки программного обеспечения появилось такое понятие как Agile.

Ответим на вопросы:

• Почему именно гибкий подход привлекает сейчас все больше последователей?
• И что именно означают принципы Agile манифеста и как их воплощать в жизнь на наших проектах?
• В каких случаях его следует использовать, а где можно обойтись другими методологиями.
• А также, расскажем (а кому-то напомним) ключевые элементы фреймворка Scrum, одной из самых распространенных реализаций принципов гибкой разработки. Расскажем о его основных ролях, активностях и артефактах.

Методология Scrum уделяет очень много внимания команде и правильному процессу организации ее работы.

Scrum-команда это, в первую очередь, самоорганизованная команда, где у каждого участника есть своя роль, обязанности и задачи.  И для работы с такими командами привычные подходы эффективно не работают. Какие именно правила и подходы предлагает Scrum для организации команд и выстраивания рабочих процессов мы разберем в этой лекции.

Краткое содержание:

• Какие роли предполагает Scrum команда?
• Какие обязанности предлагает каждая роль и как их оптимально внедрить?
• Как преобразовать существующую команду в Scrum или создать ее с нуля?
• Как понять, что ваша команда действительно Scrum и каким характеристикам она должна соответствовать?
• Как держать командные риски низкими с помощью «числа грузовика»?

Во времена, когда Agile и Scrum только появлялись на просторах Украины, многие ІТ специалисты были введены в заблуждение поверхностной простотой требований в Scrum и отсутствием многостраничных спецификаций. Так появился миф о том, что требований в Agile нет или что они не нужны. Но в действительности требования не только присутствуют, но и строятся по соответствующей иерархии и, собственно, полностью соответствуют требованиям гибкой, быстрой и ориентированной на ценности разработки программного обеспечения.

На нашем вебинаре мы:

• расскажем о том, кто ответственен за требования в Scrum команде;
• посмотрим с чего начинается работа с требованиями в Scrum;
• обсудим, что такое User Story и зачем использовать именно такой формат;
• поговорим о том, как правильно организовать требования и какая иерархия используется в гибких подходах;
• рассмотрим понятие Backlog (Беклогу), его приоритизации и правильного управления.

Оценка работы — ключевая составляющая любого процесса и методологии разработки. Именно правильная оценка позволяет спланировать дальнейшую работу над проектом или продуктом. Различные методологии используют различные меры для оценки продолжительности работ: человеко-час, story points, размеры футболок или даже фрукты. Как же правильно оценивать? И существует ли «правильно» вообще?

На этом вебинаре вы узнаете о том:

• почему в Agile и Scrum используют относительную оценку трудоемкости;
• как выглядит процесс оценки в относительных единицах и что такое Planning poker;
• что означают понятия Velocity i Capacity;
• и какая оценка применяется на различных уровнях планирования (релиз, спринт, день).

Планирование в Agile и Scrum представляет собой одну из главных отличий от классических методологий и, прежде всего, тем, что базируется на эмпирических данных, а не на пророчествах. Планирование в Scrum происходит на всех уровнях работы, начиная с уровня проекта или продукта и доходя до низкоуровневых технических задач.

В этом модуле мы более подробно рассмотрим:

• планирование в Scrum с точки зрения команды и Product Owner;
• использование Velocity и Capacity для планирования;
• принципы планирования на уровне релиза используя Minimal Marketable Product;
• и разные подходы к планированию релиза, основанные на бюджете, времени или объеме работ.

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

Мы расскажем о том:

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

А также объясним, как правильно выбирать продолжительность спринта или релиза на основе организационных расходов и гибкости технологий, которые вы используете.

Kaizen, или постоянное совершенствование – термин, пришедший к нам с производства, а именно, автостроения. Этот принцип позволяет проекту и команде настраивать свой процесс под нужды заказчика, а также, чтобы он максимально соответствовал тому, как команда хочет работать. Именно процесс постоянного улучшения делает Scrum такой успешной методологией, ведь с помощью этих изменений команда может сделать свою работу интересной, соответствующей ее интересам и интересам проекта.

На этом вебинаре мы подробно рассмотрим процессы:

• Sprint review и Демо;
• ретроспективы;
• как их проводить эффективно;
• как убедиться, что возникающие договоренности и улучшения, воплощаются и на самом деле приводят к совершенствованию.

Как и все большое, Scrum начинался с чего-то меньшего и на момент рождения обычно использовался в небольших проектах для работы над небольшими продуктами, соответственно, с помощью небольших команд. И, конечно, со временем, после того, как фреймворк приобрел популярность, появилась необходимость масштабировать на большие проекты и на большее количество команд.
В базовом описании Scrum guide не описывается, каким образом можно эффективно использовать Scrum на больших проектах. Так что наш вебинар призван рассказать, какие именно элементы нужно добавить, чтобы успешно работать при наличии нескольких команд.

В частности, поговорим о том:

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

И конечно, приправим это нашим опытом в использовании этих элементов и укажем на то, какие из них наиболее эффективны.

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

На этот сложный вопрос мы и будем отвечать на нашем вебинаре.

А также рассмотрим следующие темы:

• Как изменить свое мировоззрение и нужно ли это делать вообще?
• Какие плюсы и минусы «Agile mindset»?
• Как не превратить Agile в священную корову?

Что же поменялось в новом документе?

Во-первых, само руководство стало менее «нормативным». В новой версии создатели попытались вернуться к редакции, где меньше четких указаний, а сам Scrum сделать соответствующим определению «minimally sufficient framework».

Во-вторых, попытались устранить конфликт между «мы» как команда разработчиков и «они», т.е. РО. Сейчас будет одна Scrum Team, сфокусированная на единой цели. А к традиционным ролям SM и PO, вместо Development Teams, добавится роль Developers (кто угодно, кто работает над инкрементом спринта).

В-третьих, вводится концепт Product Goal. И каждый спринт теперь должен приближать продукт к Product Goal. Так же вводятся понятия Sprint Goal и Definition of Done.

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

В-пятых, Sprint Planning теперь фокусируется на 3-х вопросах: Что? Как? И зачем?