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

Это отличный пример открытого конфликта.
Может перед увольнением человека, попытатся понять в чем суть конфликта?

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

Садиться разговаривать. Задать честные и открытые вопросы.

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

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

И да, главный вопрос, на эстимирование задачи, разработчику дается время?

Один из самых важных моментов.

Или в стиле "Пили релизы, а еще сверху тут эстимейты пропиши"

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

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

Здесь можно:
1. Что бы вышестоящий руководитель который для разработчика авторитет сказал в чем заключаются функции тимлида и разработчика. То есть показал чье где место.
2. Тимлид тоже должен показать себя профессионалом и лидером.
3. Тимлид может откровенно поговорить с разработчиком. Возможно между ними когда то произошел конфликт после которого разработчик не хочет с ним взаимодействовать как с человеком.

В любом случае важно переводить ситуацию в конструктив.

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

очень понравился вариант, спасибо

про авторитет вы верно подметили
у вас тоже афигенные советы, все попробую

У нас в команде выделяется время на оценку до 30 минут. Если за 30 минут оценить не получается. То заводится задача на оценку в спринт и оценивается уже она. А по итогам этой задачи на оценку мы получаем либо задачу на разработку с оценкой, либо декомпозицию с оценками. Чаще всего в сроки укладываемся с погрешностью в пределах 30%. Так же на спринт закладывается время на поддержку релиза и консультации. Поэтому чаще всего выход за пределы оценки конкретной задачи компенсируется незначительным сокращением или совмещением других активностей

А еще отдельный кайф когда хвалят если закрыл спринт.

Просто сказать: «Женя молодец» на ретро дорогого стоит. Я ради этих слов любую таску вовремя закрою. А когда благодарности нет, а есть только негатив, то и спринты закрывать не хочется. Какой смысл?

А если есть ещё и штрафы за незакрытые спринты, то тут вообще супер демотивация включится.

Женя молодец!

Спасибо) теперь придется идти коммитить в tlroadmap 😆

Мыши плакали, кололись, но продолжали жрать спринты, дедлайны и эстимейты...

То ли дело канбан 👍
Ни спринтов, ни эстимейтов... Лишь бы деньги инвестора не закончились 😁

Жесть. Какие штрафы за спринты? Где такое?

А разве это так должно работать?

обыкновенный мазохизм. первый раз сталкиваетесь?