Как стать автором
Обновить

Комментарии 4

Гибкие методологии не особо подходят под большие данные. Кодирования на день, расчётов на неделю. И так в каждой реальной задаче.
Если это задачи про дата дискавери или проверку гипотез, то они как правило «мимо кухни» — тут дата сайнс аналитик вполне экипирован для самостоятельного написания запроса, скажем на Pig или Python. Расчет может идти хоть 3 недели. Хотя конечно сэмплирование еще никто не отменял и голову тоже)
То где соблюдение методологии на 100% полезно — это разработка промышленного продуктивного кода, классическая задача разработки и поставки ПО. У нас этого много, и софт высоконагруженный.
так а чем использование данных методологий для Big Data проектов отличается от их использования в не BigData?
У нас то же самое. То же пришли к канбану.
Только похоже дальше продвинулись.
Чего будет дальше:
1. Этап моделирования архитектором, после анализа. Нужно когда разработчиков много, проект большой, и реализацию нужно выполнить правильно, с точки зрения архитектуры системы.
2. Этап ревью. Ну тут понятно. У нас не только техническое ревью, но и даже ревью анализа есть.
3. Полноценный этап тестирования. Ни какой uat не проведет регрес тестирование и не проверит, что не поломалось старое, или соседнее или еще что-нить. Да и вообще полноценные тест кейсы надежнее чем Uat который зачастую идет «на глаз». Но UAT никто не отменяет!!!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий