У всего хорошего есть и плохое. Почему разработка программного обеспечения по методике Agile не решит все ваши проблемы.
Перевод статьи "The Massive Downside of Agile Software Development", источник тут и тут (полная версия).
Disclaimer
Данной статьей автор начинает цикл статей о недостатках Agile и почему его следует ограничить в применении.
Когда дело доходит до разработки программного обеспечения, все ищут беспроигрышную методологию как для поставщиков, так и для клиентов. В конце концов, в ближайшее время разработка программного обеспечения никуда не исчезнет. Разработка программного обеспечения по методологии Agile - это новейшая методология создания качественного, кастомизированного программного обеспечения за меньшее время. Хотя она и делает проект менее громоздким и более прозрачным, у нее имеются серьезные недостатки.
Чем является разработка программного обеспечения по Agile?
Эта методология была впервые представлена в 2001 году, когда 17 человек собрались на горнолыжном курорте Snowbird в штате Юта и создали с «Agile Манифест». В нем изложены 12 важнейших принципов разработки ПО. Они включают в себя общение, сотрудничество, открытость, гибкость и важность программного обеспечения. Аgile - это разновидность постепенной разработки программного обеспечения, которая проходит быстрыми циклами - во многом как бег на короткую дистанцию.
Результатом являются небольшие выпуски программного продукта, каждый из которых основан на предыдущем продукте. В идеале команды совершают больше выполненной работы за меньшее время. Оказалось, что этот метод лучше всего подходит для критичных по времени выполнения приложений, причем заказчик является доступным и готов общаться на протяжении всего жизненного цикла разработки. Для этого метода нужна приспосабливающаяся команда, готовая реагировать и вносить изменения на основе тестов и обзоров продуктов.
Преимущества Agile
Плюсы разработки по agile убедительны. Вот несколько причин, по которым многие применяют эти принципы:
Увеличение доходов компании за счет выпуска в производство некоторых преимуществ поэтапно, а вы тем временем продолжаете разрабатывать продукт.
Продукты поступают на рынок быстрее, выпускаются раньше и регулярно, и клиенты быстрее возвращают свои инвестиции.
Гарантия качества с интегрированным тестированием и регулярными проверками работающего продукта на протяжении всей разработки.
Лучшая прозрачность для основных заинтересованных сторон, поскольку гибкая разработка программного обеспечения поощряет участие пользователей в совместных усилиях.
Снижение риска, поскольку команда выявляет и исправляет любые проблемы на раннем этапе.
Компромиссы Agile
С преимуществами гибкой разработки программного обеспечения приходят и ряд недостатков. С гибкой разработке программного обеспечения легко потерять чувство равновесия. Брайан Лоули, генеральный директор 280 Group так говорит об Agile:
В разработке программного обеспечения не существует панацеи или бесплатного обеда. Если вы хотите применять гибкие принципы, вы должны быть уверены, что руководство продукта и команда проекта все понимают требования. Они также должны осознавать как потребности могут быстро превратиться в огромные подводные камни.
Требования и недостатки гибких методологий.
Вот 5 главных недостатков гибкой разработки программного обеспечения:
1. Меньшая предсказуемость.
Для некоторых программных продуктов разработчики не могут количественно оценить полный объем необходимых усилий. Это особенно верно в начале жизненного цикла разработки крупных продуктов. Команды, для готорых гибкая методология является новой, опасаются этих неизвестных. Этот страх вызывает разочарование, плохие практики и зачастую ведёт к неправильным решениям. Более систематизированный каскадный процесс (waterfall) упрощает количественную оценку усилий, времени и затрат на поставку конечного продукта.
2. Больше времени и обязательств.
Тестировщики, заказчики и разработчики должны постоянно взаимодействовать друг с другом. Это включает в себя многочисленные личные беседы, поскольку они являются лучшей формой общения. Все участники проекта должны тесно сотрудничать. Ежедневные пользователи должны быть доступны для незамедлительного тестирования и подписания на каждом этапе, чтобы разработчики могли отметить его как завершенный, прежде чем переходить к следующей функции. Такой подход может гарантировать что продукт соответствует ожиданиям пользователей; однако он является обременительным и требует много времени.
3. Повышенные требования к разработчикам и заказчикам.
Принципы Agile требуют тесного сотрудничества и активной вовлеченности пользователей. Несмотря на то, что Agile это увлекательная и полезная система, она требует больших обязательств для достижения успеха в рамках всего проекта. Клиенты должны пройти обучение, чтобы помочь в разработке продукта. Любое отсутствие участия клиента повлияет на качество и успех программного обеспечения. Это также плохо отражается на компании-разработчике.
4. Отсутствие необходимой документации.
Поскольку требования к программному обеспечению уточняются как раз к моменту разработки, документация становится менее подробной. Это означает, что когда новые участники присоединяются к команде, они не знают подробностей об определенных функциях или о том, как им нужно работать. Это создает недопонимание и трудности.
5. Проект легко сбивается с пути
Этот метод требует очень небольшого планирования для начала работы и предполагает что потребности потребителя постоянно меняются. Со столь небольшими требованиями для продолжения, легко видеть как это может ограничить agile модель. Далее, если пользователь не совсем ясен в своих отзывах или сообщениях, разработчик может сосредоточиться на неправильных областях разработки. У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.
Самые распространенные ошибки новых команд Agile-разработки
Гибкая разработка также имеет тенденцию открывать ворота для большего количества ошибок. Вот некоторые из наиболее распространенных:
Плохая структура команды
Недостаток полномочий команды
Плохое планирование
Неэффективное тестирование
Игнорирование отзывов клиентов
Не обращается внимание на сопротивление пользователей
Когда гибких методологий следует избегать
Многие команды путают гибкую разработку программного обеспечения со способом более быстрой поставки ПО. Гибкая разработка программного обеспечения имитирует повседневные действия, разбивая работу на спринты и составляя пользовательские истории. Однако им (командам) не удается полностью посвятить себя гибкой разработке. Поэтому, хотя они говорят, что они «делают по Agile», по факту они придерживаются традиционной ментальности, которая работала в прошлом.
Этот метод невыгоден, когда клиент должен работать по определенному бюджету или графику. Вы также должны избегать Agile, когда клиенты не могут изменить масштаб проекта после его запуска.
