RA
Двухнедельный спринт. Большие задачи бились на более мелкие атомарные. Перетекания из спринта в спринт были, причем довольно часто. Очень часто были ситуации, что накапливалось много задач, человек, который должен был вливать все в ветку и запускать сборку на тестовый стенд, был загружен своей основной работой. В итоге к концу спринта все вливалось и задачи целой пачкой падали на тестирование. Конечно же тут был выбор, либо тестировать поверхностно, чтобы не портить показатели спринта, либо просить людей перекидывать в следующий спринт. При первом подходе бывало, что пропускали дефекты на прод, опасные с точки зрения бизнеса. При втором подходе вероятность пропуска бага была ниже. Также мы не старались напихивать под завязку спринт, он у нас не был каким-то статичным, он был таким резиновым и наполняемым. Мы оставляли место для критов, внезапных хотелок заказчика и для багов, которые могли родится вследствие тестирования задач в спринте, также оставлялось некоторое пространство для задач, которые будут гоняться из тестирования в багфикс и обратно. Если мы понимали, что по окончании спринта мы не дотягиваем по сторипоинтам, то брались мелкие задачки и разного рода техдолги, чтобы разгрузить разрабов и дать им по фану на расслабоне наклепать мелких задачек
Действительно, практически идентичный нашему workflow, за исключением того, что мы не можем планировать бизнес-задачи на несколько спринтов вперед, потому что приоритеты у бизнеса меняются, и более-менее стабильный список задач в новый спринт мы получаем в конце текущего. Также мы обычно забиваем спринт под завязку. Возможно, это тоже вносит свою негативную роль.
