Современные методологии ведения проектов

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

Scrum

Эта методология предназначена для гибкой разработки программного обеспечения с акцентом на качественном контроле процесса разработки. Ее фундамент заключается в существовании нескольких команд, создающих финальный продукт по четко определенным этапам. То есть финальный продукт готовят не одним махом, а небольшими частями, качественно проработанными и готовыми к выпуску.

Структура скрама состоит из следующих частей:

• Роли.
• События.
  
• Правила.
  
• Артефакти.
  

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

В первой категории представлены следующие роли:

• Владелец продукта — лицо, понимающее его стоимость для бизнеса. Он представляет интересы всех заинтересованных сторон и доносит все пожелания заказчика. В то же время владелец не вовлечен в технический аспект процесса.
• Разработчики — ответственные за реализацию технических задач. Их команда состоит из специалистов разных отраслей, обеспечивающих выполнение нужных функций. Также они создают беклог, контролируют качество, адаптируют план к целям спринта.
  
• Скрам-мастер или руководитель — ответственный за групповую коммуникацию. Помогает владельцу продукта и разработчикам выполнять свои задачи без препятствий и отвлекающих факторов. Вся коммуникация лиц, не связанных с командой по разработке, происходит исключительно через скрам-мастера.
  

Для этой методологии характерны пять видов событий:

• Спринт — центр всего процесса в скраме. В нем происходят самые главные активности: планирование спринта, дейли-скрам, обзор и ретроспектива скрама.
• Планировка спринта, в котором участвует вся команда. При планировании проводятся презентации продукта и каждый участник может высказать свои предложения или замечания. На этом этапе создается беклог, определяются способы выполнения задач.
  
• Дейли-скрам — короткие рабочие встречи до 15 минут. На них планируется расписание рабочего дня разработчиков и анализ трудностей и непонятных вопросов. Присутствие всех разработчиков не обязательно. Члены команды отчитываются, что сделали с момента прошедшего совещания, что будет сделано до следующего, что мешает выполнению поставленных целей.
  
• Обзор спринта — демонстрация продукта, созданного при спринте. Происходит в конце спринта с целью показать достижение команды стейкхолдерам.
  
• Ретроспектива спринта — полное и подробное обсуждение командной работы на протяжении всего спринта и поиск методов повышения эффективности работы в будущем.
  

Артефакты — методы и инструменты, которые используются в скраме:

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

Agile

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

Примечательно, что набор инструментов у аджайла такой же, как у скрамы — спринты, беклоги. Временные расходы по выполнению проекта намечают непосредственно под спринтом.

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

Основные принципы метода заключаются в следующем:

• Активные действия всех вовлеченных в проект участников.
• Команда имеет возможность принимать общие решения.
  
• Требования должны быть прописаны наилучшим образом, их нужно облегчать и показывать наглядно.
  
• Шаги (итерации) должны быть краткими и постепенными.
  
• Фокус — только на постоянном предоставлении результатов.
  
• К следующему шагу переходят только после завершения предыдущего.
  
• Полученные результаты нужно тестировать в течение всей работы, а не под конец.
  
• Совместная работа как участников, так и заинтересованных сторон.
  

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

Среди недостатков следует выделить, что постоянная адаптация к изменениям может привести к тому, что финальный продукт так и не увидит свет.

Kanban

Ключевыми признаками этой методологии является наглядность и баланс задач. Каждый участник процесса может отследить все действия — от постановки задачи до результатов ее выполнения. У Канбана нет четких ролей или этапов прогресса. Это часто подходит для различных поточных производств, особенно тех, где финальный продукт нематериален. Выходит что-то вроде эстафеты — каждый отдел, выполнив свою функцию в задаче, передает ее в следующий отдел и т.д. Это помогает увидеть ошибки, сделанные на предыдущем этапе, и своевременно их исправить.

В общем, канбан базируется на четырех принципах:

• Визуализация задачи — все поставленные задачи должны отображаться в плане, их статус обновляется по мере прохождения этапов.
• Группировка — это делается на базе статуса задач, иногда хватает обычного «Нужно сделать», «Выполняется», «Выполнено», «Проверка», «Одобрено».
  
• Внимание к незавершенным задачам — если выполнение какой-то задачи затормозило на определенном этапе, то следует разобраться в причинах этого и при необходимости выделить дополнительные ресурсы или предоставить необходимую помощь для завершения работы.
  
• Постоянное усовершенствование — контроль за сроками выполнения и перемещением задач помогает находить слабые места в процессах. Из этого делаются соответствующие выводы: где нужно больше ресурсов, где меньше, а где следует корректировать нагрузку.
  

Хорошей иллюстрацией этого метода служит то, как создавалась эта статья:

В специальном задачнике редактор поставила задание «Написать статью на тему методологий проектов» ⟶ журналист прорабатывает источники, пишет статью и переводит ее на редактора ⟶ редактор вычитывает статью и, если все хорошо, переводит ее на корректора ⟶ корректор вычитывает статью на наличие ошибок, вносит правки и передает ее для публикации контент-менеджеру ⟶ он подбирает иллюстрации, публикует статью на нашем сайте и переводит задания обратно на журналиста ⟶ он пересматривает публикацию и закрывает задание, если все правильно.

Все эти этапы имеют специальные статусы в задачнике: «Новая задача», «В работе», «Готово к принятию», «Готово к закрытию», «Закрыто». В случае возникновения проблем на определенных этапах есть статусы «Обратная связь» и «Отклонены».

Waterfall

«Водопад» традиционная и распространенная методология. Ее суть состоит в последовательном прохождении процесса, который разделен на определенные этапы или стадии. Этот способ управления используется в проектах, которые могут быть разделены на логические и последовательные части.

Задача руководителя такой модели — следить за выполнением плана и избегать просрочки задач.

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