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

Проблема в том, как подойти к сгоранию? Если я соберу часы вместе, предположим следующую оценку:

10 часов - время разработки

4 часа - QA

4 часа - обзор кода.

Оценка задания = 18 часов

В конце каждого дня я прошу обновить задание на «сколько времени осталось до его выполнения». Тем не менее, каждый человек, как правило, просто думает о своей части этого. Должны ли они отметить оставшееся усилие, а затем ДОБАВИТЬ оценки усилия к этому? Как вы, ребята, делаете это?

ОБНОВИТЬ

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

1. Кто-то, чтобы разработать задачу. (делать юнит-тесты, т. д.)
2. Специалист по обеспечению качества для проверки задачи (в основном они проводят интеграционные и регрессионные тесты)
3. Технический лидер, чтобы сделать обзор кода.

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

Мой вопрос к тем, кто работает таким образом, будет о том, как записать «задачу», когда они настроены таким образом. Если у Задачи нет своих собственных подзадач (которые JIRA не позволяет) ... Я не уверен, что это лучший способ ежедневно отслеживать "что осталось".

Это 3 задачи, а не одна.

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

TL; DR

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

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

Задачи против историй

Вы объединяете задачи и истории. Истории включают все задачи, необходимые для завершения истории в соответствии с «определением выполненного» вашей команды. История считается на 100% неполной, если все ее задачи не выполнены. В Scrum истории всегда оцениваются каким-то образом; чаще всего они оцениваются в сюжетных баллах.

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

Сгореть

В Scrum ваша диаграмма выгорания показывает объем работы, оставшейся для спринта или проекта. Реальные диаграммы выгорания часто имеют плато; в некоторых случаях график может даже подняться. Например, при однонедельном спринте с двумя историями по 3 и 5 баллов ваши данные могут выглядеть примерно так:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

В этом идеалистическом сценарии вы начинаете с 8 сюжетных очков. История с 3 пунктами была закончена во вторник днем, в то время как история с 5 пунктами не была закончена до пятницы. Очки истории не вычитаются из выгорания до тех пор, пока история не соответствует определению «сделано». Если вы используете идеальные часы вместо баллов, единственное, что изменится, - это ваш масштаб.

Время-бокс

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

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

Можете ли вы определить задачу разработчика как "выполненную", прежде чем QA выполнит свою роль? Можете ли вы определить рецензирование кода как «выполнено» до того, как завершится разработка? Может ли QA быть «выполнено», если нет разработки и проверки кода?

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

Scrum НЕ говорит, что ответственность за любой предмет лежит на командире. Напротив, элементы журнала спринта являются обязанностью КОМАНДЫ. Если для выполнения задачи требуется три человека, то это то, что нужно.

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

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

После первоначальной оценки она неофициально завершается для нашей команды более, чем на часы. Если мы изначально думали, что это займет два дня, но после одного дня, мы думаем, что оно выполнено только на 25%, мы берем 4 из первоначальных 16 часов. Это оставляет 12 часов, а технически мы оцениваем 24, потому что мы, вероятно, вычтем 4 часа за оставшиеся 3 дня.

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

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

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

Это говорит:

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

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

Исходное задание: исправить что-то

Новые задачи: (потомок родителя исходного задания)

• Dev A - Исправление проблемы
• Dev B - Помощь Dev A в решении проблемы (например, парное программирование, проверка кода)
• Dev A - тестирование исправления с помощью Dataset X
• Dev B - тестирование исправления с помощью набора данных Y