Как написать Истории пользователей для деталей технической реализации?

Question

Я пытаюсь работать более организованным образом и начал принимать пользовательские истории.

Я думаю, что у меня непонимание того, как использовать пользовательские истории для технических материалов.

Предположим, что я кодирую приложение, которое дает мне рейтинг моего сайта для определенного ключевого слова в Google.

История пользователя выходит так:

Как интернет-маркетинг
Я хочу узнать, где мой сайт занимает по ключевому слову
Так что я знаю, работает ли мои усилия SEO

Теперь это довольно прямолинейно и ориентировано на пользователя ... Однако, что произойдет, если мне нужно ввести Proxies в цикл.

С одной стороны, Proxies - это детали технической реализации, с другой стороны, прокси-сервер является частью домена интернет-маркетолога.

Как мне создать такую ​​историю?

Как интернет-маркетингу
Я хочу использовать прокси при поиске в Google
Таким образом, мы будем иметь возможность проверить много ключевых слов без Google блокирует нас

выше сценарий Безразлично» т звук для меня ... может быть, я могу переписать его, чтобы быть что-то вроде:

Как интернет-маркетингу
Я хочу, чтобы иметь возможность проверить много ключевых слов в то время
Так что спасу мне время

Это звучит более верно, однако, что принятие критериев я могу дать? попробуйте очистить Google 100 раз в минуту? Разве это не трата времени?

Вот еще один сценарий. Как мне создать историю пользователей, когда функция, которую я хочу реализовать, заключается в том, что прокси можно использовать один раз в 30 секунд? Я не знаю, как подойти к этой проблеме с точки зрения пользователя ...

Еще одна вещь, которую я думал сделать, - это представить еще Role. Вместо того, чтобы сосредоточиться вокруг Internet Marketer, я могу сказать, что у нас есть функция под названием Google Scraper. Могу сказать, что Internet Marketer относится к Google Scraper.

Теперь я могу написать рассказ пользователя как:

Как Google Скребок
Я хочу изменить прокси каждый Поиск
Так Google не запретить мне

Что бы вы сказали, о приближающихся деталях технической реализации, как указано выше?Это также может помочь разбить систему на модули ...

Answer 1

Вы не пишите технические рассказы. Истории пользователей должны соответствовать INVEST criteria.

Прокси-серверы звучат как детали реализации, их следует избегать. Вы не должны упоминать прокси-серверы в своей истории. Даже если они являются частью домена, есть потенциально другие способы достижения такого же эффекта.

Вместо того, чтобы писать «Я хочу использовать прокси, чтобы я не блокировался», вы должны написать: «Я хочу скрыть свою личность, чтобы я не блокировался». Если бы я был вашим клиентом, я бы не знал, почему вам нужен прокси-сервер? Является ли это прямым, открытым или обратным прокси-сервером? Есть грузы uses for a proxy server. Вы должны выбрать функцию, которую хотите использовать.

Однако вы не должны слишком зависеть от прекрасных историй. Проворный манифест гласит: «Лица и взаимодействие над процессами и инструментами».

При написании истории пользователя вы также должны рассмотреть 3 C: Card, Conversation, Confirmation. Как клиент, так и вы понимаете смысл этой истории?

Соответствует ли карточка критериям ИНВЕСТ? Если вы ответили «да» на оба этих вопроса, история будет прекрасной.

Answer 2

Истории пользователей не должны содержать технических деталей. Во время Sprint Planing технические детали должны быть добавлены как задачи Delivery Team, вложенные ниже пользовательской истории. Эти задачи должны быть созданы путем обсуждения группой доставки. Вы не должны пытаться документировать каждую деталь реализации под солнцем, так как вы достигнете точки уменьшения прибыли. Цель 60-75% охвата деталей реализации (задач) для каждой истории пользователя, поскольку детали могут измениться по мере начала кодирования. Любые дополнительные сведения, которые разработчик обнаруживает во время кодирования, могут быть разделены и задокументированы во время повседневной работы. если «Пользовательская история» может быть простой и нетехнической, в то время как команда «Доставка/разработка» будет отображать детали рассказа в виде вложенных задач. Эти задачи должны быть видны разработчикам через их интегрированную среду разработки (IDE). По мере того как разработчики выполняют задачи, они могут связать свой проверенный код с задачей в инструменте отслеживания рабочих элементов (Jira, Team Foundation Server, On-Time)