Что такое гибкое управление проектами? Простое руководство

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

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

Давайте приступим к делу!

Введение в гибкое управление проектами

Представьте, что вашей команде поручено разработать «простую» систему управления контентом (CMS) с нуля. У вас есть список функций, которые нужно включить, например управление публикациями, поддержка нескольких авторов, текстовый редактор и многое другое.

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

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

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

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

Преимущества гибкого подхода

Основное преимущество гибкого управления проектами прямо в названии. В целом, вся философия заключается в том, чтобы помочь командам быстрее реализовывать проекты. Однако у Agile-подхода есть гораздо больше преимуществ, помимо скорости, например:

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

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

Например, Agile-подход к маркетинговой кампании можно разбить следующим образом:

1. Определите цели, которых вы хотите достичь в своей кампании.
2. Разбейте эти цели на отдельные задачи и назначьте их (например, разработать логотип, придумать слоган, написать текст для определенного сегмента).
3. Просмотрите результаты каждой задачи и запустите пользовательские тесты, чтобы определить уровень их успеха.
4. Переходите к следующему заданию.

В идеале весь процесс должен быть быстрым. Один из способов, которым некоторые команды не сбиваются с пути, - это использовать инструменты для совместной работы, такие как Trello, и устанавливать для себя временные рамки. Чтобы предложить дополнительный контекст, давайте перейдем к обсуждению конкретных методологий Agile.

3 примера гибких методологий

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

1. Scrum. Мы уже говорили о Scrum в прошлом - с помощью этой методологии ответственное лицо устанавливает отставание по продукту и устанавливает приоритеты. Затем каждая команда приступает к работе над «спринтом», к концу которого они должны выполнить новую итерацию.
2. Бережливая разработка программного обеспечения. Эта методология направлена ​​на устранение ненужных функций и предоставление конечным клиентам большей ценности. Когда дело доходит до разработки программного обеспечения, методология Lean также отдает приоритет тяжелому тестированию в процессе.
3. Экстремальное программирование (XP). Гибкая разработка по своей природе чертовски быстра. Однако методология XP делает еще один шаг вперед: спринты обычно длятся от одной до трех недель. Идея состоит в том, что за счет более быстрой итерации и высокого уровня участия пользователей проекты могут выполняться намного эффективнее.

Гибкое управление проектами может отлично подойти в большинстве ситуаций, когда вы запускаете проект с участием команды. Чем сложнее проект, тем больше пользы вы получите от Agile.

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

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

Как начать работу с гибким управлением проектами (4 шага)

Мы много говорили о методологии Agile и о том, как она работает в общих чертах. Теперь давайте подробнее рассмотрим, как может выглядеть этот процесс для сценариев из реальной жизни.

Шаг № 1: Создайте дорожную карту продукта и установите график выпуска релизов

Прежде чем вы хоть раз напишете хоть одну строчку кода, вам нужно иметь полное представление о том, над чем вы работаете и каковы ваши цели. Это означает знание:

• Каким должен быть конечный продукт.
• Какие функции он должен включать.
• Для кого это предназначено.
• Что делает ваш продукт уникальным.

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

Чтобы развить наш предыдущий пример, когда клиенту нужна CMS, вот как может выглядеть предыдущий список:

• Каким должен быть конечный продукт: CMS, ориентированная на ведение блога.
• Какие функции он должен включать: управление публикациями, поддержку нескольких авторов, иерархию пользователей и текстовый редактор.
• Для кого он предназначен: блоггеров, практически не имеющих опыта веб-разработки.
• Что делает ваш продукт уникальным: упор на простоту использования и доступность.

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

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

Шаг # 2: разберитесь, что вам нужно сделать, и пробегите свой первый спринт

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

• Строим админку.
• Создание базовой системы управления пользователями.
• Разработка базовой реализации издательской системы.

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

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

Шаг № 3: Ежедневно проводите «Standups», чтобы команды не сбились с пути

В процессе разработки каждого проекта возникают сбои и проблемы. Agile-менеджмент побуждает вас быть в курсе всего происходящего, проводя быстрые ежедневные встречи, состоящие из трех вопросов:

1. Какие задачи вы выполнили с момента последней встречи?
2. Над чем ты будешь работать сегодня?
3. Вы столкнулись с какими-либо проблемами во время процесса?

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

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

Шаг 4: завершите свой спринт и просмотрите его результаты

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

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

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

Заключение

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

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

1. Создайте дорожную карту продукта и установите график выпуска выпусков.
2. Определите, что вам нужно сделать, и запустите свой первый спринт.
3. Ежедневно проводите стендапы, чтобы держать команды в курсе.
4. Завершите спринт и просмотрите его результаты.

Есть ли у вас какие-либо вопросы об Agile-управлении проектами в целом? Давайте рассмотрим их в разделе комментариев ниже!

Миниатюра статьи: Бахтияр Зейн / shutterstock.com