Неправильно ли использовать Agile, когда требования клиентов вообще не меняются?

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

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

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

Мой вопрос: будет ли это плохо, ковбойское кодирование, анти-паттерн и т. Д.? Должны ли мы использовать водопад и планировать как можно больше в мельчайших деталях, прежде чем мы начнем кодировать, когда требования стабильны, а не в менталитете «давай сделаем» в Agile?

РЕДАКТИРОВАТЬ: Основным моментом здесь является то, что: мы не можем винить клиентов за изменение требований. Предположим, что клиенты указали нам на очень конкретную проблему, дайте нам список пожеланий в очень разумных деталях и оставьте нас в покое (т. Е. У клиентов есть свои собственные продуктивные дела, не надо их больше беспокоить. Только демонстрация для них рядом с конец, когда у вас есть минимальный рабочий прототип). Было бы неправильно использовать Agile в этом сценарии?

Будет ли это считаться плохим, ковбойским кодированием, анти-паттерном.

Краткий ответ: нет. Правильно делать «гибкие» не означает «не планировать», это значит не переоценивать вещи.

Одна из основных причин использования Agile - клиенты часто меняют требования.

Это упрощенное утверждение. «Изменение требований» также связано с тем, как меняется понимание требований командой. И речь идет о том, как приоритеты клиента относительно требований меняются, когда он фактически видит несколько выпусков программного обеспечения.

На самом деле, «agile» работает ИМХО лучше всего именно в той ситуации, которую вы описываете - клиент хорошо знает его общие требования, вы можете написать общий план, заполнить свой журнал большим количеством «пользовательских историй» и уже достаточно информации, чтобы выбрать правильную архитектуру системы. Короткие итерации стратегии гибкой разработки помогут сделать «неопределенные требования» более точными, с большим количеством отзывов, если вы все еще идете в правильном направлении. Это также даст вам раннюю обратную связь о реальных усилиях и затратах (это то, что вы все еще можете потерпеть неудачу в подходе с водопадом, даже если вы знаете каждый бит требования в деталях).

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

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

А) Доказывает клиенту, что вы на самом деле почти при помощи демо-версии («Все эти истории сделаны, мы можем сделать последние несколько, если вы хотите»), и еще некоторое время получит именно то, что они хотят.

Б) Потенциально достаточно хорош, чтобы они все равно были счастливы и отпустили.

Для меня устранение этого риска полного отказа - это достаточная причина для того, чтобы бизнес перешел к гибкому процессу разработки, а возможность создавать лучшее программное обеспечение, чем первоначально планировалось, не дает результатов. Как упоминалось в других ответах, эти «конкретные» требования часто все еще удивительно податливы.

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

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

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

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