Нет, к счастью в этих, конкретных, проектах ощутимой разницы по времени разработки не было, так как большинство поздних комментариев не вело к изменению функциональности, а только к уточнению самой документации (например, у разработчика и QA было разное понимание написанного и приходилось уточнять), а те, что все-таки требовали внесения изменений в приложение были (вот тут я прям перекрестилась) незначительными. Но это скорее удача, одно пропущенное или неправильно понятое существенное требование могло очень серьезно повлиять на сроки.

Что до второго вопроса: по моему опыту команда гораздо лучше воспринимает запланированные заранее встречи с понятной повесткой, чем внезапное выдергивание потому, что «очень надо срочно спросить». Кроме того, тщательно спланированное общение отнимает меньше времени команды, т.к. меньше времени теряется на нерезультативном общении.

Статья об организации общения, а не о документации или задачах :-)

Ну вот это «ПО или QA пишет для чего задача нужна» — это и есть документация в вашем случае. Не важно кто пишет, это может быть и QA, и ПО и неважно где — хоть в вики, хоть в задачах джиры: главное, что есть кусок текста, который понятен и доступен всей (это ключевое!) команде (то есть и разработчикам, и QA и владельцу продукта) и который может быть использован как референс. О чем мы тогда спорим?

Например для того, чтобы каждый новый член команды не задавал одни и те же вопросы. Или, чтобы наткнувшись на код, который реализует странную функциональность, команда понимала, откуда это взялось, а не пожимала плечами «так исторически сложилось». Обычно документируются самые важные, критичные для системы, требования. Понятно, что поведение кнопки при использовании гибкого подхода описывать никто не будет.

Дякую!

Вообще-то гибкий подход как раз позволяет сократить объем документации за счет активного и часто спонтанного общения (возник вопрос — сбегал к продакту за ответом). Вариант делать как на душу ляжет в рассчете, что ПО все увидит и поправит на демо — так себе идея, хотя бы потому, что не все, в принципе, на демо можно увидеть, и не обо всем догадаться спросить. И тогда при выходе в прод будет большой бабах, если, например, компанию оштрафуют по результатам аудита за неправильное исполнение какого-нибудь пункта законодательсва.

Можно со мной подискутировать, хоть я и не Денис :-) Процесс может быть любой, и адаптивный (agile подход) и предиктивный. В статье я говорю о том, как структурировать общение, это не зависит от подхода.
Мое мнение — планирование и структуризация общения трудозатраты сокращает, так как на выходе получаем меньше общения с нулевым выхлопом (а при ad-hoc общении выхлоп часто бывает нулевой, т.к. участники не всегда готовы предметно отвечать на вопросы, которые им вдруг решили задать :-) )