Время отслеживая в [закрытой] толпе

Оцените время, но не обращайте внимания на то, где оно находится на

. Просто убедитесь, что вы внимательны и тщательно оцениваете задачи. Обычно вы не измеряете время, потому что оно более подвержено ошибкам. Лучше всего использовать оценки времени выполнения задач в виде сюжетных очков . Таким образом вы получите:

1. Если ваши оценки времени неверны, исследования показывают, что они, как правило, постоянно неверны (коэффициент точности не меняется слишком сильно), поэтому оценки времени можно легко использовать для расчета сюжетных очков.
2. Если вам эмпирически удалось набрать x очков истории в предыдущем спринте, вы Вероятно, вы достигнете аналогичных результатов на этот раз, даже если ваши оценки времени неверны.
3. Вы должны уметь оценивать все сюжетные задачи. В противном случае ваши очки истории спринта имеют тенденцию расти во время выполнения, и вы не уложитесь в срок - даже если ваша скорость останется практически той же
4. Оценки могут измениться, но, как и в пункте 3, оставьте некоторое время спринта для этих изменений крайние сроки спринта (демонстрационный день).

Но сохраняйте оценки времени, чтобы на самом деле видеть, какие задачи должны быть разделены или объединены.

Что касается отслеживания времени, то вам нужна диаграмма выгорания .

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

Итак, на ваш вопрос о том, отслеживаем ли мы время , потраченное , не обязательно. Вместо этого Scrum любит работать с оставшимся временем . (Вы можете заменить часы на очки истории, принцип тот же, как объяснил Роберт.)

На ваш второй вопрос о том, можете ли вы скорректировать свои задачи и оценки, определенно да. Agile следует философии «реагировать на изменения»; вы расставляете приоритеты в том, что наиболее важно для клиента.

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

Утверждение: «Таким образом, после запуска проекта мы не можем добавлять новые задачи или корректировать почасовые оценки этих задач». почти наверняка не в духе Agile.

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

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

In Что касается спринта, то оставшиеся часы - это всего лишь мера прогресса, поэтому мы можем видеть, где мы сгораем. Они подсказывают, на правильном пути мы или нет. Значение имеет набранный балл.

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

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

In В процессе Scrum отдельные конечные результаты называются элементами невыполненной работы и могут рассматриваться как набор задач. Элементы невыполненной работы устанавливаются по приоритету Владельцем продукта, по оценке Команды, сначала в целом, а затем задача за задачей. Содержание, объем, приоритет и оценка элементов невыполненной работы могут быть пересмотрены.

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

Я должен кое-что добавить сюда, потому что

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

Это просто , а не схватка, поэтому я не Знайте, откуда ваш вице-президент взял информацию. Задачи (известные как элементы невыполненной работы спринта) не создаются до момента планирования следующего спринта. Они создаются как раз вовремя, и уж точно не до старта проекта. Перед запуском проекта (спринт 0) владелец продукта создает бэклог продукта и заполняет его историями. Он может добавить к нему в ЛЮБОЕ время во время проекта. Это его управление. Команда оценивает эти истории примерно по отношению друг к другу в баллах историй или в какой-либо другой относительной мере (идеальные дни?).

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

Я бы спросил вице-президента, что эти «очень осторожные» оценки собираются достичь.

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

Я бы спросил вице-президента, что эти «очень осторожные» оценки собираются выполнить.

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

Я бы спросил вице-президента, что эти «очень осторожные» оценки собираются выполнить.

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

Я бы спросил вице-президента, что эти «очень осторожные» оценки собираются выполнить.

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

Я бы спросил вице-президента, что эти «очень осторожные» оценки собираются выполнить.

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

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

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

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