Главные недостатки Agile

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

Что такое Agile?

Эта методика была предложена в 2001 году, когда 17 человек собрались на горнолыжном курорте Snowbird в штате Юта и приняли «Agile Manifesto». В манифесте были описаны 12 наиболее важных принципов разработки. Они включали взаимодействие, сотрудничество с заказчиком, открытость, гибкость и важность работающего ПО. Разработка по Agile ведется быстрыми циклами, больше похожими на спринты. Результатом являются небольшие «релизы» (версии или обновления) программного продукта, в каждом из которых добавляются новые функции по сравнению с предыдущим продуктом. В идеале, команды выполняют большую работу за меньшее время. Этот метод оказался наиболее подходящим для продуктов с критическими требованиями к срокам, когда клиент доступен и готов общаться на протяжении всего жизненного цикла разработки. Для Agile требуется легко приспосабливающаяся команда, готовая быстро реагировать и изменять продукт на основании результатов тестирования и отзывов.

---

Преимущества Agile

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

1. Увеличение прибыли. Добавляя некоторые преимущества в следующих релизах, вы продолжаете развивать продукт.
2. Продукты выходят на рынок быстрее, релизы выходят раньше и регулярно, соответственно, клиенты получают отдачу от своих инвестиций раньше.
3. Качество продукта обеспечивается с помощью встроенного тестирования и регулярных проверок рабочего продукта на всем протяжении разработки.
4. Улучшение прозрачности для заинтересованных сторон, так как гибкая методология разработки поощряет вовлечение пользователей для совместных согласованных усилий.
5. Снижение риска, так как команда выявляет и исправляет любые проблемы на ранней стадии.

---

Недостатки Agile

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

1. Меньше предсказуемости

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

2. Больше времени и приверженности

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

3. Повышенные требования к клиентам

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

4. Отсутствие необходимой документации

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

5. Проект легко сбивается с пути

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

---

Наиболее распространенные ошибки новых команд разработчиков Agile

Принципы Agile являются источником возможных ошибок для новичков. Вот некоторые из наиболее распространенных:

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

---

Когда не стоит использовать Agile

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

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

Автор: Адам Фридман (Adam Fridman)
Источник
People photo created by drobotdean — www.freepik.com

Книга в подарок

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

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.