Евгений Савицкий, Потерянные практики работы с требованиями в Agile

Понятие "Требование" в последние годы очень сильно размыто в ИТ-сообществе, особенно это связано с повсеместным внедрением гибких подходов (Agile). Теперь под требованиями понимается любая заявка заказчика, оформленная в небольшую историю пользователя (или фичу, кому как удобнее).
Пара предложений описания для каждой истории, список историй как баклог продукта - очередь требований для разработки. Управление требованиями как изменение приоритетов историй в очереди.
Это отлично работает для небольших проектов и простой предметной области, но что если мы говорим об Enterprise секторе (банки, крупное производство и тп)? Проектные команды из десятков людей, множества согласующих подразделений, требования регуляторов и безопасников..
Agile возможен и в таком окружении - вы, правда с некоторыми трудностями, сможете внедрить Scrum или Kanban в таком проекте, но простой очереди хотелок, о которой говорит скрам, вам конечно же будет мало.
И здесь на помощь приходят забытые большинством, потерянные практики работы с требованиями, наработанные десятилетиями, и за последние годы адаптированные под потребности современных процессов.
Как найти балланс между гибкостью и необходимым уровнем документации на проекте? Как облегчить жизнь команде, не прибегая к созданию 100 и более страничных документов требований, но при этом анализируя и фиксируя все необходимое? Как упростить процедуры согласования различными подразделениями? Как организовать гибкий репозиторий требований с бейзлайнами и версионированием, понятный любому инженеру проекта: разработчику, аналитику, тестировщику.
Приходите на доклад и мы поговорим об ответах на эти актуальнейшие вопросы!