Agile: Scrum. Методология управления проектами
Для прочтения этой статьи совершенно не имеет значение работали ли вы со 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 вопроса:
- Что я делал вчера
- Что я буду делать сегодня
- Есть ли какие-то проблемы
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