Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming
Scrum Agile process

Scrum процесс на одном листе

Scrum – это спортивный термин, который пришел к нам из регби, и представляет собой фигуру, которую образуют игроки перед началом игры.

Scrum Rugby

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog JIRA

Project Backlog (JIRA)

Получить стоимость обучения Agile/Scrum за 60 минут?

    Телефон: Компания:

    Sprint backlog:

    • Это список всех требований, которые нужно сделать в ближайший спринт.
    • В течение спринта, новые требования не могут появится в Sprint backlog.
    • Все требования должны быть разделены на задачи и оценены.

    Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

    Kanban Доска в Спринте

    Kanban Доска в Спринте

    Sprint Goal

    • это краткое описание того, ради чего выполняется данный спринт.
    • цель на спринт помогает команде принимать обоснованные решения.

    Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.

    Sprint Burndown Chart

    • дословно “диаграмма сгорания”
    • в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
    • диаграмма обновляется каждый раз, когда завершается какая-либо задача.

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

    Burndown диаграмма в Jira

    Burndown диаграмма в Jira

    Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

    Роли в Scrum

    В скрам используется всего три роли:

    • Product Owner
    • Scrum Master
    • Team.

    Роль Product Owner

    • формулирует требования
    • приоритезирует требования
    • корректирует приоритеты на каждом спринте
    • несет персональную ответственность за ценность требований для рынка/пользователей
    • отвечает за взаимодействие с рынком
    • только один человек

    Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

    В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

    Роль Scrum Master

    • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
    • организует работу команды и обеспечивает её всем необходимым
    • защищает команду, несёт ответственность за её эффективность
    • только один человек.

    Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

    • Скрам мастер не назначает людей на задачи – это делает сама команда;
    • Мастер не заставляет людей делать работу – это ответственность команды;
    • Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

    Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

    Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

    Team (команда проекта)

    • кросс-функциональная
    • взаимозаменяемая
    • самоорганизующаяся
    • с фиксированным составом (в ходе спринта)
    • 4-10 человек.

    Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

    Команда НЕ принимает решений:

    • какие требования являются приоритетными – это делает Product Owner.

    На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

    Daily Meeting scrum

    Команда проводит “ритуал” Daily Meeting

    Для компаний, которые решили системно перейти на методологию Scrum, я рекомендую ознакомиться со структурой проекта внедрения и рекомендациями заказчику.

    Ритуалы (процессы в Scrum)

    В скрам есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.

    Ритуалы в скрам это:

    • Sprint Planning Meeting
    • Daily Meeting
    • Sprint Review
    • Retrospective

    Sprint Planning Meeting (встреча по планированию спринта)

    • выполняется всей командой перед началом спринта
    • команда выбирает требования из Product Backlog и формирует Sprint Backlog
    • если требуется учесть взаимосвязи между операциями, то это делается здесь
    • команда декомпозирует требования на задачи (tasks)
    • каждая задача проходит оценку в трудозатратах или универсальных единицах
    • во время встречи Product Owner отвечает на вопросы команды.

    Встреча, которая проводится перед началом каждого спринта. Структура встречи:

    • представление и пояснение Product Owner’ом списка требований
    • вопросы со стороны команды
    • /рекомендуется перерыв/
    • декомпозиция требований на задачи (tasks)
    • оценка задач по методу Planning Poker.

    Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

    Daily Meeting (ежедневная встреча команды).

    Из названия понятно, что встреча проводится ежедневно. Основные принципы:

    • проходит ежедневно и только в одно и то же время;
    • встреча проходит только стоя;
    • поэтому длительность встречи не более 15 минут;
    • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

    Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.

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

    Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

    Kanban Board во время спринта

    Kanban Board во время спринта

    Sprint Review – сдача спринта Product Owner

    По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

    Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

    Структура встречи:

    • команда зачитывает требования из Sprint Backlog
    • по каждому критерию приемки происходит демонстрация полученных результатов
    • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
    • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

    На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

    Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

    Retrospective

    Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

    Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:

    • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
    • какие проблемы мешают команде выполнять взятые на себя обязательства?
    • как улучшить взаимодействие с Product Owner’ом?
    • какие ошибки совершает команда и почему.

    Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.
    Ознакомьтесь со списком наших курсов по управлению проектами.

    Почему появился Agile?

    Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

    1. Заказчик не может сформировать четкие требования к ПО;
    2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
    3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

    #1 Заказчик не может сформировать четкие требования к ПО

    В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

    • у Заказчика существует только идея приложения и он не представляет всю его функциональность;
    • у группы проекта есть разный взгляд на функциональность приложения;
    • команда не может договориться, как же будет удобнее/разумнее реализовать ту или иную часть функциональности приложения.

    Один из принципов Agile гласит «Используйте прототипы и делайте поставки продукта как можно чаще». Это позволит снять неопределенность в требованиях и проверить, как с ней будут работать реальные пользователи.

    В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

    #2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

    К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

    Подход Agile предоставил бизнесу главное преимущество – быстрые поставки новой функциональности. Это позволило каждый месяц выпускать продукт и оперативно получать обратную связь от пользователей.

    #3 Заказчики и разработчики не удовлетворены процессом взаимодействия

    При жестком сроке и в условиях постоянных изменений разработчики вынуждены формализовывать процессы взаимодействия с Заказчиком. Разработчики закладывают в бюджет работы по созданию детальных требований и спецификаций, а также риски на возможные их изменения. При этом Заказчик вынужден оплачивать документы, которые не несут реальной ценности для бизнеса.

    Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

    При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

    Резюме

    Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

    Внедрить Agile за 3 месяца?

    Пошаговая инструкция, как внедрить Agile/Scrum в вашей компании за короткий срок

    0 91 100 43
    91%
    Средняя оценка
    Оцените!
    Закрыть

    Большое спасибо, что нашли время написать отзыв!

    Закрыть

    • Содержание статьи
      96%
    • Актуальность информации
      97%
    Айгуль2020/11/19 3:33:32 пп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Daniil2020/09/21 8:57:37 пп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    That's a good article.Thanks
    Наталия2020/08/31 1:24:06 дп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Супер! Очень понятно.
    Наталия2020/08/31 1:24:05 дп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Супер! Очень понятно.
    Elena2020/08/04 3:33:28 пп
    • Содержание статьи
      50%
    • Актуальность информации
      50%
    Не вводите в заблуждение новичков. Перечитайте скрам гайд 2017 года, все станет на свои места. Как пример: в артефактах скрама нет ни чартов ни целей, есть только бэклог продукта, бэклог спринта и инкремент.
    Alesia2020/05/28 11:14:34 пп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Спасибо, для новичков отличный старт!
    Евгений2019/12/19 10:00:37 дп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Спасибо, доступно, общую картину получил
    Mikhail2019/10/23 12:23:53 пп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Очень познавательно
    Валентина2019/10/23 8:44:19 дп
    • Содержание статьи
      100%
    • Актуальность информации
      100%
    Понятно,доступно,емко,спасибо.
    Ольга2019/04/28 11:56:26 пп
    • Содержание статьи
      97%
    • Актуальность информации
      98%
    Спасибо! Все изложено в доступной форме!
    Loading.....Load More Reviews
    9 комментариев
    1. Сергей 4 года ago

      Очень подробная и интересная статья. Подскажите, вы проводите тренинги?

      • Автор

        Добрый день.
        Мы проводим тренинги по всему СНГ. Свяжитесь с нами любым удобным способом и мы пообщаемся.

    2. Georgevopob 4 года ago

      По моему тема весьма интересна. Предлагаю всем активнее принять участие в обсуждении.

    3. Юрий 4 года ago

      Хорошая статья. Спасибо

      • Автор

        Опубликовали статью для заказчиков и подрядчиков в крупных ИТ-проектах. Посмотрите в записях блога.

    4. Сергей 4 года ago

      Спасибо. Лучшая статья про Agile, что я нашел в интернете.

    5. Петр Петрович 4 года ago

      Мне нравится в Agile сам принцип: важно договориться с клиентом, а не пытаться ограничить наши коммуникации с помощью контракта.
      Если стороны не умеют договариваться, то любая модель управления будет очень напряженной и дорогой. С клиентами-муд*ками никакой Agile не работает.

    6. Дмитрий 4 года ago

      Игра в регби не начинается со scrum (схватки). Это такая же часть игры, как пенальти в футболе

    7. Автор

      Появилась новая статья “Как внедрить Agile за 3 месяца”.
      Также в Расписании анонсированы бесплатные вебинары.
      Ждем всех.

    Leave a reply

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    *

    ©2021 «Проектный Офис» все права защищены

    Проектный офис Профессиональное управление проектами
    Проектный офис Профессиональное управление проектами

      Log in with your credentials

      Forgot your details?