JAD-сессии нужны для тщательного создания детальнейшего ТЗ?
Зачем же так страдать, когда уже есть Agile :))
Правда далеко не всякие внедрены готовы на это пойти
Большинство по-прежнему верны проверенному Waterfall-у
и много томным Техническим Заданиям ))))
Ответ на первый вопрос - нет. Если воспринимать JAD-сессии исключительно как инструмент тщательного и детального создания ТЗ, то я соглашусь с тем, что это сущее страдание.
Но и использование Agile без разрешения конфликтов на уровне заинтересованных сторон - весьма затратно для компании-заказчика.
Почему обязательно "детальнейшее"?
ТЗ тоже стоит создавать итеративно. Собственно, ISO/IEC/IEEE 29148:2011 как раз и предлагает создавать ТЗ в несколько этапов, на каждом - детализируя и углубляясь (при необходимости) [вот все руки не доходят выложить наши наработки по созданию ТЗ в соответветствии с этим стандартом...]
Так что JAD-сессии в нашей практике - наоброт, инструмент скорейшего сбора информации, получения полной картины. А уж уровень детализации зависит от ситуации.
Кроме того, мы используем подходы JAD для получения картины бизнес-процессов. За несколько часов не только аналитики получают "картину" процессов, но и участники (особенно - руководство заказчика) узнают много нового о своей компании :)
Что касается agile... Во-первых, это вообще - сильно широкое понятие :) Во-вторых, как более-менее полноценно организовать agile-проект у заказчика, напрочь далекого от ИТ?