Разбиение сложной истории в начале проекта

Я пытаюсь справиться с гибким управлением проектами (с Pivotal Tracker), но продолжаю сталкиваться с трудностями, пытаясь определить первые несколько историй проекта. Возьмем, к примеру, эту очень простую историю:

«Пользователь должен иметь возможность пометить товар»

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

Моя проблема с количеством работы, скрытой в этой истории. Я могу определить задачи, чтобы сделать историю, но истории в целом должны работать 1-2 дня? Я не чувствую себя правдиво по поводу истории, раскрывающей только верхушку айсберга, но это единственная часть, которая относится к Пользователю.

Как вы преодолеваете такие вещи? Каковы лучшие практики?

ОБНОВЛЕНИЕ 25/08 Спасибо всем за ваше руководство, я принял все советы о том, как определять истории. Сейчас я переключаюсь на Jira Grasshopper, который лучше поддерживает задачи в историях (задания, оценки и т. Д.) И отслеживает задачи разработки после начала спринта.

Если вы хотите, чтобы ваши истории занимали от 1 до 2 дней работы разработчиков, возможно, вам следует разбить каждую историю на конкретные пользовательские задачи, которые составляют от 1 до 2 дней работы разработчика.

Рассмотрим следующую «историю пользователя»:

Пользователь должен иметь возможность получить счет от купленного товара.

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

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

• Пользователь кладет товар в корзину
• Пользователь указывает количество
• Пользователь указывает тип доставки

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

Рассказы не должны быть «1-2 дня работы». Под Scrum истории обычно оцениваются с использованием Story Points, относительной системы определения размеров. Если вы используете планирование покерных историй, им присваивается количество очков - время, которое занимает история, зависит от скорости, которую установила ваша команда.

Если вы чувствуете, что история скрывает сложность (вы можете назвать это эпической историей), вам следует разбить ее на более мелкие истории. Убедитесь, что новые истории соответствуют критериям ИНВЕСТ .

Но вы можете переусердствовать в этом; принцип XP YAGNI применяется здесь. Чтобы быть явным, вы не должны реализовывать «полиморфную систему тегов под капотом», если вам это действительно не нужно. Даже тогда она должна быть разработана путем улучшения существующей системы, которую вы разработали с помощью хорошего набора тестов.

Если вы уверены, что вам нужна эта сложная система тегов, вы должны назвать сложность в отдельных историях. Майк Кон описывает подход к дизайну как « преднамеренный, но возникающий »

Кажется, вы путаете истории и задачи.

История пользователя

Пользовательская история - это полная «функция», которая при добавлении к продукту повышает его ценность.

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

задача

На второй части этапа планирования спринта разработчики делят историю на задачи . Задачи являются задачами развития. Это могут быть такие вещи, как «Добавить столбец в базу данных», «Расширить службу x» и т. Д. Задача не должна быть больше, чем она может быть выполнена за один день.

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

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

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

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

эпический

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

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

Разделить эпос на пользовательские истории, управляемые в течение времени спринта, не всегда легко, если у вас нет опыта в этом.

Использование Pivotal Tracker

Я считаю, что Pivotal Tracker - отличный инструмент для отслеживания пользовательских историй. Но это не инструмент Scrum как таковой, и способ, которым Scrum учит разделять истории на задачи, не легко обрабатывается центральным трекером. Вы можете включить возможность добавлять задачи в пользовательские истории. Но если вы запускаете проект с использованием scrum, я бы предложил использовать белую доску и заметки, чтобы отслеживать ход выполнения задач во время спринта.

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

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

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

... и я мог бы продолжить.

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

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

Взяв еще более художественную лицензию, я мог бы разделить: «Как пользователь системы, я хочу иметь возможность прикрепить один тег к одному продукту». на следующие вертикальные ломтики:

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

Каждый из них может быть проверен, если не особенно ценен сам по себе.

Есть книги, написанные с единственной целью найти правильный способ описать и разбить ваши требования. Так что это не простая задача.

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

Как владелец продукта, вы можете влиять на это, разбивая истории на более мелкие кусочки. Вы должны спросить себя: является ли история наименьшим решением, которое мы можем придумать прямо сейчас? Можем ли мы разбить его на сокращенные наборы функций, которые когда-нибудь станут «большой гибкой системой тегирования, которую я всегда хотел». Вы можете начать с системы тегов только для одного тега, затем расширить ее, включив в нее список предварительно выбранных тегов, и затем позволить пользователю определять теги и т. Д.

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

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