Отслеживание времени в Scrum

Ответ 1

Вы отслеживаете время в Scrum как функцию часов/дней, потраченных на задание, или просто завершена ли эта задача или нет?

Я отслеживаю ожидаемую работу. Это должна быть информация. Без этого вы не можете нарисовать диаграмму Burndown. Без диаграммы Burndown вы не знаете, где вы находитесь, вы не знаете, находится ли ваш Sprint на ходу или нет. Это сделало бы этот инструмент решения практически бесполезным. Да, диаграмма Burndown не является инструментом отслеживания, это инструмент решения.

Можете ли вы настроить эти задачи и оценки?

Конечно!

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

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

Итак, во время Sprint члены команды должны, очевидно, обновлять оценки оставшейся работы, как только они могут это сделать (вверх или вниз). Если оценка задачи была первоначально 6h, но команда обнаружила, что нужно выполнить большую работу и что задача займет 8 часов, команда должна обновить "Спринт-отставание" соответственно. Если кто-то потратил 4 часа на задание, которое первоначально было оценено в 4 часа, но все еще нужно 2 часа работы, эти 2h следует сообщить в журнале Sprint Backlog. Если команда обнаруживает задачу, которая должна быть выполнена, но это не было определено, команда должна добавить эту задачу и ее оценку в Sprint Backlog. И быть неточным в начале - это не проблема, если вы обновляете отставание со знаниями, собранными с течением времени. Чем скорее вы сделаете эти обновления, тем скорее вы сможете адаптироваться и принять решения.

Тем не менее, может быть полезно сохранить "начальную оценку" и сравнить ее с "фактическим временем, затраченным на завершение". Но не для целей отслеживания, а только для того, чтобы помочь команде сделать более точные оценки. На самом деле, я бы советовал не делать этого, если вы переходите на Scrum. Часто бывает много других препятствий для решения, многие другие вещи, которые нужно улучшить, когда вы изучаете ценности и принципы Scrum. И если вы это сделаете, остерегайтесь демонов Водопада. Будьте готовы сражаться с ними, они могут вернуться очень быстро.

Ответ 2

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

Я думаю, вы спрашиваете: "Должен ли я отслеживать общее количество часов, потраченных на определенную задачу?" Ответ: "Вы можете, если вам нужно, но это не часть Scrum".

Scrum - очень легкий процесс. Он определяет/требует только того, что необходимо для работы Scrum. Вы можете (и, во многих случаях, вероятно, должны) накладывать другие процессы поверх Scrum, чтобы удовлетворить ваши организационные потребности. Например, если отслеживать общее количество часов, потраченных на задание, позволяет лучше оценить похожие задачи в будущем (как вам кажется, ваш VP хочет), то это может быть хорошей причиной для отслеживания общих часов, при условии, что это не слишком много мешают продуктивной работе. Или, возможно, вам нужно знать общее количество часов для выставления счетов. Так что только потому, что Scrum не требует чего-то, это не значит, что вы не должны этого делать.

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

Ответ 3

Я не знаю, правильна ли наша реализация, но что мы делаем:

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

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

Ответ 4

Мне нужно добавить что-то здесь, потому что

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

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

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

Я попросил бы VP, что эти "очень осторожные" оценки будут выполнены.

Ответ 5

Оцените время, но на самом деле все равно, если оно отображается на

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

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

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

Ответ 6

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

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

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

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

Ответ 7

Что касается отслеживания времени, то вы ищете график сгоревшего экрана.

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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