Главная » Блог » Наш опыт » Управление проектами на основе SCRUM. Что получилось из этого

Управление проектами на основе SCRUM. Что получилось из этого

Автор статьи
Аватар
Антон Чураков
Руководитель IT-компании "Цифровой Волк"
Дата публикации:16.11.2019

В этой статье мы хотим поделиться тем, как мы в 2017 году внедряли гибкий подход к управлению проектами по разработке ПО и созданию сайтов.

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

Гибкое управление проектами - Цифровой Волк

Но когда мы поговорили с некоторыми клиентами, которые пробовали внедрить управление проектами на основе гибкой методологии, мы слышали: “У нас это не сработало”.

Конечно, после таких слов стало интересно, почему же не получилось успешно у них внедрить. И мы решили попробовать внедрить гибкую методологию для управления проектам по разработке. Сделали свой выбор в пользу SCRUM.

Первым делом изучили общую информацию о том, что такое Agile и из чего он состоит. Существует такой манифест Agile, и содержит в себе 12 пунктов, которые описывают ценности и принципы гибкой разработки.

Получив общую информацию об этих принципах, мы стали искать дополнительную литературу и информацию. Искали и изучали лекции на ютубе, а также нашли интересную книжку Джеффа Сазерланда “SCRUM. Революционный метод управления проектами”.

Управление проектами SCRUM - Цифровой Волк

Знакомство и внедрение данного подхода

Купив и изучив данную книгу, мы приступил к внедрению данного метода управления проектами.

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

Сам по себе данный метод подразумевает, что по каждому проекту составляется бэклог. После этого определяется длительность спринта.
К примеру, у себя мы определили неделю. Этот тот период, за который необходимо было полностью выполнить выбранные задачи из бэклога.

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

SCRUM доска — доска на которой разработчики определяют фазы и размещают задачи. К примеру: “В работе”, “На тестировании”, “Выполнено” и так далее. Количество конечно может быть и больше и меньше. Каждая команда определяет данный перечень самостоятельно и как удобно им.
Стоит отметить, что руководитель проекта в это время видит, кто и над какой задачей работает.

Это придает определенную гибкость к процессу выполнения проекта.

К этому времени стали появляться различные онлайн-сервисы для командной работы. В которых можно было использовать такие доски, а не покупать маркеры и саму доску.

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

Иии мы совершили первую ошибку после первой недели работы.

Ошибка №1 — это попытка внедрить такой подход в “чистом” виде. Соблюдая все принципы и методы которые описаны в манифесте и данной книге.
Из-за этого мы не выполнили большую часть работ по проекту.

Методология SCRUM содержит в себе еще такие вещи как: митинги, написание пользовательских историй, постоянная связь и анализ с клиентом и многие другие вещи.

Но на этом наши ошибки не закончились.

Ошибка №2 — не все участники команды поняли, для чего нам это вообще необходимо. Ведь раньше как работали, так и работали.

Ошибка №3 — не учитывали размер проекта и его длительность разработки.

Управление проектами по Scrum. Полученный опыт и результат

Проект, который мы решили разработать по гибкому подходу — сдали в срок. Не смотря на то, что это было совсем новое для нас.

После этого мы провели анализ нашей работы и сделали выводы:

  1. Не стоит использовать данный подход для небольших проектов. Лучше использовать для более сложных, дорогих и продолжительных проектов. Когда требования могут часто меняться, в зависимости от ситуации.
  2. Необходимо, чтобы каждый участник команды понимал, для чего и как внедряется тот или иной подход. Не важно, управление проектами или что-то совершенно другое.
  3. Использовать преимущества и инструменты подхода исходя из ситуации. А не бездумно пробовать все подряд. В нашем случае, ежедневные встречи по 15 минут не имели особого смысла. Участники команды и так знали, кто что сделал.

Если вы однажды решите внедрить такой подход у себя в компании, не повторяйте наших ошибок и пусть проекты выполняются легко и быстро.

Предыдущая запись
Хотите быть в курсе последних новостей?

Присоединяйтесь к нам в социальных сетях

hello@digitalwolf.org 8 963 543 46 43