современных реалиях водопад плохая модель? То, что пишут в профильных изданиях, так это то, что в водопаде сложно вносить изменения в требования, особенно на поздних стадиях проекта. Как правило нежданчики вылазят на стадии тестирования, это понтяно. А кто-нибудь может сказать, а почему собственно изменения сложно вносить? Я представляю, что раньше изменение требований означало перепроектирование и переписывание *ручных тестовых сценариев. Но в современном мире автотестов все сводится просто к переписываниею тестов и рефакторингу кода. Не получается, что мы изменения уже вроде как давно научились внедрять, а водопада боимся до сих пор?
Я бы больше делал упор не на "сложно вносить", а на долго получать фидбек от изменений. В водопаде много завязано на объёмной, предварительной работе с требованиями/архитектурой/документации, т.е. продумыванием, согласованием, написанием ее и т.д. В agile мы просто сокращаем время до получения фидбека. Например взаимодействия людей важнее документации, потому что так быстрее, и т.д. В современных реалиях водопад не плохо, это просто инструмент который надо понимать где и когда применять.
Так время тяжеловесных тулов для проектирования и документации прошло. Я не вижу проблем написать легковесную спеку, которая покрывает процентов 60% запланированных фичей, спроектировать "на салфектках", это сэкономит кучу времени на переделках, быстро заделиверить, сделать план на доработку, заделиверить по кусочкам. Это не Agile, и не Waterfall. Нечто, что люди называют Studio Model. Это как 3-d Way в Экономике.
Надеюсь не за горами время, когда не нужно будет описывать совсем ничего. И вся документация будет автоматизирована. Правда тогда одну ценность Аджаил придется пересмотреть 😅
Мне нравится чужое определение на эту тему, что agile and waterfall не что-то конкретное (а это факт, т.к. бОльшая часть споров-обсуждений в чате из-за не точных интерпретаций терминов), а точки на графике где график показывает длину обратной связи. Когда нам ничего не понятно, нам выгодно двигаться на угад маленькими шажками. Когда нам сильно бОльше понятно, нам выгодно заранее побольше вложиться в проектирование. Под вотерфлолом обычно понимают жёстко нисходящий подход разработки + отдельные полностью завершенные стадии сбора требований, проектирования и т.д. Это хорошо работает/работало когда нужно построить вундервафлю у которой требования можно зафиксировать и мы знаем как эти вундервафли строить мне кажется. Ну вот например как какое-нибудь оружие строят
спроектировать "на салфектках" - когда вы владелец продукта да, но как вы продадите эту идею заказчику которому делаете проект, ведь не все готовы потом на основании записи на "салфетке" принимать много миллионный проект.
У вундервафель требования не фиксируются. Точнее сказать они прописаны, но потом проводится конкурс между вундервафлями, и побеждает та, что лучше в характеристиках. См. историю принятия на вооружение всякого стрелкового оружия
Обсуждают сегодня