История оценивает в [закрытой] Толпе
Хорошо иметь Ваш сайт быть доступным пользователями с отключенным JavaScript, в этом случае href указывает на страницу, которая выполняет то же действие как выполняемый JavaScript. Иначе я использую" #" с" return false;" для предотвращения действия по умолчанию (прокрутите к верхней части страницы) как другие упомянули.
Гугление для" javascript:void(0)" предоставляет большую информацию об этой теме. Некоторые из них, как этот причины упоминания для НЕ используют пусто (0) .
3 ответа
Вы абсолютно можете снова оценить свои истории, и должны. Очки фиксируются только тогда, когда команда берет на себя обязательства по ним на Сессии планирования спринта непосредственно перед началом спринта.
Одна практика, которую я использовал, заключается в том, что при индивидуальном планировании спринта вы должны заново оценить каждую историю. Со временем команда учится и станет более точной с помощью оценок и выявления зависимостей. Помните, что входит в спринт, зависит от команды, а владелец продукта определяет общее отставание. Если проект ограничен по времени, не пытайтесь привести оценки в соответствие с датой окончания, в противном случае вы настраиваете себя на провал.
Помните, что с Velocity вы начинаете с предположения о том, чего вы можете достичь. Обычно это не так t до 3-го или 4-го спринта, в котором вы участвуете, определите реалистичную скорость, которой может управлять команда. Да, это означает, что вы могли предположить, что команда может набрать 20 очков за спринт, а на самом деле может набрать только 15 очков. Да, это означает, что срок поставки истекает или истории падают ниже границы разреза.
Что касается зависимых историй, вам следует работать с владельцем продукта. Если команда разговаривает с ними, вы обычно можете переставлять истории. Большинство людей восприимчивы к тому, кто говорит им: «Если мы сделаем А сейчас, это займет полный спринт, но если мы сделаем А позже, это займет 15% спринта», что делает его довольно убедительным.
Полезная практика для try - это планирование историй в рамках Sprint. Во время сеанса планирования, когда все истории проверены и обсуждены, команда открывает календарь и обсуждает, когда они хотят что-то сделать. Помещение плановых дат в календарь помогает выявить совпадения и зависимости между историями. Это может идентифицировать вещи, которые являются последовательными по своей природе и могут привести к сбою спринта.
Надеюсь, эта информация будет полезной.
Судя по вашему объяснению, вы уже отлично справляетесь. Конечно, всегда будут истории с зависимостью. Некоторые могут даже не иметь непосредственно видимой ценности для потребителей; то есть начальные усилия по настройке архитектуры и некоторых фреймворков). Но если вы их оставите, вы создадите большой технический долг. Если можете, я бы посоветовал вам попытаться завершить уравнение и каким-то образом показать связь между задачами.
Например: - Задача 3 составляет 8 баллов, если выполняется после задачи 2, и 12 баллов, если выполняется независимо.
Таким образом, владелец продукта почувствует боль игнорирования зависимостей, но все же сможет сделать выбор в пользу того, чтобы сначала сделать наиболее ценные истории. Если product owner уверен, что все истории пройдут в следующих спринтах, вы можете направить их на реализацию в наиболее эффективном порядке. Например, заблокировав элементы, для которых не были выполнены зависимости (т. Е. Функция «изменить мой логотип на веб-сайте» может быть доступна только после завершения истории «Версия с веб-поддержкой»).
Удачи!
Я могу только описать свой опыт.
Когда мы планировали первый спринт, мы решили, что сможем набрать 18 очков. Итак, мы взяли несколько историй, и общая оценка составила 15 баллов. Как я упоминал выше, мы делали свои первые шаги в схватке, и поэтому мы решили, что 3 неиспользованных точки и форм-фактор 0,6 гарантируют наш успех.
Но наши оценки каждой истории были только приблизительными. У нас были и зависимые истории. И мы не составляли план реализации каждой истории, потому что считали это небезопасным для гибкой методологии.
В результате мы провалили наш первый спринт, набрав всего 8.
Перед нашим вторым спринтом я решил, что мы должны взять что-то из старых добрых простых каскадных и итеративных методологий (а я был мастером схватки). Итак, при нашем планировании на следующую весну, чтобы сделать правильные оценки, мы спланировали каждую историю (около 20 минут на рассказ) с простыми диаграммами, всеми зависимостями, деталями реализации и так далее. Планирование было трудным, и потребовалось 2 встречи.
Но второй спринт был намного лучше, и мы сделали почти все (на самом деле мы сделали все, кроме некоторых ошибок). Думаю, в 3-м спринте мы возьмем меньший форм-фактор, и он будет успешным.