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

Начнем с нефункциональных требований. Во-первых сразу хотелось бы отметить, что сами по себе они очень важны. Но из-за специфического названия многие склонны о них забывать. Часто заказчики даже не понимают о чем идет речь: «Нефункциональные требования? Нам в первую очередь нужен качественно сделанный функционал!». Мне гораздо больше нравится понятие «качество сервиса» (quality of service). Ведь качество всегда является важным фактором и его нельзя игнорировать. В это понятие входит доступность, надежность, производительность, расширяемость, устойчивость и так далее. При такой формулировке нефункциональные требования превращаются в качественные показатели системы. Если задать вопрос заказчику об его ожиданиях от качества разрабатываемого продукта, то он с радостью поделится с вами, так как вопрос будет ему понятен и важность его будет действительно высока.

Второй термин, который хотелось бы обсудить – это приемочный критерий. На первый взгляд с ним все нормально. Заказчик или «владелец продукта» (Product Owner) формулирует приемочные критерии для каждой новой функциональности системы, после чего они используются для написания приемочных тестов, модульных тестов, интеграционных тестов, а также приема готового функционала. Но что если заказчик не готов придумывать и выставлять приемочные критерии? Что если фаза приема нового функционала вообще отсутствует на проекте? В этом случае теряется смысл слова «приемочный» и многие попросту начинают игнорировать приемочные критерии, тем самым лишая команду разработки важного артефакта. Мне больше по душе термины «критерий готовности» (Definition of Done) или «критерий завершенности» (completion criteria). Цель этих терминов очень похожа – указать, что необходимо сделать чтобы функциональность считалась готовой или завершенной. Добавлять критерий готовности может кто угодно: разработчик, лидер команды, менеджер проекта, тестировщик. Физически данные критерии добавляются в описание задачи в системе управления задачами или на доску задач. Для этого может быть использовано описание задачи или отдельная секция под названием «как продемонстрировать» (how to demo). Например, для регистрации пользователя в приложении могут быть использованы следующие критерии готовности:

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

Критерий готовности позволяет ничего не упустить в процессе разработки функциональности и является источником для тестов. В случае использование формального приема функциональности заказчиком эти же критерии могут быть успешно использованы.

Используйте такую терминологию, которая будет понятна всем в вашей команде и за ее пределами!