Я усердно работаю над пользовательскими историями, и это окупается, но что-то чешется.
Мы используем Jira, но проблема в том, что сверху бэклог кажется корявым.
Нам нужно написать сводку для пользовательской истории, чтобы Jira могла ее отобразить, но эти сводки иногда немного вводят в заблуждение или не помогают найти какую-то конкретную историю.
Мы не используем скрам, мы просто используем бэклог и модифицированную канбан-доску, чтобы визуализировать наш прогресс.
Я хотел бы, чтобы в бэклоге (и на доске) истории отображались в (удобочитаемой) последовательной структуре, чтобы мне было легче ориентироваться.
В данный момент, чтобы решить эту проблему, я вижу, что я либо:
Я не знаю, как быть с пунктом 2.
Некоторые идеи для пункта 1:
Больше я думаю об этом, я думаю, что у пользовательской истории нет резюме (?). Они произошли от учетных карточек (?) и представляют собой небольшую часть требования.
Они кажутся настолько краткими, насколько это возможно.
Некоторые примеры историй (пожалуйста, будьте осторожны, если в них есть недостатки) в контексте торгового автомата или платежной станции, которые предлагают возможность оплаты картой.
Как клиент,
я хочу, чтобы мне напоминали, что моя карта находится в карточном терминале после того, как я отменил платеж по карте,
чтобы я не забыл ее на кассе.Как покупатель,
я хочу, чтобы мне напоминали, что моя карта находится в карточном терминале после того, как я оплатил картой,
чтобы я не забыл ее на кассе.Как клиент,
я хочу знать, успешно ли я отменил платеж по карте с карточного терминала,
чтобы не запутаться, оплатил я или нет.
Вместо этого используйте рассказы о работе .
Все ваши пользовательские истории начинаются с «Как клиент», так что вы тратите эту строчку впустую. Мы знаем, что они клиенты. Это данность.
Вместо этого рассказы о работе идут:
Когда... Я хочу... Значит, я могу...
Так - например -
Когда я отменяю платеж по карте, я хочу, чтобы мне напоминали, что моя карта находится в карточном терминале, чтобы я ее не забыл.
(А затем вы можете добавить последнюю строку — «Эта потребность будет удовлетворена, когда...», чтобы вы точно знали, что вам нужно делать. Если хотите.)
Мне будет очень трудно найти канонический ответ на этот вопрос, и, учитывая, что проблема, с которой вы столкнулись, может быть разделена другими членами сообщества, я поделюсь некоторыми мыслями.
Ваша основная проблема заключается в том, как команда визуализирует отставание. Каким бы подробным ни было резюме, это всего лишь... краткое изложение. Не стоит ожидать, что вы все поймете из резюме.
Старайтесь рассматривать сводки как «указатели». Ваша команда должна провести сеанс для просмотра основных элементов невыполненной работы (чтобы узнать фактическое «содержимое»). В следующий раз, когда люди будут смотреть на невыполненную работу, читая сводку, они должны иметь представление о том, о чем каждый элемент. Чтение об уточнении невыполненной работы может вам помочь.
Теперь, принимая во внимание ваши конкретные примеры Story и использование Jira. Если вы используете доску Scrum вместо доски Kanban, вы можете сгруппировать истории, описанные выше, под эпиком под названием «оплата картой»… а затем, в журнале Scrum, вы можете щелкнуть этот эпик в фильтре эпиков слева. сторона отставания. Вы можете увидеть пример в ЭТОМ ответе.
Вы можете применить ту же логику к другим эпикам, таким как «оплата наличными», или даже оставить конкретный эпик для «платежей». Суть в том, что бэклог должен быть простым для чтения и навигации.
Кроме того, крайне важно помнить, что «пользовательская история» — это не исходный код! Пользовательская история — это просто формулировка требования в человеческом смысле. Если вы «обобщаете» это, вы подвергаетесь двум прагматическим рискам:
Вы изменяете его, сознательно или бессознательно переписывая его с точки зрения дизайна или реализации развивающейся программной системы.
Вы навязываете одно значение — свое — чему-то, что с «точки зрения пользователя» могло означать что-то другое.
Ваша цель состоит в том, чтобы использовать эти истории в процессе формулирования дизайна и реализации, чтобы затем вы могли сравнить этот дизайн с ними, чтобы увидеть, как требование, изложенное в этой «истории», должно быть выполнено как системой, так и гипотетический пользователь, который «рассказал историю», когда пытался использовать систему. Если вы суммируете (переписываете) их, вы очень быстро теряете заложенную в них ценность.
Да, верно, если вы действительно используете концепцию пользовательских историй, резюме не будет. Просто формат "Как, хочу, так и так".
Если вы хотите или можете написать более подробное резюме, то вы выполняете или уже выполнили аналитическую работу, которую команда должна выполнить позже. Это пуристский подход, я думаю. Это даже хорошо известная практика — добавлять критерии приемлемости к истории, возможно, в формате корнишонов, поэтому трудно утверждать, что всегда плохо добавлять что-то большее, чем заголовок. Конечно, критерии приемлемости часто добавляются позже, при доработке.
Я думаю, как только вы добавляете много текста, диаграмм или скриншотов, это начинает отдаляться от сути пользовательской истории. Это не всегда может быть плохо, не все гибкие требования должны быть пользовательскими историями. Однако то, как во многих местах используется термин «История пользователя» с прикрепленными целыми многостраничными текстовыми файлами, на самом деле не является тем, что мы должны рассматривать как «Историю пользователя».
С практической точки зрения, в Jira вы можете хранить критерии приемлемости в поле сводки.
Барнаби Голден
Тодд А. Джейкобс