Фреймворк Scrum Основные понятия фреймворка Преимущества и недостатки фреймворка Артефакты Scrum Роли в Scrum Event - ы в Scrum Работа с Backlog. Приоритезация задач Планирование и мониторинг спринта Выбор методологии для проекта: Подходы Рекомендации

1. Управление проектами. Модуль 2.

2. Лекция 11-12
Фреймворк Scrum
● Основные понятия фреймворка
● Преимущества и недостатки фреймворка
● АртефактыScrum
● Роли в Scrum
● Event - ы в Scrum
● Работа с Backlog. Приоритезация задач
● Планированиеи мониторингспринта
Выбор методологии для проекта:
● Подходы
● Рекомендации

3. Основные понятия фреймворка
Scrum (сущ.) — это фреймворк, который помогает решать
изменяющиеся в процессе работы задачи, чтобы продуктивно и
творчески поставлять клиентам продукты с максимально
возможной ценностью.
Скрам является:
• компактным,
• простым для понимания,
• трудным для совершенного овладения
Основными элементами фреймворка являются Скрам-команды и
связанные с ними роли, события, артефакты и правила. Каждый
элемент фреймворка служит определенной цели и является
обязательным для успешного использования Скрама.
Девиз Скрама - "FAIL EARLY"

4. Применение Scrum
Скрам был изначально разработан для управления продуктами и их
разработки. С начала девяностых Скрам активно используется по всему
миру,чтобы:
1) исследовать и выявлять жизнеспособные рынки, технологии и
возможности продуктов;
2) разрабатыватьпродукты и улучшать их;
3) выпускатьпродуктыи их обновленияпо несколькораз в день;
4) разрабатывать и поддерживать облачные технологии (онлайн,
безопасно, по требованию) и другие среды для использования
продуктов;
5) поддерживатьи обновлятьпродукты.
Скрам применялся для разработки программного обеспечения,
оборудования, встроенного программного обеспечения, автономных
транспортных средств и микробиологических исследований. Скрам
использовался в школах, правительстве, маркетинге, в управлении
организациями— повсеместно вжизни отдельныхлюдейи сообществ

5. Теория Scrum
Скрам основан на теории эмпирического управления
(эмпиризме).Согласно этой теории, источникомзнаний
являетсяопыт, а источником решений – реальныеданные.
Скрам использует итеративный и инкрементный подход,
чтобы улучшатьпрогнозируемость и управлять рисками.
Процесс эмпирического
управленияоснован
на «трех китах»:
● прозрачности
● инспекции
● адаптации

6. Scrum Framework
● Практики Скрама (Events):
● Ежедневные митинги
● Игра в планирование
● Демо – презентация
● Ретроспектива
● Роли в Скраме (Scrum Team)
● Скрам мастер
● Владелец продукта
● Команда разработки
● Скрам Артефакты
● Беклог продукта
● Беклог спринта (итерации)
● Диаграмма сгорания

7. Scrum Roles
Владелец продукта (Product Owner)-это человек, отвечающий за
разработку продукта. Как правило, это product manager для
продуктовой разработки, менеджер проекта для внутренней
разработки и представитель заказчика для заказной разработки.
Product Owner – это единая точка принятия окончательных
решений для команды в проекте, именно поэтому это всегда
один человек, а не группа или комитет. Обязанности Product
Owner таковы:
● представляет интересы stakeholders , коммуницирует
требования продукта
● один человек, который создает и приоритезирует Product
Backlog
● Выбирает цели ( из Product Backlog) для следующего спринта
● Ответственный за обеспечение того, что самые главные
бизнес ценности разрабатываются в первую очередь
● Вместе с остальными stakeholders, участвует в Srpint Review

8. Scrum Roles
Скрам-мастер ( Scrum Master)-самая важная роль в методологии.
Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам
Мастер является интерфейсом между менеджментом и
командой. Как правило, эту роль в проекте играет менеджер
проекта или тимлид. Важно подчеркнуть,что Скрам Мастер не
раздает задачи членам команды. В Agile команда является
самоорганизующейся и самоуправляемой. Основные
обязанности Скрам Мастера:
● обеспечивает выполнение скрам-практик
● управляет daily stand-up
● главная работа - убирать препятствия
● посредник между менеджментом и скрам- командой
● брандмауэр (firewall) - обеспечивает спокойную работу
команды, контролирует, чтобы не поступали запросы извне
● фасилитатор, но не менеджер
● создает атмосферу доверия

9. Scrum Roles
Команда разарботки ( Devlopment Team)- в методологии Scrum
команда является самоорганизующейся и самоуправляемой.
Команда берет на себя обязательства по выполнению объема
работ на спринт перед Product Owner. Работа команды
оценивается как работа единой группы. В Scrum вклад отдельных
членов проектной команды не оценивается, так как это
разваливает самоорганизацию команды. Обязанности команды
таковы:
● кросс функциональная
● идеально 6+ /- 3 человека
● содержит инициативных разработчиков
● устанавливает цели каждого спринта вместе с Product Owner
● самоорганизующаяся и самодисциплинированная
● делает все необходимое для достижения цели
● отслеживает собственный прогресс вместе со Scrum Master
● отвечает за результат перед Product Owner

10. Scrum Artefacts
Бэклог продукта ( Product Backlog)- это приоритезированный
список имеющихся на данный момент бизнес требований и
технических требований к системе. Обычно состоит из user stories
(пользовательские истории) Product Backlog постоянно
пересматривается и дополняется – в него включаются новые
требования, удаляются ненужные, пересматриваются приоритеты.
Содержит в себе:
● список требований
● список всех "хотелок" проекта
● в идеале, он должен выражать какую ценность несет каждая
задача для пользователя или заказчика продукта
● приоритезирует Product Owner
● приоритеты должны пересматриваться перед каждым
спринтом
● отслеживать прогресс можно с помощью Burndown chart

11. Scrum Artefacts
Бэклог спринта ( Sprint Backlog) — это набор элементов Бэклога,
взятых в Спринт, плюс план по достижению цели спринта и
поставке инкремента продукта. Бэклог Спринта — это прогноз
команды разработки о том, какая функциональность войдет в
следующий инкремент и какая работа необходима для создания
готового инкремента. Бэклог Спринта отражает весь объем работ,
который команда разработки считает необходимым для
достижения Цели Спринта.
Sprint Backlog:
● принадлежит команде
● содержит оценку , установленную командой
● зависит от производительности команды (velocity)
● изменять бэклог спринта может только команда разработки
● отслеживать прогресс можно с помощью Burndown chart

12. Scrum Artefacts
Инкремент ( Increment)— это сумма завершенных во время
cпринта элементов Бэклога Продукта и всех инкрементов
предыдущих cпринтов. К концу спринта Инкремент должен быть
«Готов», что подразумевает его соответствие критериям готовности
Скрам-команды и готовность к использованию.
Инкремент — это совокупность выполненных работ, которая
поддерживает эмпирический подход и которую можно
инспектировать в конце спринта. Можно сказать, что это шаг на
пути к видению или цели.
Он должен быть готов к использованию вне зависимости от
положительного или отрицательного решения Product Owner о его
выпуске.

13. Scrum Events
Спринт ( Sprint)— служитядром скрама. Спринт —
временной отрезок длительностью месяцили меньше, в
течение которого создается «Готовый», то есть пригодный к
использованиюи выпуску Инкремент продукта. Желательно
сохранять неизменную продолжительность напротяжении
всего процесса разработки.Новый Спринт начинается сразу
после окончания предыдущего. Спринт состоит из:
● ПланированияСпринта (Sprint Planning)
● Ежедневного Скрама (Daily Stand up)
● Разработки ( Iteration)
● Обзора Спринта (Sprint Review)
● Ретроспективы Спринта (Retrospective)
Максимальнаяпродолжительностьспринта - 1 календар.
месяц

14. Scrum Events
Остановка Спринта ( AbnormalTermination)— cпринт может
быть отменен досрочно.
Право на отмену Спринта имеет только владелец продукта, хотя на
данное решение могут повлиять заинтересованные лица, команда
Разработки или скрам-мастер.
Единственное основание для отмены Спринта — потеря
актуальности Цели Спринта. Причиной этому могут быть смена
направления работы компании, изменения рыночных условийили
технологий. Происходят крайне редко благодаря короткой
длительности спринтов.
Цель Спринта (Sprint Goal) – это установленный для Спринта и
команды ориентир, который достигается через выполнение части
бэклога продукта.Формируется во время его планирования и
объясняет команде разработки, для чего создается инкремент.

15. Scrum Events
Планирование спринта(Sprint Planning)— Задачи, над
которыми будет трудиться команда разработки во время спринта,
определяются на планировании Спринта. План создается
совместными усилиями всей Скрам-Команды. Планирование
Спринта ограничено по времени. Для Спринта длительностью один
месяц Планирование не должно занимать более 8 часов. Если
Спринт короче, то и Планирование проводится быстрее. Скрам-
мастер убеждается, что событие состоялось, а участники понимали
его цель. Скрам- мастер обучает Скрам-Команду соблюдать
временное ограничение.
По результатам Планирования Спринта Скрам-команда решает:
• каким будет Инкремент в конце Спринта;
• как организовать работу, чтобы получить готовый Инкремент
Продукта.

16. Scrum Events
Ежедневныйскрам ( Daily Scrum or Stand up) – Этот митинг
проходит каждое утро в начале дня. Он предназначен для того,
чтобы все члены команды знали, кто и чем занимается в проекте.
Длительность этого митинга строго ограничена и не должна
превышать 15 минут. Цель митинга – поделиться информацией. Он
не предназначен для решения проблем в проекте. Все требующие
специального обсуждения вопросы должны быть вынесены за
пределы митинга. Скрам митинг проводит Скрам Мастер. Он по
кругу задает вопросы каждому члену команды
● Что сделано вчера?
● Что будет сделано сегодня?
● С какими проблемами столкнулся?
Скрам Мастер собирает все открытые для обсуждения вопросы в
виде Action Items, например в формате что/кто/когда

17. Scrum Events
Ревью Спринта ( Sprint Review)–проводитсяв конце Спринта с целью
инспекции Инкрементаи, по необходимости,адаптацииБэклога Продукта.Скрам-
командаи заинтересованные лица во время Обзора Спринта совместнообсуждают,что
было сделано за Спринт.
КлючевыеэлементыОбзора Спринта:
• в число участников встречи входят Скрам-команда и ключевые заинтересованные лица,
которых приглашает Владелец Продукта;
• Владелец продукта объясняет, какие Элементы Бэклога готовы, а какие нет;
• Команда Разработки рассказывает о том, что получилось во время Спринта, какие возникли
проблемы и как они были решены;
• Команда Разработки демонстрирует готовую работу и отвечает на вопросы об Инкременте;
• Владелец Продукта описывает текущее состояние Бэклога Продукта. При необходимости он
прогнозирует возможные даты завершения разработки Продукта, основываясь на текущих
показателях прогресса;
• все присутствующие обсуждают, над чем стоит работать дальше.
• проводится обзор, как изменения рынка или потенциальное использование продукта могли
изменить то, что нужно сделать в первую очередь;
• выполняется обзор сроков, бюджета, возможностей и позиций на рынке для будущих
релизов или возможностей продукта. Результатом является пересмотренный Бэклог Продукта

18. Scrum Events
Ретроспектива( SprintRetrospective)— это возможность для
Скрам-команды провести инспекцию, направленную на себя, и
создать план улучшений командной работы в следующем Спринте.
Ретроспектива Спринта проводится после Обзора Спринта и перед
Планированием следующего Спринта. Максимальная
продолжительность Ретроспективы– 3 часа для Спринта
длительностью один месяц.
Цели проведения ретроспективы спринта:
• инспекция прошедшего Спринта применительно к людям,
отношениям, процессам и инструментам. Обнаружение и
упорядочение того, что прошло хорошо и того, что нуждается в
улучшении;
• создание плана внедрения улучшении ̆в процесс работы Скрам-
команды. В конце прописывают и планируют улучшения, которые
будут реализованы в следующем спринте.

19. Scrum Framework
● Сильные стороны Scrum
● Scrum был разработан для проектов, в которых необходимы «быстрые победы» в
сочетании с толерантностью к изменениям. Кроме того, этот фреймворк подходит
для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в
которой реализуется проект – постоянные коммуникации между членами
командами позволяют недостаток опыта или квалификации одних сотрудников за
счёт информации и помощи от коллег.
● Слабые стороны Scrum
● Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9
человек) и кроссфункциональной – то есть члены команды должны обладать более
чем одной компетенцией, необходимой для реализации проекта. Например
разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике.
Делается это для того, чтобы часть команды не «простаивала» на разных этапах
проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.
● Кроме того, члены команды должны быть «командными игроками», активно брать
на себя ответственность и уметь самоорганизовываться. Подобрать такую
зрелую команду очень непросто!
● Scrum подходит не для всех команд и организаций ещё и потому, что предлагаемый
процесс может не подойти для разработки конкретного продукта – например
промышленного станка или постройки здания.

20. Выбор методологии для проекта
При оценке методологий следует обратитьвниманиена
следующиемоменты:
• стратегические цели и базовые ценности организации;
• ключевые бизнес-факторы;
• ограничения;
• заинтересованные лица;
• риски;
• сложность;
• масштаб и стоимость проекта;
• оценка методологий управления проектами.

21. Выбор методологии для проекта

22. Выбор методологии для проекта