Как в Agile решается проблема, когда на последних спринтах приходит требование, ради которого придется все переделывать?
Здравствуйте!
Требуется пояснение от товарищей, опытных в Agile:
Как в Agile решается проблема, когда на поздних этапах разработки, на последних спринтах, вдруг появляется требование, реализация которого потребует критических по сложности и длительности доработок? Проще говоря, вся архитектура решения оказывается неподходящей для этого требования и оказывается, что придется все переделывать. Ведь архитектура строилась только исходя из предыдущих требований.
Есть ли в Agile приемы, которые помогут предотвратить такие ситуации?
Добавлю только, что agile помогает в этом случае тем, что вы начинаете перестраивать ваше приложение по итогам спринта, когда получили новые требования, а не через год, когда выпустили окончательный продукт, а он уже никому не нужен.
Ну почему же? В Водопаде ведь к началу разработки известны все требования. И разработчики разрабатывают архитектуру, видя всю картину требований, учитывая их все. А дополнительные требования идут сверх согласованного проекта и, соответственно, бюджета.
Понятно, что в Водопаде на подготовку такого ТЗ, которое содержит большинство необходимых требований и с высокой долей вероятности уберегает от таких сюрпризов, требуются огромные ресурсы.
Наверное, тут вопрос поиска компромисса между стоимостью и вероятностью "переделывать все".
CyberRich, все так, только, в очень быстро меняющемся мире, продукт приходится менять тоже постоянно, даже во время разработки. Собственно гибкие они потому и гибкие, что необходимо было менять вектор разработки даже во время разработки, иначе продукт выпущенный через год работы по водопаду может оказаться устаревшим и никому не нужным.
Это не значит что водопад плохо, просто где-то нужно одно, а где-то другое. Не всегда нужна эта гибкость, бывает четко зафиксированные, проработанные до мелочей требования важнее.
CyberRich, в agile Точно также можно кучу требований в самом начале сформировать, а большие переделки делать за отдельный прайс.
Agile появился как раз в ответ на то, что всегда в процессе приходит понимание, что во время планирования что-то не учли и не продумали, и что в конце говорят "а можно вот то же самое, но с перламутровыми пуговицами"
Если это не актуально, то можно спокойно составлять многотомное ТЗ с планом на три года - это будет дешевле.
Почему-то думаю, что никак. В этом-то и суть agile - не думать о глобальных проблемах, которых сегодня вроде-бы как и нет. Оно вроде-бы звучит правильно. Но всегда надо над архитектурой больше думать ,чем это требуют требования сегодня. Но. Это низя.
Мой совет - требование в топку. Хотя, если подумаешь ;). Но ведь без него тоже будет никак. Ну тогда выводится n-кол-во людей из под agile и они делают перезализ новой архитектуры в новой ветке. Это конечно-же те ещё грабли и обе ветки координировать - мало удовольствия. Увы - демаю рецепта нет.
Потому что нельзя помыться и не намочиться. А все этого только и хотят.
Ну обычно есть скрам-мастер, который пояснит тебе за ценности компании и скажет, что надо постараться всё переделать. А дальше ты будешь проявлять креативность, как на костылях и велосипедах это побыстрее переписать и забудешь про архитектуру и прочие глупости.
Никак не решается ни в оной методологии, верно тут пишут. У нас это новый проект. Мы закрываем стаарый, как не актуальный и открываем новый. Новый проект в WEEEK -новое ТЗ, выйди и зайди нормально, опиши еще раз, что хочешь сделать. На третий-четвертый раз инициаторы просто уже стараются сформулировать ТЗ так, чтобы таких факапов не было.
Простой
