Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.
На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
В каком определении? Есть, например, «The Manifesto for Agile Software Development». И написано там совсем не «аджайл нужен когда полноценное ТЗ до начала проекта не получить».
Т.е. вы основываетесь на каком-то своём видении аджайла, а не на конкретном определении. Какой смысл тогда обсуждать, что является аджайлом, если вы это слово можете по своему понимать?
Интересно, основываясь на каких определениях аджайла и водопада вы делаете такие утверждения? Потому что на мой взгляд я описал достаточно типовую ситуацию и примерно равноудалённую от чистого водопада и чистого аджайла.
Чего это вдруг? Например, если я делаю интернет-магазин и заказываю у некого подрядчика сначала витрину, прописываю всё ТЗ и он уходит на месяц его пилить и приносят результат. Пока он пилит — я прописываю ТЗ на корзину и страницу заказов. И потом еще так же модуль кросс-сейлз и рекомендаций. Это что? Аджайл? Ватерфол?
В основе аджайл и ватерфол лежит на мой взгляд один и тот же цикл проектного управления, просто в аджайле он повторяется очень много раз, а в ватерфол 1 раз за весь проект. Соотв. всё что кроме аджайла и ватерфолл может быть посредине между этими крайностями, например, квартальный проект разбитый на 3 месячных этапа, на каждом из месячных этапов будет ватерфолл.
На мой взгляд проблема не в скраме, а в людях, которые полностью упускают из виду другие аспекты разработки, кроме как регулярное и прогнозируемое закрытие тикетов на мелкие задачи.
Я просто про метрику говорил. Не про оценку эффективности. Количество строк кода среднее в день зависит от огромного числа факторов. Гораздо большего, между прочим, чем общая длина швов у хирурга.
Это конечно интересно, обсуждать абстрактные строчки кода, да еще и по однобокому описанию ситуации, только вот ситуация в реальном мире может быть кардинально разной, вот навскидку три варианта:
1. Реально сложный проект с какой-нибудь математикой или нетривиальными алгоритмами (кодеки, рейтрейсинг, библиотеки машинного зрения или ML и т.п.)
2. Разработчик нагородил чудную конструкцию из костылей и подпорок и теперь сам не может в ней разобраться
3. Разработчика назначили на поддержку проекта и он просто потратил много времени на то, чтобы понять что где происходит в чужом коде.
Рассуждать про абстрактную измеримость или нет ценности абстрактных 2 строк кода это не лучшее занятие.
Так самую тривиальную и тестировать смысла нет, ибо гораздо более сложные кейсы и так будут проверены в ходе е2е тестов, которых всё равно не избежать, т.к. проверять в сборе фронт+бекенд всё равно надо. А возможность за 5 секунд отловить ошибки до е2е тестов — так мы в этот модуль переходов изменения вносим раз в полгода максимум, поэтому нецелесообразно их проверять отдельно.
В теории да, но тогда и тесты все на отрисовку состояний по сути, а не на какую-то логику «руководителя» (т.е. у нас практически нет никаких ToDoList'ов хранящихся на фронте). А если мы хотим проверить реальные переходы как срабатывают — так надо тогда весь флоу реальных переходов и эмулировать.
У нас кредитный брокер. Ключевой процесс — оформление кредитных заявок и выдача кредитов с кучей вариантов, которые приходится учитывать, т.к. мы консолидируем продукты различных банков. Одних только схем подписания 3 класса.
Правильно замокать флоу всех этих вариантов процессов и потом это поддерживать это тот еще спорт.
В целом ваша идея понятна — не мокать всё подряд, мокать только сервисы работы с внешним миром. Ну хорошо если у вас такой низкий уровень связности с внешним миром, что от таких тестов много пользы.
Отдельная история — замокать все АПИ-сервисы сразу на все случаи жизни. При сложном бекенде это так себе. Мы это проходили.
У нас в проекте любые тесты без живого бекенда оказались нецелесообразны, поэтому сейчас только e2e тесты на реальном бекенде на копии продуктовой базы. Да долго, да ресурсы, но от остального пользы меньше, чем затрат на поддержание. Зато такие е2е тесты выявили сразу еще пачку сопутствующих проблем в инфраструктуре и на бекенде, сплошная польза вышла.
Если что — у меня не праздный интерес ко всему этому, мы сейчас на распутье — надо нам в ангуляровском проекте какие-то тесты кроме e2e или нет. И пока я глядя на фактический поток багов вижу, что остальные виды тестов для нашего проекта получаются просто нецелесообразны.
Т.е. почти всегда мы бы просто не догадались написать конкретно такой тест, который поймал бы баг (например при создании этот компонент так не планировали использовать).
Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.
На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
1. Реально сложный проект с какой-нибудь математикой или нетривиальными алгоритмами (кодеки, рейтрейсинг, библиотеки машинного зрения или ML и т.п.)
2. Разработчик нагородил чудную конструкцию из костылей и подпорок и теперь сам не может в ней разобраться
3. Разработчика назначили на поддержку проекта и он просто потратил много времени на то, чтобы понять что где происходит в чужом коде.
Рассуждать про абстрактную измеримость или нет ценности абстрактных 2 строк кода это не лучшее занятие.
Правильно замокать флоу всех этих вариантов процессов и потом это поддерживать это тот еще спорт.
Отдельная история — замокать все АПИ-сервисы сразу на все случаи жизни. При сложном бекенде это так себе. Мы это проходили.
У нас в проекте любые тесты без живого бекенда оказались нецелесообразны, поэтому сейчас только e2e тесты на реальном бекенде на копии продуктовой базы. Да долго, да ресурсы, но от остального пользы меньше, чем затрат на поддержание. Зато такие е2е тесты выявили сразу еще пачку сопутствующих проблем в инфраструктуре и на бекенде, сплошная польза вышла.
Т.е. почти всегда мы бы просто не догадались написать конкретно такой тест, который поймал бы баг (например при создании этот компонент так не планировали использовать).