Как понять, какая модель жизненного цикла проекта даст наибольший эффект для конкретного проекта?

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

Для того, чтобы ответить на этот вопрос, я предлагаю использовать формальную модель, предложенную PMI. Модель эта называется Agile Suitability Model. Почему я предлагаю использовать именно ее? На своих курсах по управлению проектами я уже много раз делал с группами практические задания на тему выбора подхода к управлению конкретными проектами с помощью этой модели и убедился в ее простоте с точки зрения понимания аудиторией.

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

В первую очередь, Вам надо запланировать совещание, на которое стоит пригласить Заказчика проекта, Спонсора проекта (если он есть у проекта), и пару человек из команды исполнителей.

Также стоит заранее предупредить участников, что совещание займет около 1 часа, к нему нужно распечатать диаграмму, приведенную ниже, и раздать ее каждому участнику:

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

В ходе совещания модератор задает следующие вопросы:

Поддержка: Как вы считаете, поддерживает ли спонсор проекта (куратор) применение Scrum на данном проекте?

Если на совещании присутствует спонсор проекта, то он и отвечает на этот вопрос. Если ответ Да, то ставим 1 балл, если Нет, ставим 10 баллов, если ответ примерно такой: «не уверен, что Scrum нам поможет» , то ставим 5. Между 1 и 5, 5 и 10, есть другие цифры и спонсор может выбрать любую из них:

Доверие: Считают ли представители Заказчика, что команда сможет трансформировать их видение и потребности в продукт или услугу – при их поддержке и постоянной обратной связи?

Например, если группа считает, что команда 100% сможет создать продукт без разработки детальных ТЗ, но с использованием устных обсуждений требований и формулирования User Story, то ставим 1. Если есть сомнения, но вероятность оценивается от 90% до 10%, то ставим балл от 2 до 9, и, если группа уверена, что команда не сможет получить результат без письменной работы с требованиями, ставим 10.

Решения: Будет ли у команды автономия в принятии локальных решений по выполнению работы в проекте?

Если оценщики уверены в том, что владелец продукта отдаст принятие технических решений по поводу реализации требований команде, ставим 1, если есть сомнения, но вероятность оценивается от 90% до 10%, то ставим балл от 2 до 9, и, если группа уверена, что команда не сможет получить автономию в принятии технических решений, ставим 10.

Далее группа отвечает на три вопроса, связанных с командой:

Размер команды: Оцените размер основной команды проекта по следующей шкале:
1-9 = 1; 10-20 = 2; 21-30 = 3; 31-45 = 4; 46-60 = 5; 61-80 = 6; 81-110 = 7; 111-150 = 8; 151 – 200 = 9; 201+ = 10.

Тут все однозначно, и неверную оценку поставить почти невозможно

Опыт: Рассмотрите опыт и навыки ключевых ролей в команде. Есть ли в команде по одному опытному члену команды на каждую роль?

Если в команде есть опытный Product Owner, реализовавший хотя бы 2 проекта в этой роли, Scrum master с опытом работы в 2-3 проектах в этой роли, и каждый участник команды участвовал хотя бы в 2-х проектах, использовавших Scrum, ставим 1.

Если хотя бы у одной роли отсутствует опытный участник, ставим 5 или оценку рядом. И если нет ни одного опытного участника – ставим 10.

Доступ: Будет ли у команды ежедневный доступ хотя бы к одному представителю заказчика/бизнеса для получения обратной связи и ответов на вопросы?

Группа оценивает, сможет ли Product owner отвечать день в день на вопросы команды разработки? Если да – ставим 1, если есть сомнения, ставим от 2 до 9, и, если есть уверенность, что нет – ставим 10.

И последний набор вопросов связан непосредственно с самим проектом.

Изменения: Какой процент требований возможно будет меняться каждый месяц?

Участники прогнозируют, какая доля из первоначально сформулированных требований к продукту проекта может измениться по ходу реализации проекта.  Если есть предположение, что более 50 % – ставим 1, если около 25% - ставим 5. Остальные оценки ставим исходя из того, что каждые 5% изменений – это оценка в плюс 1 балл. Например, для прогноза о том, что изменится 45 процентов требований, оценка будет 2.

Критичность: Рассмотрите потери, которые могут возникнуть из-за дефектов, определите, чем может закончиться провал.

Это самый сложный вопрос в третьем сете. Если группа предполагает, что в результате ошибки в работающей версии продукта могут погибнуть люди, ставим 10. Если погибнуть может 1 человек – ставим 6. Если ошибка приведет к потере большой суммы денег, ставим 5, и если ошибка приведет только к тому, что надо потратить десяток часов разработчиков на ее исправление – ставим 1.

Поставка: Может ли продукт разрабатываться и оцениваться по частям? Смогут ли представители заказчика/бизнеса своевременно давать обратную связь по инкрементам?

Тут все просто. Если вы оцениваете, что продукт моно разрабатывать небольшими кусочками, а затем эти части соединять как в конструкторе Lego, то ставим 1, если соединять можно, но сложнее, чем в конструкторе, ставим от 2 до 5. Если же оценщики считают, что разрабатывать инкрементами продукт почти невозможно (как, например, шампунь), то ставится оценка 10.

После того, как все оценки нанесены на диаграмму, мы получаем некоторый профиль проекта.

Например, такой:

Для данного проекта я бы однозначно не рекомендовал использовать Scrum. Для него лучше использовать гибридную модель жизненного цикла (ЖЦ) проекта, так как 5 точек из 9ти находятся в области гибридной модели, 3 - в области предиктивной модели ЖЦ и лишь одна попала в круг Agile.

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

Удачи вам в выборе правильных моделей ЖЦ проектов!

__________________