Ученье свет

Контакты

Email info@aintellecto.ru
Тарифы Тарифы
Главная Каталог Agile и Scrum простым языком

Agile и Scrum простым языком

Дата создания September 1, 2026
Отзывы (4.0 оценка учеников)

О чем этот курс

Этот курс для тех, кто хочет понимать Agile и Scrum по сути, а не копировать чужие ритуалы. Вы научитесь работать итеративно в условиях неопределённости, быстро получать обратную связь и адаптировать курс продукта. Мы разберём роли и артефакты Scrum, отличим ответственность Scrum Master от руководителя и научимся выбирать подход под характер задачи.

Вы пройдёте через набор реалистичных ситуаций, коротких симуляций и получите осязаемые артефакты (цели, бэклоги, критерии готовности, прогнозы). В каждом модуле — мини‑тест и разбор типичного заблуждения. Всё — простым языком, с акцентом на эмпиризм, ценность для пользователя и командную автономию.

Курс помогает осознанно применять Scrum там, где он уместен, и не бояться выбирать Kanban или традиционное планирование там, где поток или предсказуемость важнее спринтов. Без смешения ролей и без «Scrum‑театра».

Как вы будете учиться

  • Каждый модуль включает: ситуацию команды, симуляцию, создаваемый артефакт, короткий тест и разбор заблуждения.
  • Фокус — на прозрачности, инспекции и адаптации (эмпиризм). Мы не копируем практики механически, а подбираем их под цель.
  • Ответственность Scrum Master не смешивается с обязанностями руководителя: SM — про систему и эмпиризм, руководитель — про стратегику и организационные рамки.
flowchart TD
  A["Product Goal"] --> B["Product Backlog"]
  B --> C["Sprint Planning"]
  C --> D["Sprint Goal"]
  C --> E["Sprint Backlog"]

  E --> F["Daily Scrum"]
  F --|adapts|--> E

  E --> H["Increment"]
  H --|meets|--> J["Definition of Done"]

  H --> K["Sprint Review"]
  K --|updates|--> B

  K --> R["Sprint Retrospective"]
  R --|improves|--> C

  P["Product Owner"] -.-> A
  P -.-> B

  Dev["Developers"] -.-> E
  Dev -.-> H

  SM["Scrum Master"] -.-> F
  SM -.-> R

Роли и границы ответственности:

flowchart TB
  subgraph "Scrum roles: responsibilities (not RACI)"
  direction TB

    subgraph "Product Owner"
    direction TB
      po1["Responsible for value"]
      po2["Orders Product Backlog"]
      po3["Defines Product Goal"]
      po1 --> po2 --> po3
    end

    subgraph "Developers"
    direction TB
      dev1["Build the Increment"]
      dev2["Manage Sprint Backlog"]
      dev3["Ensure quality"]
      dev1 --> dev2 --> dev3
    end

    subgraph "Scrum Master"
    direction TB
      sm1["Coaches on Scrum"]
      sm2["Removes impediments at system level"]
      sm3["Facilitates events"]
      sm1 --> sm2 --> sm3
    end

    warn["Anti-pattern: 'Manager' != 'Scrum Master'"]
  end

  style warn fill:red,color:white,stroke:red

Модуль 1. Зачем Agile: неопределённость, ценности и обратная связь

  • Ситуация: Команда делает фичу «на глазок», сроки срываются, ценность туманна.
  • Симуляция: Быстрые циклы «построй–проверь–научись» на примере карточек с гипотезами.
  • Артефакт: Карта неопределённости и список ключевых петель обратной связи.
  • Тест: 5 вопросов на распознавание типов неопределённости и нужной петли фидбэка.
  • Разбор заблуждения: «Agile = быстрее» — на самом деле про раньше узнавать правду.

Модуль 2. Эмпиризм: прозрачность, инспекция, адаптация

  • Ситуация: Решения принимаются на ощущениях, проблемы всплывают в конце.
  • Симуляция: Микро‑итерации с измеримыми критериям результата.
  • Артефакт: Набор показателей прозрачности для команды (видимость работы, качества, риска).
  • Тест: 5 кейсов — что и когда инспектировать и как адаптировать план.
  • Разбор заблуждения: «Отчёт = прозрачность» — нет, прозрачность про понятные артефакты и общие определения.

Модуль 3. Scrum без ритуалов: роли и ответственность

  • Ситуация: Руководитель раздаёт задачи, Scrum Master «ведёт митинги», владельца продукта нет.
  • Симуляция: Распределение решений по ролям на наборе спорных кейсов.
  • Артефакт: Карта ответственности: Product Owner (ценность и цели), Developers (как делать), Scrum Master (система и улучшение).
  • Тест: Кто принимает решение в 7 ситуациях (приоритезация, архитектура, найм, эскалация и т.п.).
  • Разбор заблуждения: «Scrum Master — это руководитель» — почему это ломает эмпиризм и автономию.

Модуль 4. Product Goal и Product Backlog: формирование продукта

  • Ситуация: Бэклог — свалка задач, непонятно зачем и в какой последовательности.
  • Симуляция: От проблем пользователя к Product Goal и нарезке ценностных элементов.
  • Артефакт: Сформулированный Product Goal и упорядоченный Product Backlog с критериями приоритизации.
  • Тест: Что является ценностной частью и что — просто активностью.
  • Разбор заблуждения: «User story = формат записи» — важнее смысл и проверяемая ценность.

Модуль 5. Планирование спринта: Sprint Goal, Sprint Backlog, оценка и прогноз

  • Ситуация: Команда «коммитится» на набор задач и не успевает.
  • Симуляция: Планирование от цели спринта с учётом пропускной способности и риска.
  • Артефакт: Sprint Goal, Sprint Backlog, лёгкий прогноз по исторической скорости/сквозному времени.
  • Тест: 6 вопросов по отличию оценки и прогноза, когда уместны story points/throughput.
  • Разбор заблуждения: «Velocity — KPI» — как не превращать прогноз в игру.

Модуль 6. Daily Scrum: адаптация плана каждый день

  • Ситуация: Ежедневки превратились в отчёт руководителю.
  • Симуляция: Настоящий daily вокруг Sprint Goal: как сократить риск невыполнения цели.
  • Артефакт: Ежедневная доска ограничений и договорённости по фокусировке.
  • Тест: Что обсуждать, что — нет; 3 мини‑кейса.
  • Разбор заблуждения: «Все по очереди отчитайтесь» — вместо этого синхронизация плана команды.

Модуль 7. Инкремент и Definition of Done: качество в каждом спринте

  • Ситуация: «Готово» означает «передано тестировщикам» — долги растут.
  • Симуляция: Сборка DoD: от идеи к проверяемому инкременту.
  • Артефакт: Командная Definition of Done, связанная с качеством и доставкой.
  • Тест: Что можно в DoD, а что — нет; влияние на прогноз и риски.
  • Разбор заблуждения: «DoD — список бюрократии» — на деле это минимальная гарантия ценности.

Модуль 8. Sprint Review: проверка гипотез и работа с изменениями

  • Ситуация: Review = демо для галочки, обратной связи нет.
  • Симуляция: Проведение обзора как совместного анализа ценности с заказчиками.
  • Артефакт: Обновлённый Product Backlog по результатам и принятым решениям.
  • Тест: 5 ситуаций — что пересматривать и как фиксировать изменения.
  • Разбор заблуждения: «Изменения — зло» — изменения управляемы, если есть прозрачность.

Модуль 9. Retrospective: улучшение процесса

  • Ситуация: Одни и те же проблемы кочуют из спринта в спринт.
  • Симуляция: Выбор узкого места и формулировка эксперимента на следующий спринт.
  • Артефакт: План улучшений с владельцами и критерием успеха.
  • Тест: Что является экспериментом, а что — пожеланием.
  • Разбор заблуждения: «Ретро — это вентиляция» — цель ретро — измеримые изменения в системе.

Модуль 10. Scrum vs Kanban vs проектный план: как выбрать подход

  • Ситуация: Команда поддержки, фича‑команда и проект со жёстким контрактом — один процесс на всех.
  • Симуляция: Матчинг контекстов к Scrum, Kanban и классическому плану.
  • Артефакт: Критерии выбора подхода и сигналы переключения.
  • Тест: 6 кейсов выбора.
  • Разбор заблуждения: «Kanban — бездедлайновый хаос» и «Scrum решает всё» — где чьи сильные стороны.

Модуль 11. Анти‑паттерны Scrum

  • Ситуация: «Scrum‑театр»: много митингов, мало ценности.
  • Симуляция: Диагностика по симптомам и выбор минимального вмешательства.
  • Артефакт: Список анти‑паттернов и мер противодействия (стейкхолдер‑дефицит, микроменеджмент, velocity‑игры, смешение ролей и др.).
  • Тест: Определите анти‑паттерн по наблюдениям.
  • Разбор заблуждения: «Достаточно следовать гайду» — без целей и эмпиризма не сработает.

Модуль 12. Метрики потока и прогнозирование без манипуляций

  • Ситуация: Команда «подгоняет» оценки, чтобы выглядеть лучше.
  • Симуляция: Построение прогноза на основе throughput/lead time и дольки неопределённости.
  • Артефакт: Простая политика метрик: зачем меряем, как используем, как не наказываем.
  • Тест: Выбор уместной метрики под цель.
  • Разбор заблуждения: «Измерение = контроль людей» — на самом деле про контроль системы.
flowchart LR
  HD["Historical Data
(Throughput or Cycle Time)"] --> FM["Choose Forecast Method
(percentiles)"]
  FM --> CR["Consider Capacity/Risk"]
  CR --> PF["Produce Range Forecast
for Sprint/Release"]
  PF --> IR["Inspect at Review"]
  IR --> AD["Adapt"]

  N["estimate != commitment"]
  N -.-> PF

  style N fill: lightyellow,stroke: orange,stroke-dasharray: 5 5,color: black

Модуль 13. Итоговый проект: организуем два учебных спринта

  • Ситуация: Нужно за 2 спринта проверить ценность гипотезы и наладить способ её проверять.
  • Симуляция: Полный цикл: цель продукта, бэклог, планирование, daily, инкремент и DoD, Review, изменения, Retrospective, новый эксперимент.
  • Артефакт: Две итерации материалов: Product Goal, Product Backlog, Sprint Goal/Backlog, DoD, инкременты, протоколы Review/Retro, обновлённый бэклог и прогноз.
  • Тест: Устный питч процесса и результата (чек‑лист критериев).
  • Разбор заблуждения: «Спринт — это мини‑проект» — спринт — шаг к цели продукта с проверкой гипотез.

По завершении вы будете уверенно объяснять, зачем нужен Scrum, как им пользоваться в своей реальности и когда лучше выбрать Kanban или классическое проектное планирование. Главное — вы научитесь проектировать петли обратной связи и улучшать систему, не копируя ритуалы без смысла.

Оглавление

12 часа

Начать обучение Начать обучение

Курс содержит:
  • Длительность: 12 часа
  • Студентов: 13
  • Сертификат: Да

Похожие курсы

Другие курсы по близким темам

Подпишитесь сегодня — получайте полезные идеи