Каким образом «всплески» фигурируют в игре «расписание / оценка»?

Я думаю ты постоянно недооценивать

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

1. Научитесь лучше оценивать эти две вещи.

Итак, все дело в опыте. Независимо от того, какую методологию вы используете, они помогут вам лучше использовать ваш опыт, а не заменить его.

2. Постарайтесь не сбиться с пути при работе с этими шипами.

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

Обновление (Гишу): Подведем итоги

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

@pointernil .. Это больше не оценка в сочетании с подходом Indy-Jones Head-First к решению истории. Я оцениваю истории по их содержанию ... в настоящее время я не принимаю во внимание время, необходимое для того, чтобы найти правильное заклинание, чтобы библиотека управления играла хорошо. Иногда это занимает больше времени, чем логика моего приложения .. Итак, перефразируя исходный вопрос, должны ли пики быть отдельными задачами в плане итераций, добавленными на основе JIT, прежде чем вы начнете работать над определенной историей?

Мои Спайки чрезвычайно сфокусированы ... Я просто не могу дождаться, чтобы вернуться к "настоящим" проблемам. например 'Как мне показать контекстное меню из этого элемента управления?' Я могу быть виноватым в том, что не прочитал все 150+ страниц руководства или образцы кода ... но тогда времени мало. Первое решение, которое решает проблему, получает одобрение, и я двигаюсь дальше. Но когда вы не можете найти это неуловимое событие или шаблон уведомления NIH, используемый компонентом, всплески могут занять много времени. Как установить временные рамки для неизвестного? например Мой временной интервал истек, и я до сих пор не знаю, как подключить свое настраиваемое контекстное меню. Как мне продолжить? Продолжайте взламывать?

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

Я согласен с пуантернилом. Проблема только в том, что ваши оценки неверны. Это не большая драма, если, конечно, вы только что не провалили проект на 3 миллиона долларов :-)

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

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

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

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