Мышление в стиле Agile: гибкие методы в управлении проектами

25 Янв 2016

Мышление в стиле Agile: гибкие методы в управлении проектами

Гибкие методологии набирают популярность за пределами ИТ, крупные компании всё чаще рассматривают Scrum в качестве альтернативы классическому проектному управлению. Но прежде чем приступить к внедрению гибких методик управления проектами необходимо найти ответы не несколько вопросов, таких как: подходит ли Agile нашей компании? Подойдёт ли существующая организационная структура для таких изменений? Как измерить отдачу от внедрения?

Во многих ситуациях внедрение Agile может серьёзно повысить производительность и улучшить результативность всех членов команды. Однако недостаточно просто нанять «гибкого» менеджера проектов (Agile Project Manager (APM) – прим. пер.). Для успешного внедрения и использования гибких методологий необходимо изменение всей организации, метрик и образа мышления.

Хотите использовать гибкие методы? Вам нужна гибкая организация!

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

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

Переосмысливая метрики проектов

«Гибкий» менеджер проекта должен понимать, насколько продвинулась команда в работе над проектом и предоставлять отчётность высшему руководству. Он может делать отчёт о состоянии всего проекта, в форме, например, диаграммы сгорания. Или о какой-то его части во время ежедневных встреч или в форме отчётов. Но важно понимать, что все усилия сконцентрированы на устранении препятствий в работе проекта, а не на подчинении его процессу отчётности.

Именно это и пугает организации с традиционным подходом – они уверены, что гибкие методики управления проектами хаотичны и не ориентированы на детали. Но это плата за освобождение менеджера проекта от рутины постоянного детального планирования и отчётности. Теперь руководитель может больше времени уделить работе над проектом, решению проблем, мотивации команды. В этом состоит основное отличие каскадных и гибких методологий с точки зрения функций руководителя проекта. «Гибкий менеджер» меньше занимается контролем, и больше – решением проблем и работой с командой. Если удастся привлечь к преобразованиям в сторону Agile руководство, компанию и клиентов, то точность «гибких» метрик может достичь того же уровня, что и у традиционных «каскадных» методологий, и даже превзойти их благодаря концентрации Agile на главных аспектах продукта.

Особенности Agile

Традиционные «каскадные» методики

Гибкие методики

Диаграмма Гантта

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

Диаграмма сгорания

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

Встречи по статусу проекта

Чётко распланированная встреча, где менеджер проекта с командой разбирает каждую задачу, её статус, результаты и сроки, когда она будет выполнена. Руководитель ответственен за выполнение задач (тут авторы приводят какой-то свой пример, обычно на классических статус митингах разбирают примерно то же, что и на «встречах на ходу» — прим. пер.)

Ежедневные встречи «на ходу»

Короткие встречи с командой на ходу, на которой каждый из членов команды отвечает на 3 вопроса: «Что было сделано с последней встречи? Что должно быть сделано перед следующей? Какие препятствия мешают достичь цели?». Руководитель получает необходимую ему информацию, чтобы быть в курсе дел проекта, а член команды берёт на себя ответственность за выполнение задачи

Заказчик ожидает

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

Заказчик вовлечён

В Agile Заказчик – активный участник проекта. Владелец продукта («product owner») присутствует на ежедневных встречах, участвует в принятии решений. Задача руководителя проекта состоит в поддержании тесных взаимоотношений с заказчиком и обучении его принципам работы с Agile

 

Авторы статьи в таблице привели примеры из своей практики. Однако в опыте компании «Проектные сервисы» встречались случаи применения инструментов, указанных в статье, как «гибкие», в традиционных методиках и компаниях – прим. пер.

Смотрите также:

Источник: http://www.esi-intl.co.uk/blogs/pmoperspectives/index.php/agile-project-management-a-shift-in-metrics-and-mindset/


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Rambler's Top100 Яндекс.Метрика Рейтинг@Mail.ru