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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Антон Чураков - Руководитель ИТ-компании Цифровой Волк
Антон Чураков
Автор публикации Об авторе

Получил образование по специальности «Информационные системы (по отраслям)». Работал программистом в компании, занимающейся разработкой и внедрением системы BPM для автоматизации бизнес-процессов. Опыт работы разработчким ПО с 2016 года по направлениям PHP/Laravel и .NET

ВКонтакте Telegram