Улучшение качества пользовательской истории [закрыто]

Question

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

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

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

Как лучше всего разорвать порочный круг незавершенных/недостаточных историй для наших спринтов?

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

Answer 1

Так ты говоришь, что:

1. Клиенты/пользователи общаются с командой проекта
2. Команда проекта пишет истории и создает каркасы
3. Команда разработчиков разбивает истории на задачи и оценки

Есть ли возможность у команды разработчиков на самом деле поговорить с клиентами/пользователями?Пользовательские истории иногда рассматриваются как способ начать разговор, а не как документация с требованиями/спецификациями.

РЕДАКТИРОВАТЬ:Некоторые ссылки:

• Пользовательская история для варианта использования — то же самое, что газель для беседки.
• Шесть особенностей хорошей пользовательской истории - Модель INVEST
• Клиент всегда доступен

РЕДАКТИРОВАТЬ:Мартин Фаулер вчера сделал сообщение в блоге на Разговорные истории это охватывает это гораздо лучше, чем я.

Answer 2

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

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

Предложение @Pascal посвятить 5% вашего спринта работе с невыполненной работой по продукту является хорошим.Это должно позволить пользовательским историям быть более подробными перед началом спринта.

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

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

Это вернет вас к хорошей ретроспективе и решение поднятые вопросы.

Как лучше всего разбить цикл неполных / недостаточных историй для наших спринтов?

Ретроспективы, планирование, работа с отставанием.

Это неудача команды проекта вплоть с самого начала, или мы (т.е.Команда разработчиков) взять на себя часть ответственности?

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

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

Answer 3

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

Вы можете начать с такой истории:

As an administrative user I can create a new widget.

Хорошо, что это значит?После некоторого анализа это может означать:

As an administrative user I can create a new widget in created status with complex data validation errors.

Итак, после этого список полей, их размер и какие поля необходимы для сохранения в базе данных.Базовый макет пользовательского интерфейса также был бы хорош.

Другая пользовательская история для следующего спринта может быть такой:

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

Затем список сложных правил проверки.

Answer 4

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

В начале спринта истории должны быть ГОТОВЫ.Если вам нужно их немного доработать, я думаю, вам (команде разработчиков, ScrumMaster, команде проекта) следует сделать это немного раньше, во время предыдущего спринта.

Как лучше всего разорвать порочный круг незавершенных/недостаточных историй для наших спринтов?

Возможно, вы недооцениваете истории, или они слишком объемны и расплывчаты.В обоих случаях это похоже на проблему оценки, и хороший способ улучшить ситуацию — уменьшить размер историй.Чтобы поработать над этой проблемой, вы можете посвятить некоторое время (например,5% каждого спринта) до Уход за бэклогом продукта для того, чтобы подготовить самые важные истории и уменьшить их размер, поместив их на диете если необходимо до следующий спринт.И это на самом деле сделает встречу по планированию спринта более гладкой.

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

ИМХО, ответственность не так уж важна (за исключением, возможно, политических причин, но они все равно не приносят большой пользы), и команда разработчиков, и команда проекта работают вместе и вместе «терпят неудачу».Здесь важно осмотреть и адаптироваться, чтобы устранить препятствие.Итак, команда разработчиков обязана сделать эту проблему видимой (это является препятствие).И ScrumMaster обязан работать над этим препятствием.Провалом было бы не работать над этим.Сессии по очистке бэклога — один из способов сделать это.И в конце концов, я уверен, что команда проекта улучшится и лучше поймет, чего ожидает команда разработчиков.И вы оба добьетесь лучших результатов.

Answer 5

Здесь уже есть много хороших идей по аспектам Scrum вашей проблемы.Судя по вашему комментарию:

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

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

Answer 6

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

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