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

9

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

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

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

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

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

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

matthewrk
источник
1
Разделение работы на задачи, которые занимают максимум 1-2 дня, безусловно, хорошая идея, и многие люди сказали бы, что это важно. Тем не менее, задачи! = Пользовательские истории . Задачи - это отдельные кусочки разработки, которые вам необходимо выполнить для реализации пользовательских историй, и одна пользовательская история может включать в себя множество задач.
vaughandroid
1
@Baqueta Но это история, которая имеет оценку в баллах? и эти точки отслеживаются как командная скорость, по крайней мере, так настроено в Pivotal Tracker.
Matthewrk
Пользовательская история завершается, когда все задачи, необходимые для ее выполнения, выполнены. Если вы в конечном итоге разделите историю на несколько спринтов, это может немного снизить скорость для этих конкретных спринтов, но она вырисовывается в стирке, и ваше среднее значение все равно должно быть полезным.
vaughandroid

Ответы:

7

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

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

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

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

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

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

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

Роберт Харви
источник
Можете ли вы привести примеры разбивки на основе моей истории? Причина, по которой я изо всех сил пытаюсь сломать его, состоит в том, что тегирование - это очень простая история на поверхности, и это единственная часть, к которой пользователь прикасается.
Matthewrk
7

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

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

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

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

Дэйв Хиллиер
источник
Я не видел твою правку. Ваша оригинальная версия в основном говорила «не делай этого», что, как мне казалось, не добавило никакой ценности. Предположительно, «полиморфная система мечения» является частью требований. Я отредактировал, чтобы уменьшить акцент на «чрезмерной инженерии» вашего ответа, и изменил мое отрицательное голосование на повышающее.
Роберт Харви
Я до сих пор в стороне, "не делай этого" :). Скрам - это особая методология, которую ОП будет использовать против принципов Скрама.
Дейв Хиллиер,
Спасибо за ссылку по планированию покера, я использовал систему, подобную той, что раньше, не зная, что существует формальная процедура. Причина, по которой я указал полиморфную систему тегов, заключается в том, что я с самого начала знаю, что нам нужно будет маркировать и другие модели, поэтому в таком случае это следует учитывать с самого начала? Работа в течение 1-2 дней на одну историю - это просто то, что я выбрал в качестве «хорошей идеи», когда изучал разборки, работа над точками усилий или сложностями в одиночку казалась немного открытой для интерпретации, тогда как оценка дней работы кажется довольно точной ,
Matthewrk
2
@matthewrk Вот что YAGNIоколо: даже не пытайтесь сделать полную полиморфный систему мечения еще . Сделайте простой для одного конкретного случая использования. Если владелец продукта возвращается с другой историей о маркировке других вещей, то вы расширяете простую существующую систему в полиморфную систему тегирования. То, что вы думаете, что это будет необходимо, не означает наверняка, что это будет необходимо; может оказаться, что пометить другие модели на некоторое время не понадобится, тогда все об этом забудут и это никогда не станет требованием. Следовательно, «Вам это не нужно».
Изката
7

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

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

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

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

задача

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

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

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

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

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

эпический

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

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

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

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

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

Пит
источник
1
Спасибо, это определенно очищает часть рабочего процесса для меня. Когда разработчики делят историю на задачи, создают ли они больше историй для отслеживания этих задач? или добавить задачи в историю? Попытка решить, как применить это в Pivotal Tracker.
Matthewrk
Разработчики не создают новые истории. Истории управляются «Владельцем продукта». Можно сказать, что они добавляют задачи в историю, но я думаю, что эта фраза немного вводит в заблуждение. Я добавил к ответу несколько слов о Pivotal Tracker.
Пит
4

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

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

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

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

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

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

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

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

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

Ник
источник
Когда вы упоминаете тесты, это с точки зрения пользователей? т.е. интеграционные / сквозные тесты? Учитывая ваши примеры в качестве разработчика, могу ли я взять все эти истории, реализовать нужную мне структуру (полиморфные теги), а затем завершить все истории сразу, когда id выполнил требование на стороне пользователя? но тогда где отслеживаются общие технические требования?
Matthewrk
В данном случае я имею в виду тестируемый пользователем, так что актер, упомянутый в пользовательской истории, может проверить, что вы реализовали то, что они хотят.
Ник
Говоря о требованиях, важно иметь одну валюту в проекте. Все, кто говорит о прогрессе с точки зрения пользовательских историй, значительно упрощают общение и отчетность. Я бы порекомендовал вам согласовать набор пользовательских историй с вашим клиентом и работать над ними в согласованном порядке (в первую очередь для бизнеса, за исключением тех случаев, когда существуют технические зависимости), а не просто реализовывать свое видение. Если вы считаете, что дополнительные функции в вашем видении системы полиморфных тегов полезны, то поднимите их как пользовательские истории и договоритесь с вашим клиентом, когда их делать.
Ник
2

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

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

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

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

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

Malte
источник