При таком подходе возникает и другая проблема: команда не фиксирует принятые решения, описание предметной области. То есть “в скраме” отсутствует документооборот, все на словах.
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?
Ну, предположим, мы зафиксируем «знание» в документе на 500 страниц. Чем оно будет отличаться от ТЗ на 500 страниц на входе, которое не читают?
Нужны документы с логическое схемой для «введения», со всеми связями. Нужны описания моделей данных, нужны описания спецификаций API и процессов. Последние три группы должны либо быть кодом, либо из него генерироваться, чтобы не дублировать источники знаний.