Здравствуйте, robin_of_the_wood, Вы писали:

___>Ваша демонстрация очень однобокая.

Ну я надеялся, что сарказм будет заметен.

___>Создается в впечатление, что ни ревью, ни конфликтов при комите, ни падающих тестов, ни командной работы в "обычном" подходе нет.
___>А это не совсем так.

Э, вы ж не о том. Конфликты, падающие тесты, внезапно обнаруженные недоработки, необходимость что-то дописать/переделать и т.п., конечно, бывают везде. Но у agile-методик есть неприятная особенность — если ими бездумно (или слишком фанатично) пользоваться, то подобные вещи оборачиваются авралами, которые начинают повторяться чуть ли не в каждый спринт. И если в случае классического подхода поработать до ночи раз в два-три месяца перед дедлайном — это не такая уж большая сложность, то еженедельные пятничные посиделки очень быстро задалбывают до невозможности. Особенно ярко это проявляется, когда руководитель проекта не вкуривает разницу между завершением спринта и зеленым свистком для выкладывания новой версии в продакшен. И когда планирование задач на неделю начинается словами "в этот спринт мы должны все сделать, потому что заказчику я обещал это к следующему вторнику". После чего уже можно сразу идти и запасаться пивом — вероятность того, что в пятницу будет вышеописанный аврал и пиво под вечер тебе пригодится, после таких слов вырастает обычно почти до ста процентов.
С другой стороны, если руководитель адекватный, то работать по agile, конечно, гораздо приятнее. Тут не поспоришь — драйв от постоянного улучшения продукта и ощущение вовлеченности в общее дело ни в какое сравнение не идут с рутинным многонедельным копанием в недрах "родного" модуля. И, собственно, выше я с этим нисколько не спорил — меня просто удивляет, насколько легко весь этот позитив может превращаться в банальную соковыжималку...

___>А у Вас весь негатив оказался только в описании второго подхода.

Ну я надеялся, что сарказм будет заметен.