редакции
4 допущенных ошибки при внедрении SCRUM для управления проектами
В этой статье я хочу поделиться тем, как в 2017 году внедрял гибкий подход к управлению проектами по разработке ПО на заказ и созданию сайтов.
Используется не только в IT-сфере.
Примерно в конце 2017 года, когда уже стал более глубже погружаться в IT сферу в том числе и по управлению проектами, часто перед глазами встречались различные гибкие подходы к разработке программного обеспечения. Да и в целом для различных проектов.
Многие компании из IT сферы размещали подобную информацию на собственных сайтах, что не могло не заинтересовать меня. Ведь в основном акцент делался на то, что клиент получает необходимый ему функционал и при этом не тратит лишних денег.
Читая подобные высказывания первая мысль которая посетила мою голову — это то, что я нашел «волшебную» методику для проектов.
Окончательно мой выбор остановился на Scrum и реализацию попытки внедрить данный гибкий подход после того, как у одного клиента из производственного сектора увидел на стене доску, разбитую на несколько столбцов и проставленных в них задач.
Единственное, что мне ответили в этой компании на вопрос, получается ли использовать такой подход:
«У нас это не сработало и не работает, как бы мы не внедряли»
С того момента, я решил что необходимо попробовать внедрить это у себя в работе. Ведь я разрабатываю IT-проекты, значит должно получиться.
Поиск и изучение информации по Agile и SCRUM
Первым делом изучил общую информацию о том, что такое Agile и из чего он состоит. Существует такой манифест Agile, и содержит в себе 12 пунктов, которые описывают ценности и принципы гибкой разработки.
Получив общую информацию об этих принципах, я стал искать дополнительную литературу и информацию. Искал и изучал лекции на ютубе, а также нашел интересную книжку Джеффа Сазерланда «Scrum. Революционный метод управления проектами».
После месяца изучения данной темы по несколько часов каждый день было принято перейти к практике. Самому внедрению в процесс разработки.
Внедрение данного подхода
Для начал я приведу новый термины и их определения, про которые я узнал во время изучения материалов.
Основная цель гибкого подхода — это сократить затраты клиента, предоставив необходимый функционал в кратчайшие сроки. Реализовав более приоритетные и важные задачи из бэклога.
Сам по себе данный метод подразумевает, что по каждому проекту составляется бэклог. После этого определяется длительность спринта.К примеру, у себя я определил неделю. Этот тот период, за который необходимо было полностью выполнить выбранные задачи из бэклога.
Спринт — это временной промежуток, за который команде или отдельному разработчику, необходимо выполнить поставленные задачи в scrum доске. Длительность спринта каждая команда определяет самостоятельно.
Бэклог — это общий список задач по проекту, которые необходимо решить. Из него команда выбирает более важные задачи в текущий спринт и начинает работать над ними. После выбора задач, они размещаются на специальной доске.
Scrum доска — доска на которой разработчики определяют фазы, размещают задачи и каждый разработчик может выбрать нужную ему задачу. К примеру: «В работе», «На тестировании», «Выполнено» и так далее.
Количество этапов может быть, как больше, так и меньше. Каждая команда определяет данный перечень самостоятельно.
Стоит отметить, что каждый участник проекта в режиме реального времени видит, кто и над какой задачей работает.
Ежедневные встречи — необходимы для того, чтобы каждый участник команды сообщал, какие трудности появились при решении его задачи, а также сообщать как в целом продвигаются дела по текущему спринту.
Это позволяет поддерживать в определенной степени ритм работы команды.
Стоит также отметить, что в то время уже стали появляться различные онлайн-сервисы для командной работы, в которых можно было использовать такие доски, а не покупать маркеры и саму доску.
Для тестирования данного подхода, был выбран небольшой проект по созданию сайта для одной образовательной организации.
Составил список задач, обозначил приоритеты, определил длительность спринта и разместил их в онлайн сервисе Asana.
И вроде бы ты все сделал правильно, как делали другие команды в компаниях. Но не тут-то было.
После первых двух недель использования данного подхода я выявил следующие ошибки:
Ошибка № 1 — это попытка внедрить такой подход в «чистом» виде. Соблюдая все принципы и методы которые описаны в манифесте и данной книге.Из-за этого сроки проекта постепенно начинали срываться.
Ошибка № 2 — не все участники команды поняли, для чего нам это вообще необходимо. Ведь раньше как работали, так и работали, и все было хорошо.
Ошибка № 3 — не учитывали размер проекта и его длительность разработки.
Ошибка № 4 — Это не волшебный инструмент для разработки проектов, который просто так можно внедрить в работу и начать получать результат.
Управление проектами по Scrum. Полученный опыт и результат
Проект, который решил разработать по гибкому подходу — сдали в срок. Не смотря на то, что это было совсем новое для меня и команды.
После этого провел анализ работы и сделал выводы:
- Не стоит использовать данный подход для небольших проектов. Лучше использовать для более сложных и продолжительных проектов. Когда требования могут часто меняться.
- Необходимо, чтобы каждый участник команды понимали, для чего и как внедряется тот или иной подход. Не важно, управление проектами или что-то совершенно другое.
- Использовать преимущества и инструменты подхода исходя из ситуации. А не просто пробовать все подряд. В моем случае, ежедневные встречи по 15 минут не имели особого смысла. Участники команды и так знали, кто и что сделал.
В следующей статье я расскажу, что понял спустя почти 3 года после разработки и завершения нескольких проектов и какие выводы сделал для себя по поводу использования данного подхода.
Присоединяйтесь к нам в соц. сетях, чтобы быть в курсе последних новостей
