Разрешены ли «технические истории пользователей» в Scrum?

Разрешены ли технические истории пользователей в Scrum? Если да, то каков стандартный шаблон для написания технических пользовательских историй в Scrum? Это то же самое As a <user> I want to do <task> so that I can <goal>?

Я читал в некоторых блогах, что « разработчик не для пользователя» , но я также читал, что Scrum не обязывает их. Есть несколько блогов, где они делятся пользовательскими историями с системой как пользователь , это как as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Так какой же стандарт?

Например, есть пользовательские истории, такие как:

Как рецензент, я хочу загружать фотографии любого отеля / еды, чтобы другие пользователи могли видеть и любить их

Как пользователь, я хочу добавить фото комментарии, чтобы я мог лучше объяснить мой взгляд

Теперь для обеих этих пользовательских историй есть большой технический пункт - сохранение и получение изображения.

Итак, могу ли я добавить техническую историю под названием «Механизм хранения и получения изображений» со следующим описанием?

Как разработчик, я хочу разработать механизм для хранения и извлечения изображений, чтобы пользователи могли добавлять / просматривать изображения там, где это необходимо

Технические истории разрешены, но я бы посоветовал вам стараться избегать их как можно чаще.

Например, ваш рассказ о сохранении и извлечении изображений можно легко записать в виде двух обычных пользовательских историй.

1. Как рецензент, я хочу, чтобы мои загруженные фотографии сохранялись постоянно, чтобы другие пользователи могли просматривать их в любое время.
   (Обратите внимание, что это предполагает, что в исходной истории загрузки изображение не будет постоянно сохраняться после загрузки. Хотя это может показаться странным, это правильный способ разделения историй, чтобы сделать их управляемыми.)
2. Как пользователь, я хочу просматривать загруженные изображения в удобный для меня момент.
   (Это означает, что сохраненные изображения могут быть получены позже.)

Технические истории должны быть зарезервированы для работы, которая важна для организации, но не видна непосредственно как функция / функциональность для пользователей. Например, добавление балансировки нагрузки для обработки большего количества запросов.

Вопрос, приведенный в вашем конкретном примере, заключается в том, почему разработчик хочет разработать механизм для хранения и извлечения изображений, чтобы пользователи могли добавлять / просматривать изображения в любом месте, если пользователь не хочет добавлять или просматривать изображения?

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

Техническая история больше «Как разработчик, я хочу уменьшить дублирование в модулях архивации данных, чтобы мне не приходилось вносить все изменения в 6 местах».

Вопрос о том, должны ли они быть включены в спринт, является сложным, и это зависит от того, кого вы считаете своим клиентом. Это конечный пользователь, или бизнес, который вас нанимает, или бизнес, который нанимает вас на работу?

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

У меня больше опыта работы с внутренними командами, предоставляющими программное обеспечение непосредственно компании, которая платит мне зарплату. Во многих из этих компаний существует барьер доверия между бизнесом и техническим крылом бизнеса. Во всех из них есть другой менталитет, где снижение затрат точно так же, как увеличение дохода.

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

В конце концов, я предлагаю вам попробовать. И, если это не предлагает ценность, прекратите делать это.

Но мой инстинкт говорит, что если бы вы рассматривали ценность этой разработки для бизнеса, вы бы даже не попытались сделать ее историей для разработчиков. Это либо хорошо для конечного пользователя, либо нет. Если это не так, то для бизнеса нет никакой ценности.

Это хороший вопрос. У меня нет официального ответа, но там, где я работаю, мы добавляем технические истории пользователей и называем их техническими долгами. Если бы им не разрешили, я бы нашел какой-то другой способ добавить их только для того, чтобы записать мою работу и сообщить о ней бизнесу. Кроме того, наличие этой документации напоминает нам о том, что необходимо для будущих проектов.

Например, отключение в новом приложении, если нам не разрешено добавлять технические истории, заключается в том, что я буду гудеть в течение недели после начала спринта, создавая модели баз данных и ожидая, пока мой разработчик моделей данных утвердит итерируйте их вместе с разработчиком моделей и, когда закончите, отправьте сценарии в dba и подождите, пока они создадут объекты db. Тем временем я создам новый проект кода, некоторые базовые функциональные возможности ORM и мою схему управления исходным кодом, и когда все будет сказано и сделано, у меня будет время, чтобы создать одну пустую целевую страницу и развернуть ее.

Изо дня в день, пока это происходит, если я не записываю информацию, дело в том, что наша команда не работает над проектом, хотя на самом деле мы. Наличие этих элементов в историях означает, что мы можем проверить нашу работу, задокументировать работу и сообщить бизнесу, что мы делаем успехи.

Если есть лучшая лучшая практика для этого, я весь в ушах.

Мое личное мнение состоит в том, что команды не должны слишком зацикливаться на том, что позволяет схватка, и больше беспокоиться о том, что работает для команды. Одной из причин того, что схватки получили плохую репутацию, является то, что практики могут стать сфокусированными на процессах, что противоречит идеям гибкого управления проектами.

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

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

Причина, по которой это важно, заключается в том, что технический результат (сам по себе) не является чем-то, что производит ценность с точки зрения пользователя. Если вы начнете отслеживать технические результаты как пользовательские истории, вы можете легко попасть в ловушку, рассматривая техническую продукцию как создающую ценность для бизнеса. Грязь таким образом смешивает работу, которая поддерживает бизнес-цели (то есть вещи, которые стоят денег) с реальными бизнес-целями (то есть вещи, которые приносят деньги).

Все приведенные выше ответы не содержат ссылки на официальный исходный документ для платформы Scrum: Руководство по Scrum .

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

Акцент должен быть сделан на создании ценности. Иногда эта ценность исходит от технической работы, такой как модернизация инфраструктуры. Не исключайте эти предметы!

Термин « пользовательская история» никогда не появляется в The Scrum Guide, потому что

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

Использование пользовательской истории - это только один из возможных способов записи PBI. Хотя обычно встречается формат «Как, я хочу, так», это может противоречить его первоначальному замыслу . Этот проблемный формат также был рассмотрен на Agile 2017 .

Понимание и использование вертикальной нарезки поможет уменьшить размер элементов незавершенного производства (PBI). Рассмотрим нарезку , что одного сохранения и извлечения элемента в экономии и получить элемент s .