Итерация уже началась, новый программист присоединяется к команде, задача X уже оценена другим разработчиком в течение 30 часов.
Какова лучшая практика в этой ситуации?
Ответы:
То, что я говорю, это:
Новый разработчик переоценивает задачу. Если он должен быть удален из итерации, то он будет удален.
Вы не знаете, сможет ли новый разработчик сделать это или нет, в то время, как это сделает первоначальный разработчик. А с гибкими методологиями разработчик, выполняющий работу, должен сказать, сколько времени это займет.
Кроме того, я бы применил множитель (насколько велик в зависимости от разработчика), так как разработчик должен соответствовать команде / проекту / компании.
Я бы не стал добавлять этого человека в этот индивидуальный спринт. Вместо этого дайте ему еще одно задание, над которым нужно поработать, чтобы ускорить работу с кодовой базой (возможно, низко висящие исправления?).
Добавление нового человека в команду, скорее всего, замедлит ваш прогресс в достижении этой конкретной цели, поскольку ему придется привыкнуть к вашей среде и узнать, как там все работает. Включите его в следующий спринт, с правильными оценками, основанными на новой команде.
Во-первых, я слышу «Agile Task» и думаю, что один-два дня работы, а не недели. Задачи - это то, на что вы разбиваете истории, когда сама история вписывается в итерацию, и очень редко иметь историю, которую нельзя разбить на более мелкие части.
Во-вторых, вы в основном просите этого нового разработчика взяться за дело. Если можно разумно ожидать, что он прыгнет прямо в ногу со скоростью остальной части команды, то первоначальная оценка должна сохраниться. Если он не может, он, вероятно, не должен придерживаться этой оценки, по крайней мере, не один.
В-третьих, какова ситуация? Я почти уверен, что ситуация была не в том, что команда оценила свою работу, тогда кто-то ушел, и вы заменили его на следующий день. Итак, я думаю, что ребята из X в команде оценили работу этого спринта и взяли то, что, по их мнению, они могли бы обработать, а затем вы представили нового парня, и теперь есть ребята из X + 1, которые делают работу, изначально обещанную ребятами из X , Если бы команда не выбрала свою рабочую нагрузку и вместо этого не заполнила отставание руководства, я бы не стал давать новому парню много работы на этой неделе. Если расписание было установлено руководством, это не Agile.
Лично я бы настроил этого парня на пару с более опытным программистом для его первого спринта (если ваши программисты не спариваются все время, что я предполагаю, что они не делают из-за того, что вы рассматриваете возможность дать один задание одному парню). Оглядываясь через плечо и задавая вопросы, он начнет изучать кодовую базу, и, если его общий навык программирования понизится, он почти сразу станет эффективным рецензентом кода, обнаруживая ошибки, неэффективный код и т. Д. И т. Д.