Основы методологии SCRUM
Last updated
Last updated
Есть проекты большие и маленькие. Есть проекты, которые может сделать один разработчик за 1 день. Есть проекты, на которые требуются 2 разработчика, и им нужно несколько дней. Но есть и проекты, реализация и поддержка которых может занимать не один год.
Реализацией каждого проекта необходимо управлять. Каждый проект несет в себе некую ценность, будь то материальная или другая. За реализацию проекта платятся деньги, и всем участникам процесса необходимо понимать, сколько времени и денег нужно потратить, сколько необходимо человеко-ресурсов, чтобы его реализовать.
Что первое приходит в голову, когда идет речь о реализации проекта? Например, нужно сделать веб-сайт.
Нужно прописать требования в целом к сайту, а также к каждой его странице;
нужно нарисовать его дизайн;
все это нужно со всеми участниками процесса согласовать;
нужно, собственно, написать код;
необходимо все протестировать;
нужно исправить баги по итогу тестирования;
и прочее.
Ранее практически все проекты делались постепенно. То есть, сначала определялись требования к проекту. Только потом рисовался дизайн всего сайта. И так далее. Пока не была окончена полностью одна стадия, не приступалась работа к другой. Такой метод ведения проекта называется Waterfall (водопад).
Но в современном мире все меняется очень быстро. Появляются новые тренды, новые бизнесы, новые конкуренты, новые идеи сменяют одна другую очень быстро. И это не могло не наложить отпечаток на методах разработки проектов. Все столкнулись с тем, что модель Waterfall абсолютно не гибкая в плане изменений. Разработав по этой методологии продукт, можно было спокойно столкнуться с ситуацией, что он уже никому не нужен и абсолютно не конкурентен по окончанию разработки.
На смену такой модели управления проектами пришел Agile.
Agile - это набор различных методик управления проектами, основной сутью которых является готовность к постоянному изменению требований к продукту. То есть, приступая к реализации, команда может до конца не знать конечный продукт, который получится, и должна быть гибкой к изменениям требований.
Большинство компаний в современном мире стараются реализовывать проекты, используя одну из методик Agile.
У Agile есть множество практик, подходов и реализаций. Одним из наиболее популярных подходов является Scrum
.
В чем основная идея Scrum?
Основая идея методологии Scrum - это работа определенными временными промежутками, которые называются спринтами. Каждая итерация, т.е. каждый спринт - это фиксированный отрезок времени, за который команда обязуется разработать и выпустить кусок готового продукта.
Чтобы этого достичь, существуют различные практики и подходы в Scrum.
Кто обычно является участником команды?
Собственно сами разработчики.
Product owner (идеолог продукта, который разрабатывается, его задача - доносить до команды требования по реализации).
Scrum master (его цель - следить за тем, что команда сплоченная, и двигается в нужном направлении, все понимают принципы Scrum, по которым происходит работа. Иногда эту роль совмещает в себе Project manager).
Разумеется, в зависимости от проекта и компании, ролей может быть как больше, так и какие-то из них могут отсутствовать.
Как управлять поставленными задачами?
Для того, чтобы каждому участнику команды было удобно, понятно и прозрачно отслеживать процесс выполнения задач, а также для более удобного анализа выполнения плана, была придумана доска задач. Самая простая реализация такой доски следующая.
Она построена в формате колонок. Первая колонка - это список задач. Вторая колонка - это список задач, которые на данный момент в работе. Третья колонка - задачи, которые готовы к проверке. Четвертая колонка - задачи которые полностью завершены.
Визуально, это выглядит примерно так:
В зависимости от принятых компаниями правил, эти колонки могут быть разными.
Также могут быть и другие колонки, например, Ready for QA
(задачи, которые могут быть взяты на тестирование отделом QA), RC
(release candidate, задачи, которые полностью протестированы и могут быть вылиты со следующим релизом), и другие.
Можно сделать как одну доску для одного спринта, так и одну доску для всего проекта. Данные вещи варьируются в зависимости от компании и от проекта.
Как формируется список задач?
Обычно в начале спринта формируется его цель. Например - Подключить платежные системы
. Цель - это какой-то рабочий функционал, описанный понятным языком. В зависимости от этого формируется список задач на данный спринт. Задачи могут быть уже созданы, и лежать в backlog-e. Backlog - это список задач, который формирует или Product owner, или проектный менеджер, или команда. По сути это список всех задач, которые будут реализовываться в будущем. Если такой задачи в backlog-е нет, она создается и добавляется в спринт.
По правилам Scrum, в начале каждого спринта (или в конце предыдущего) проводится планирование. Команда собирается и решает, что она планирует реализовать в следующем спринте. Как мы помним, спринт - это фиксированный отрезок времени. То есть, например, если спринт - это 2 недели, команда набирает такое количество задач, которое сможет реализовать за 2 недели. Каждый оценивает, сколько ему времени нужно для реализации той или иной задачи, и дает свою оценку времени. Это называется оценкой задач или эстимированием (от слова estimate).
Как оценивать задачи?
Обычно, в классическом Scrum оценка задач проводится не в промежутках времени, а в условных единицах, под названием Story points
. Стори поинт - это условное обозначение усилий, которые нужно потратить на реализацию той или иной задачи. Команда должна оценить все, что повлияет на эти усилия. Это может быть:
Объем работы для выполнения.
Сложность работы.
Риски или неопределенность при выполнении работы.
Разные компании по-разному проводят оценку. Основная часть работает по стори-поинтам. Некоторые пренебрегают советами, и стори-поинты измеряют в часах, а некоторые и вовсе измеряют время на реализацию той или иной задачи в часах и никак не используют стори-поинты.
Как понимать, что все идет, как запланировано?
Scrum предполагает очень большое количество коммуникации. Команда должна постоянно друг с другом взаимодействовать, чтобы понимать, успевает ли она выполнить все задачи в срок. Также очень оперативно должны устранятся барьеры, которые возникают на пути достижения поставленной цели.
Для этого по методологии Scrum существует несколько видов встреч команд:
Ежедневный stand-up. Это встреча всей команды, которая обычно проводится утром перед началом рабочего дня. Ее длительность - не более 15 минут. Ее цель - получить от каждого из участника команды статус по выполненым вчера и запланированным на сегодня задачам, а также озвучить проблемы, которые возникли при выполнении задачи. Каждый член команды говорит на этой встрече примерно такое: Вчера я сделал задачу по добавлению новых товаров в корзину, сегодня планирую сделать страницу платежных систем
, Вчера начал делать интеграцию платежной системы Paymentwall, но на их стороне есть проблема и я жду от их разработчиков решения. Пока его нет, планирую сделать верстку страницы кошелька
. И все в таком духе.
Планирование спринта. Это встреча, на которой обычно присутствуют все члены команды. Ее цель - спланировать работу на следующий спринт. По Scrum - все, что запланировано на спринт - должно быть выполнено в течение спринта. Новые задачи не должны добавляться. Это позволяет сконцентрироваться на цели спринта. В реальности, конечно же, такой принцип регулярно нарушается :)
Груминг. Цель этой встречи - оценить задачу, задать по ней вопросы и выяснить детали, которых недостает для того, чтобы к ней приступить. Product owner может быть как технически подкованым, так и нет. Соответственно, описание задачи может быть не всегда понятным, и по ним возникает масса вопросов. В идеале, задачи для спринта берутся из backlog-а. И задачи в нем должны быть в таком состоянии, что их можно просто оттуда взять и реализовывать. Для этого каждая задача должна быть описана, проэстимирована, и у разработчика должно возникать минимальное количество вопросов при ее реализации. На груминге команда изучает задачу, задает вопросы, и Product owner приводит задачу в то состояние, когда она максимально готова к реализации.
Ретроспектива. Эта встреча проводится в конце спринта. Ее цель - оценка всеми участниками команды того, каких успехов добились в спринте, что реализовать не получилось и почему. Каждый имеет право говорить, какие барьеры возникали, что хотелось бы улучшить. По итогам ретроспективы команда изучает эти барьеры и желаемые улучшения и планирует, что сделать, чтоб такого больше не повторилось.
Также существуют и другие встречи, например demo. Также каждая команда может проводить встречи другой направленности. Цель любой встречи - синхронизация работы, поиск и устранения барьеров по достижению цели.
В среде руководителей проектов Scrum считается фреймворком для управления проектами. То есть, по сути, это набор готовых решений для достижений тех или иных задач. При использовании методологии Scrum не обязательно применять абсолютно все, что предполагает Scrum. Можно добавлять что-то, что-то видоизменять, от каких-то подходов отказываться.
При выборе методологии ведения проектов, менеджер должен учитывать массу факторов. Анализировать ресурсы, риски, планировать и подбирать такую методологию, с помощью которой можно максимально эффективно реализовать проект.
Задача разработчика - в любой из выбранных методологий четко следовать ей и понимать, зачем это нужно. При адаптации нового члена команды, всегда дается время на ознакомление с процессами и подходами командной работы. Поэтому не стоит пытаться детально разбираться в той или иной особенности Scrum. От компании к компании подходы к реализации Scrum могут отличаться. Нужно в целом понимать, какие элементы включает Scrum, и зачем каждый из них нужен.
Полезные ссылки
Agile - это, можно сказать, некий подход. Существует такая вещь, как Agile-манифест, в котором изложены основные принципы и ценности данного подхода. Детальнее с ними можно ознакомиться .
Наиболее распространенной программой для ведения подобных досок является . Также, ее популярный, бесплатный, и более легковесный аналог - .
Подробнее об оценке задач в стори поинтах можно почитать .