Как написать пользовательские истории для технических деталей реализации?
Я пытаюсь работать более организованно и начал принимать истории пользователей.
Я думаю, что у меня неправильное понимание того, как я должен использовать пользовательские истории для технических вещей.
Допустим, я пишу приложение, которое дает мне рейтинг моего сайта по определенному ключевому слову в Google.
Пользовательская история выглядит так:
Как интернет-маркетолог
Я хочу узнать, где мой веб-сайт занимает ключевое слово
Так что я буду знать, работают ли мои усилия по SEO
Теперь это довольно просто и ориентировано на пользователя... Однако, что произойдет, если мне нужно будет ввести Прокси в цикл.
С одной стороны, прокси - это технические детали реализации, с другой стороны, прокси - часть домена интернет-маркетингу.
Как мне создать такую историю?
Как интернет-маркетолог
Я хочу использовать Прокси при поиске в Google
Таким образом, мы сможем проверить много ключевых слов, не блокируя нас Google
Приведенный выше сценарий не подходит для меня... Может быть, я могу переписать его примерно так:
Как интернет-маркетолог
Я хочу иметь возможность проверить много ключевых слов одновременно
Так что это сэкономит мне время
Это звучит более правильно, однако, какие критерии приемлемости я могу дать? Попробуйте очистить Google 100 раз в минуту? Разве это не пустая трата времени?
Вот еще один сценарий. Как мне создать пользовательскую историю, если функция, которую я хочу реализовать, заключается в том, что прокси-сервер можно использовать один раз в 30 секунд? Я понятия не имею, как подойти к этой проблеме с точки зрения пользователя...
Еще одна вещь, которую я подумал сделать, это представить другую Role, Вместо того, чтобы сосредоточиться вокруг Internet MarketerЯ могу сказать, что у нас есть роль под названием Google Scraper, Я могу сказать, что Internet Marketer в связи с Google Scraper,
Теперь я могу написать историю пользователя, например:
Как Google Scraper
Я хочу менять прокси каждый поиск
Так что Google не забанит меня
Что бы вы сказали о деталях технической реализации, как описано выше? Это также может помочь разбить систему на модули...
2 ответа
Вы не пишите технические истории. Пользовательские истории должны соответствовать критериям INVEST.
Прокси действительно похожи на детали реализации, и их следует избегать. Вы не должны упоминать прокси-серверы в своей истории. Даже если они являются частью домена, есть потенциально другие способы достижения того же эффекта.
Вместо того чтобы писать "Я хочу использовать прокси, чтобы меня не блокировали", вы должны написать "Я хочу скрыть свою личность, чтобы меня не заблокировали". Если бы я был вашим клиентом, я бы не знал, зачем вам нужен прокси? Это прямой, открытый или обратный прокси? Существует множество вариантов использования прокси-сервера. Вы должны выбрать функцию, которую вы хотите использовать.
Тем не менее, вы не должны быть слишком одержимы идеальными историями. Гибкий манифест гласит: "Индивидуумы и взаимодействия над процессами и инструментами".
При написании пользовательской истории вы также должны учитывать 3 С: Карточка, Разговор, Подтверждение. И клиент, и вы понимаете смысл истории?
Соответствует ли карта критериям INVEST? Если вы ответили утвердительно на оба этих вопроса, значит, история в порядке.
Пользовательские истории не должны включать технические детали. Во время планирования спринта технические детали должны быть добавлены в виде задач группы доставки, вложенных ниже пользовательской истории. Эти задачи должны быть созданы путем обсуждения командой доставки. Вы не должны пытаться задокументировать каждую деталь реализации под солнцем, поскольку вы достигнете точки убывающей отдачи. Стремитесь к 60-75 процентам охвата деталей реализации (задач) для каждой пользовательской истории, так как детали могут измениться, когда начинается кодирование. Любая дополнительная информация, которую разработчик обнаружит во время кодирования, может быть кратко раскрыта и задокументирована во время ежедневной проверки. Если пользовательская история может быть простой и нетехнической, в то время как отдел доставки / разработки выделит детали истории в виде вложенных задач. Эти задачи должны быть видны разработчикам через интегрированную среду разработки (IDE). Когда разработчики выполняют задачи, они могут связать свой проверенный код с задачей в инструменте отслеживания рабочих элементов (Jira, Team Foundation Server, On-Time)