Во-первых, чтобы ответить на ваш вопрос, я должен прояснить, что никакие Agile-структуры или методологии не пытаются определить все, что может понадобиться команде (особенно Scrum), поэтому нет ничего плохого в добавлении дополнительных артефактов или практик, которые находит команда.полезно, если они не противоречат определенной практике.
Есть несколько мест, в которых я обычно вижу записанные нефункциональные требования.Вот некоторые из наиболее распространенных:
Определение выполнено
Определение выполнено содержит стандарты качества, которые должны применяться ко всем элементам невыполненных работ, которые проходят через,Часто это включает в себя такие вещи, как «n% модульного тестирования кода», «изменения кода и конфигурации были проверены коллегами» и «все автоматизированные регрессионные тесты были выполнены и успешно пройдены».Иногда я видел более широкие нефункциональные требования, такие как «без изменений, время загрузки приложения превышает X мс».
Документы архитектурного проектирования
Вы все еще можете иметьэто в Agile.Вместо того, чтобы устанавливать законченную архитектуру в начале проекта, они вводят ограничения, в которых должна оставаться архитектура.По мере выполнения проекта и принятия или изменения архитектурных решений эти документы обновляются для отражения этой информации.Примерами ограничений могут быть: «Система X считается авторитетным источником личных данных клиентов» или «Детали, необходимые для обработки платежей, никогда не должны быть доступны общедоступному серверу, чтобы уменьшить возможности атак на эти данные».
Фрахтование продукта
В зависимости от проекта, «начать прямо сейчас» может быть немного изменчиво.На очень больших проектах или продуктах нередко требуется несколько дней (по моему опыту, 1 - 3 - хорошее число), чтобы зафрахтовать проект.Это может включать в себя определение персон, обеспечение того, чтобы заинтересованные стороны бизнеса и члены команды имели общее понимание видения, обсуждали ожидаемый пользовательский опыт и проблемы на высоком уровне и т. Д. Очень часто, что нефункциональные потребности возникают здесь и должнызаписываться либо в DoD, существующих архитектурных документах, либо в некоторых случаях в элементах невыполненных работ.Хорошим примером этого является то, что называется матрицей компромисса.При построении матрицы компромисса мы говорим об ограничениях проекта, таких как производительность, адаптивность, набор функций, бюджет, время и т. Д. Мы идентифицируем одно как основное ограничение, два как вторичное, а все остальные считаются третичными.Это не жесткое и быстрое правило, но оно устанавливает общее понимание того, как в работе будут решаться компромиссы с нефункциональными потребностями.
Элементы невыполненных заказов
Хорошо, последний.Не все элементы бэклога должны быть пользовательскими историями.Если у вас есть действующее нефункциональное требование (настроить сервер, перенастроить брандмауэр, команде нужно перейти на новую версию IDE), ничто не помешает вам создать элемент невыполненной работы для этого.Это не история пользователя, но это нормально.Я предупрежу, что большинство команд находят корреляцию между количеством элементов в бэклоге, которые являются пользовательскими историями, и их способностью эффективно приносить пользу и адаптироваться к изменениям на этом пути, так что не отчаивайтесь.Но я бы предпочел, чтобы команда включила неамериканцев в свое отставание, чем пытался выдать эти вещи в виде пользовательских историй, таких как «Как брандмауэр, я хочу обновляться, чтобы мы не получали h @ XX0rD» <- реальный элемент отставания, который я видел. </p>
В заключение: помните, что в Agile мы стремимся адаптироваться к изменениям, поэтому не беспокойтесь о том, чтобы DoD или архитектурный документ в первый раз были идеальными.Это может измениться, когда вы узнаете больше.