Название очень хорошо отражает суть вопроса. Как ты это делаешь? Стоит ли вообще превращать внедрение HTTPS в пользовательскую историю?
Я подумал о:
« Как посетитель страницы, я хочу, чтобы вся связь со службой была безопасной, чтобы сохранялась целостность данных ». Звучит довольно глупо, если вы спросите меня. Наоборот было бы:
« Как технический менеджер я хочу, чтобы доступ к веб-странице был безопасным, чтобы информация от посетителя страницы была в безопасности ». Тоже глупо звучит.
Я бы сосредоточился на необходимости , а не на реализации. Пользовательская история тогда будет просто:
«Как пользователь, я хочу, чтобы любая личная информация, которую я передаю (Компании), оставалась конфиденциальной и защищенной».
Тогда как HTTPS является деталью реализации этой истории. В конце концов, если бы вы нашли какой-то другой способ выполнить требование (например, вообще не получать никакой личной информации), то HTTPS стал бы неактуален.
Вы также можете добавить что-то вроде «даже от злонамеренного злоумышленника», что должно сделать его более проверяемым (см. Мнемонику INVEST ) — убедитесь, что все распространенные атаки (кроме социальной инженерии, которые на самом деле не разрешимы...) терпят неудачу.
Просто имейте в виду, что пользователю все равно , защищена ли веб-страница. Они заботятся о том, чтобы их данные не были скомпрометированы. У вас может быть пользовательская история (потенциально очень большая), чтобы все необходимое для защиты было защищено. (Однако, в зависимости от того, насколько он велик, это может сделать INVEST недействительным.)
В качестве альтернативы вы можете запечь его в своем определении готовности (см. этот ответ ). Обратите внимание, что DoD не является пользовательской историей, задачей или эпиком сам по себе — это часть критериев приемлемости для историй. Если ваш DoD содержит достаточную безопасность в качестве требования, а у вас есть история, которая еще не имеет такой защиты, то история не может считаться «Готовой» (и, следовательно, сгорела), пока она не будет соответствовать требованиям DoD.
Прежде всего, вы потенциально неправильно используете пользовательские истории как механизм. Пользовательская история возникает из реальной потребности, ее не следует придумывать или изменять под процесс.
Во всяком случае, это может быть что-то вроде:
Как главный менеджер по безопасности, я хочу, чтобы вся связь между всеми нашими приложениями и всеми клиентами осуществлялась через HTTP, чтобы снизить риск атаки MITM.
Или же:
Как посетитель страницы, я хочу видеть в своем браузере «зеленый замок», чтобы чувствовать себя в безопасности и защищенным.
Обратите внимание на разницу между ними. Например, если у вас есть мобильное приложение с взаимодействием клиент-сервер, история API — first заставляет вас охватить и их.
Вы также можете просто иметь это как общую «задачу». Не все нужно писать в формате пользовательской истории.
Рекомендовал бы «Внедрение HTTPS» в качестве названия задачи.
Пользовательские истории отлично подходят для описания проблемы, особенно с точки зрения клиента (или в его шкуре). Они также помогают клиентам структурировать свои проблемы таким образом, чтобы они с меньшей вероятностью предлагали то, что, по их мнению, является решением.
Но вам нужно быть практичным, это часть Agile-манифеста.
Здесь нет непонимания проблемы; здесь нет отличной интерпретации и не требуется «непредвзятости». В этом случае пользовательская история может исказить очевидный результат.
Сделайте себе и своей команде одолжение, сделав это простым. Но обязательно регистрируйте, отслеживайте и создавайте определение готовности, чтобы его можно было протестировать и оценить.
Саров
Мухаммед