Фильтр применимости Agile

Фильтр для определения применимости Agile

Фильтр применимости Agile bспользуется для визуализации характеристик проекта и организации. Помогает заинтересованным сторонам вести более конструктивные дискуссии о выборе и адаптации на протяжении всего жизненного цикла проекта.

https://www.projectmanagement.com/agile-suitability-filter/

Как использовать подход и фильтры соответствия

1) Использовать в группе

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

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

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

2) Оцените ответы на вопросы по категориям.

В группе обсудите и согласуйте (или пойдите на компромисс) оценку, которая наиболее точно отражает субъективную оценку вопроса. Перетащите ползунок в соответствующее положение. Хотя окончательные варианты часто предоставляются только для начальной, средней и конечной точек спектра ответов, представляющих оценки 1, 5 и 10 по 10-балльной шкале, допустимо (и желательно) использовать оценки, например, 2 для «почти 1, но не совсем» или 7 для «где-то между 5 и 10». Повторюсь, оценка - это инструмент для обсуждения, мнения будут субъективными, и следует ожидать оттенков серого.

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

3) Интерпретируйте результаты

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

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

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

4) Устранение зон риска

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

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

К распространенным областям риска и стратегиям решения относятся:

• Доступ к клиенту- назначьте ему представителя, возможно, бизнес-аналитика, играющего роль клиента, но также по возможности проводите проверку с реальными клиентами.
• Подход, направленный на получение поддержки: инвестируйте в обучение, информационные сессии или, по крайней мере, выделите дополнительное время, чтобы объяснить, почему рекомендуется именно этот подход.
• Доверие к команде- обучите команду, внедрите в нее специалистов по бизнесу и замените членов команды на более надежных/уважаемых коллег.
• Принятие решений в команде- аналогично описанному выше, обучите команду, замените опытных членов команды, обеспечьте наставничество, начните с малого и поощряйте эксперименты.
• Поэтапная разработка- если продукт невозможно создать и проверить по частям, можно ли использовать заменители? Автопроизводители проводят множество краш-тестов с помощью моделирования, можно ли дать содержательную обратную связь по какой-либо части решения?
• Критичность продукта- необходимо усилить контроль качества, обеспечить резервирование, прослеживаемость от требований до результатов тестирования, независимую инспекцию и всестороннее тестирование.
• Вероятность изменений- Если изменения маловероятны, безопаснее провести более тщательное предварительное планирование, а польза от частых обзоров для отслеживания прогресса и изучения изменений снижается. Рассмотрите возможность более длительных итераций.
• Уровни опыта- укомплектуйте команду более опытными сотрудниками, предоставьте наставника, инвестируйте в обучение.

5) Планирование подхода

Теперь, когда группа оценила инициативу и ее организационную среду, согласовала подход и определила шаги по предотвращению/снижению рисков, настало время спланировать этот подход и приступить к работе.

Начните с выбранного подхода (гибкий, гибридный, прогнозный) или (разработчик-гражданин, автоматизированная непрерывная доставка, разработка ИТ-систем) и добавьте согласованные шаги по предотвращению/снижению рисков, определенные на шаге 4. Создайте план высокого уровня, отражающий процесс принятия решений на сегодняшний день, и убедитесь, что все его поддерживают. Начните с этого подхода, но не предполагайте, что он будет идеальным. Запланируйте несколько контрольных точек для оценки эффективности работы и оставьте за собой право завтра действовать эффективнее, чем вчера - то есть, предусмотрите возможности для анализа и улучшения по мере необходимости.

Источник: https://www.projectmanagement.com/agile-suitability-filter/