Agile: Scrum. Методология управления проектами
Agile: Scrum. Методология управления проектами

Agile: Scrum. Методология управления проектами

Інше 12.01.2020 4 min read

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

Waterfall и Agile

Существует две основные методологии управления проектами: Waterfall и Agile.

Waterfall — это способ разработки, когда проект разбивается на последовательные линейные этапы, где каждая последующая часть зависит от разработки предыдущей. Здесь является важным полностью завершить предыдущий этап прежде чем приступать к следующей части — Вы не можете строить крышу если Вы еще даже не положили фундамент.

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

Waterfall в сравнении с Agile, не является столь гибким.

Agile: Scrum

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

Разработка в Scrum ведется короткими циклами — Sprints ( спринтами ), продолжительность которых заранее определена для всего процесса работы над проектом и обычно составляют 2-4 недели. В процессе разработки продукта продолжительность спринта не изменяется, а новый спринт начинается сразу после завершения предыдущего. Во время спринта программисты разрабатывают заранее определенное количество работы, которое не должно меняться после его начала, а по окончанию каждого спринта заказчик получает версию приложения или его часть.

Артефакты Scrum

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown chart

Product Backlog — список всех требований по проекту. Когда Product Backlog заканчивается — проект считается завершенным. Задачи представляют собой User Stories и Bugs, они отсортированы по приоритетам, которые проставляет заказчик. Приоритеты для задач пересматриваются каждый спринт.

Sprint Backlog — список требований на поточный Sprint. Он определяется а начале спринта и не должен изменяться в течении.

Sprint Goal — краткое описание того, что должно быть сделано в результате конкретного спринта. Помогает четко определить приоритеты задач и помогает принимать какие-либо решения в процессе спринта касательно рабочего процесса.

Sprint Burndown chart — это график для наглядного отображения процесса разработки во время спринта. Он показывает количество задач которые остались для выполнения и постоянно обновляется, демонстрируя актуальные денные.

Роли в Scrum

  • Product Owner (Владелец продукта)
  • Scrum Master
  • Scrum команда

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

Scrum Master — следит за выполнением принципов Scrum в командах изнутри, организовывает эффективную работу команды.

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

События в Scrum

  • Daily meetings
  • Sprint Planning
  • Sprint Review
  • Retrospective

Daily meetings — ежедневное собрание всех участников команды, обычно до 15 минут. В течении этого митинга каждый участник команды должен ответить на 3 вопроса:

  1. Что я делал вчера
  2. Что я буду делать сегодня
  3. Есть ли какие-то проблемы

Sprint Planning — это встреча на которой определяется цель спринта и список задач на конкретный спринт (Sprint Backlog). На Sprint Planning команда рассматривает каждую задачу, обсуждает ее, выбирает ответственных людей за разработку конкретных задач и проводит предварительную оценку, обычно по системе Plannng Poker. Plannng Poker (Scrum poker) — это система оценки задач, позволяющая каждому участнику команды проголосовать за количество времени, на его усмотрение, необходимое на разработку данной задачи. Она позволяет оценивать время, затраченное на приложения в часах, днях или StoryPoints. Чаще всего для реализации системы оценки Plannng Poker используют онлайн приложения.

Sprint Review — митинг на котором проверяется выполненная работа за спринт, а так же пересматриваются задачи, которые были не завершены и принимаются решения по их реализации.

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

Принципы Scrum

  • Удовлетворение потребностей клиентов является главным приоритетом
  • Изменения и улучшения приветствуются во время разработки проекта, что достигается гибкостью Scrum
  • Рабочая версия проекта получается в результате каждого спринта. С каждым спринтом наращивается новая функциональность.
  • Ежедневная коммуникация между членами команды позволяет всем получать самую актуальную информацию и вовремя решать возникающие проблемы
  • Непрерывная коммуникация между командами разработки и заказчиком позволяет быстро внедрять изменения на улучшение проекта

Scrum и Kanban

И Scrum и Kanban — методологии семейства Agile. В обоих вариантах на проекте есть небольшие команды, состоящие из 5-10 человек. В Scrum над каждой задачей работает автономная команда, состоящая из специалистов разного профиля, что позволяет реализовать одну задачу целиком одной команде. В то же время в Kanban методологии — над одной задачей может работать несколько узконаправленных команд, таким образом задача передается от одной команды к другой — от архитекторов к дизайнерам, после к разработчикам, а уже потом к команде тестировщиков. В Kanban внутри команды нет ролей.

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

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

Источники: Lucidchart, Pmservices, Unetway, Te-st, Educba, netology

Поширити

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

guest
0 коментарів
Міжтекстові Відгуки
Переглянути всі коментарі