В проектах гибкой разработки (agile) нет формальной операции визирования. В таких проектах требования обычно хранятся в виде пользовательских историй в резерве (backlog) продукта. Владелец продукта и команда согласовывают, какие рассказы будут реализовываться в следующей итерации, в процессе совещания по планированию. Набор историй выбирается на основе приоритетов и скорости работы (продуктивности) команды. После определения и согласования набора содержащиеся в итерации истории замораживаются.
Новые запрошенные изменения планируются только на будущие итерации.
В проектах гибкой разработки никто не пытается получить одобрение заинтересованного лица сразу на весь набор требований. В таких проектах полный набор функциональности определяется со временем, хотя концепция и другие бизнес-требования должны быть определены с самого начала.
В проектах гибкой разработки владелец продукта публично принимает
или отвергает требования на итерацию, которые представляют собой набор
историй и связанных критериев принятия и приемочных тестов. Конечное
«подписание» заключается в приемке работающего и протестированного
ПО, полученного на данной итерации.
Даже в среде гибкой разработки принцип визирования может играть полезную роль. Гибкость говорит нам «полагаться на изменения», но сама концепция изменения существует только в связке с точкой отсчета. Даже в команде, где ее члены тесно общающихся друг с другом, у людей могут быть разные интерпретации текущих планов и состояния. Предложение об изменении, представленное на рассмотрение одним человеком, другой может посчитать уже согласованным. Однако если процедуру визирования считать как упрощенный церемониал признания, что «мы находимся на таком и таком этапе», то это нормально. Такое утверждение не означает, что завтра мы не можем быть в другом месте, но как минимум это обеспечивает взаимопонимание и общую точку отсчета.
Разработка требований к ПО. Карл Вигерс и Джой Битти.