Здравствуйте, dangler, Вы писали:
D>Согласен про рефакторинги. Тут как раз идет сравнение времени, которое тратиться на разработку детального SRS а потом архитектуры со временем, которое мы может потратим (а может и нет) на последующие рефакторинги. Причем TDD во многом удешевит стоимость рефакторингов и последующего перетестирования.
Возможно, ..но в классике юниттесты никто не запрещает.
D>Это что за баги такие, которые «известны девелоперам», но еще не пофиксаны?
не буду углубляться в детали различных недоделок которые имеют место в незаконнченном продукте. Коротко пример: Новый функционал затрагивает рефакторинг старого кода, в котором временно ставятся "заглушки" (известные девелоперам

). Тут заканчивается спринт и тестировщики начинают писать баг репорты если заглушка оказыватся в поле их тестов по данному спринту. Что тут удивительного?
D>Все зависит от уровня команды по умению эстимейтить и от умения скрам-мастера объяснить заказчику откуда баги и что с ними будет сделано в ближайшее время . А если команда умеет правильно эстимейтить – то билды после каждой итерации выглядят очень симпатично, и заказчик от этого только становится более счастливым. Это я говорю исключительно на примере моего текущего проекта: у нас бежит уже 12ый спринт, и команда вышла на такой уровень, что без всякого аврала в конце спринта мы показываем заказчику полностью работающую ф-ть, которую мы и планировали в начале спринта. Очень приятно.
Похоже что у вас сферическая команда в вакууме
D>А по второму пункту – вот у нас сейчас пойдет в продакшен функциональность, которая была разработана за последние 4 спринта (2 месяца). Причем с этой функциональностью знаком уже и конечные пользователи за счет того, что мы ее им презентовали уже 3 раза (в конце каждого спринта). И не ожидается никакого «потная тех-поддержка и нервно курящие тестировщики».
D>Все зависит от того насколько правильно поставлен процесс
D>Да, после каждого спринта в продакшен выходят очень редкие продукты (в конце спринта должен быть “Potentially shippable” билд, а вовсе необязательно продакшен), но все-равно продакшен случается намного чаще, чем при Waterfall и других моделях/методологиях разработки.
Повторяю — показать из далека или отдать на реальное пользование — разные вещи.
И вообще, наверное мы говорим о разных вещах. Я о коробочном продукте для больших контор, которые физически не могут (и если и могут то им там по правилам не положено) делать апдейты в продакшн чаще чем раз в полгода, а после оффициального релиза продукт еще и тестируется в течении пары месяцев самыми консервативными заказчиками.