Как “всплески” фигурируют в расписании / оценке игры?[закрыто]

Question

Может быть субъективным и / или дискуссионным..но вот что происходит.

Меня попросили оценить функцию для следующего масштабного проекта на работе.Я разбираю это на части..используйте сюжетные баллы, составьте оценку.Однако эта функция требует взаимодействия с GoDiagrams, сторонним компонентом построения диаграмм, в дополнение к различным другим инициативам компании..(целый набор фреймворков/сервисов 2008_Limited_Edition:).Я отслеживал себя с помощью графика выгорания и обнаружил, что не могу поддерживать свой темп в первую очередь из-за "всплесков".. Определение

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

Шипы нужны, чтобы вбивать гвозди в доски невежества.Но как они учитываются в уравнении оценки?Выполнение всех необходимых скачков до того, как функция покажется неправильной..(может оказаться, что это ЯГНИ) Выполнение этого в промежутках нарушает мой поток.Прямо сейчас это происходит во время предварительного итерационного планирования..но это отодвигает сенсорную линию на еженедельной основе.

Answer 1

Я предполагаю, что вы постоянно недооценивающий

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

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

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

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

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

Обновление (Gishu):Подводя итог

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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