Почему AGILE терпит неудачу: его обратная сторона и как избежать ошибок

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

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

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

Зачем нам Agile?

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

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

Ранняя и непрерывная формулировка ценности

Снижает риск и влияние ошибок на сроки запуска

Лучшее соответствие потребностям клиента

Связано с контентом: зачем быть гибким в динамичном бизнес-контексте

Причины неудач Agile при внедрении ИТ

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

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

1. Думая, что Agile – это новая версия Waterfal

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

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

Как избежать ошибок?

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

2. Нет активного участия клиента

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

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

Как этого избежать?

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

3. Различные области не задействованы с самого начала проекта.

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

Как этого избежать?

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

4. Отсутствие преданности делу и приверженности

Еще один важный момент, который совпадает с предыдущим, связан с самоотдачей команды.

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

Как этого избежать?

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

5. Заблудиться в рутине

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

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

Как этого избежать?

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

Не пропустите эту статью:  Agile — это нормально, и что теперь?

Подводить итоги

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

Получение максимальной отдачи от Agile поможет нам избежать этой скрытой темной стороны, которая может появиться при неправильном использовании. Да прибудет с тобой сила!