Agile nonfunctional Requirements

Конспект статьи. Автор оригинала: Иван Загребельный (база знаний emacsway)

Подборка мнений Карла Вигерса, Кена Рубина и Дина Леффингуэлла о том, как работать с НФТ в гибких методологиях.

Главная идея

НФТ нельзя откладывать на поздние итерации — их приоритизируют наравне с пользовательскими историями. Производительность деградирует по мере добавления функций, поэтому цели задают и начинают проверять с первых итераций.

Проверяемость

«Быстро» не проверить, конкретный порог времени отклика — проверить. Приёмка итерации включает проверку выполнения соответствующих НФТ.

Кто отвечает

• В Scrum критерии приёмки, включая НФТ, — зона Product Owner. Каждое НФТ — кандидат в Definition of Done.
• В SAFe НФТ определяет системный архитектор или архитектурная команда.
• Product Owner может делегировать часть работы аналитику или архитектору — важно, как организован процесс.

НФТ как ограничения бэклога

Леффингуэлл моделирует НФТ как ограничения: одна история может подпадать под несколько НФТ, одно НФТ — относиться ко многим историям («поддерживать 100 одновременных пользователей»).

Как хранить

Истории после реализации закрепляются в приёмочных тестах. Часть НФТ тоже покрывается автотестами (нагрузочный тест в регрессе), но многие — нет: соответствие PCI DSS, локализация, юридическая проверка открытого кода. Для них нужен отдельный бэклог, вики, дополнительная спецификация или ссылка из DoD.