а можешь свой опыт описать?

а зачем?

чисто письками помериться?

могу конечно

ну вот мой опыт подсказывает что такие подходы приносят боль

а еще есть целые книжки

и я сам так периодически делаю

и много людей

и испытываю боль

с опытом

которые тоже скажут о боли

я могу свой опыт описать и сервисы в разработке которых принимал участие

не не

но не думаю что это стоит делать тут

без деталей

размеры команд хотя бы, количество изменений в требованиях в неделю

количество багов

среднее в неделю

сберу делали учет налогов на java 2 команды в разных городах (численность разработчиков от 15 человек суммарно, плюс аналитики тестировщики и тд)

мои позиция от разраба, до core разраба

в команде

позиции не интересны

про требования в доваться в подробности?

интересна скорость разработки и количество регрессий

реакция на изменения

вот такие метрики меня лично интересуют

как быстро от "хотелки" до "выкатить клиенту"

как долго вообще проект жил?

там enterprice

год, 2, 5?

10?

не не

разработка больше 2 лет

т.е от хотелок до продакшена 2 года?

в планах я работал 1 год

ну это уже говорит о так себе скорости разработки. нет?

это говорит о гибкой методологии

и я хз с какой скоростью ты реализуешь текущие налоговые требования

при гибкой методологии ты должен был за пару месяцев выкатить MVP и потом 2 года развивать

я вижу только раздутые сроки

и генерацию форм

так там и были релизы

промежуточные и сдача заказчику

а ну окей

ты спросил про сроки проекта

тогда повторюсь

а не про длину спринтов

от "хотелки" до "продакшена" в среднем сколько?

и я не про спринты

там график был по релизам

меня интересуют цикл обратной связи

в среднем раз в 3 месяца отдавали подрядчику на пси и ввод в эксплуатацию

за 3 месяца примерно 3 промежуточных релиза команды

или даже 4

говорить могу потому что nda закончился

теперь давай о твоем опыте

или nda не позволяет разглашать ?

ну без конкретики я как бы nda и не нарушу)

> за 3 месяца примерно 3 промежуточных релиза команды как-то мало... мы хотя бы раз в 2 недели релизим итерацию...

хотя pci конечно

там своеобразный agile был

на одном из проектов где надо было pci делать мы просто разделили систему на две

часть которая хранил данные карточек, и все остальное

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

у нас на подобе было

логика расчеты налоговых форм на grovy было

а сейчас - все пейменты через блокчейны проводим...

там как-то проще

а api для данных и взаимодействия с системой на java

из груви дергали сервисы которые давали нужный результат

ну мол сервер ничего не хранит, а потому париться о безопасности приходится меньше

а у нас тестили просто, брали формы за прошлый год )

забивали показатели и расчитывали и сравнивали)

но в целом... по изменению требований... один проект - мы сами виноваты в большом количестве изменений, поскольку там бизнес специфичный со своими процессами и хотелками, которые нифига не очевидны. А на другом проектике клиент... не оглашал что должно получиться до последнего)

загадочные люди

везде свой геморой

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

когда команда больше хотя бы 3-х человек и темпы разработки не позволяют расслабляться

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

но допустим тот же отказ от геттеров пока приносит плоды

системы стала более предсказуемой

я тоже, сейчас на пхп пишу)

но я еще не рискую заставлять своих так делать

просто потому что все жду что "что-то пойдет не так"

ну да у людей много мнений

самое смешное, что если задуматься то все это логично и просто... но когда 8 лет писал геттеры то переключить мышление не так просто

ну хз меня не гетеры в коде с кординатами напрягают

я тоже, сейчас на пхп пишу)

странный немного выбор после groovy/java

а то что при вызове метода у объкта с одним GeoCordinat

можно получать разные результаты

если есть сеттер по изменению кординаты

если нужно определять дистанию на плоскости и метод такой только один

то нет смысла фигарить сервис

можно и в самом объекте делать

но обычно определенем растояни дело не заканчивается

а то что при вызове метода у объкта с одним GeoCordinat

в смысле? как так то?

и изначальный объект хранит кучу разной логики, правда она касается координат но все же не приятно

ну в твоем коде нет сеттеров