Не встречал еще разработчиков, которые любят оценивать задачи | Сеньор

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

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

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

Почему?

Потому что менеджер знает, что программисты склонны к недооценке задач и к переоценке способностей. И что в 9 случаях из 10 — первоначальная оценка будет не верной.

"Но ведь придумали уже давно story points и другие agile штуковины!"

Вместо оценки в часах или днях, на помощь пришли story points, которые включат в себя все риски. Удобно использовать числа Фибоначчи (1, 2, 3, 5, 8, 13 и тд), где чем больше число, тем сложнее и больше задача. Они и правда помогают, но также не лишены проблем.

Что такое 1 story point? В чем разница между 5 и 8? Как вообще оценивать?

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

Даже спустя годы и работы в разных компаниях мне не кажется понятным и объективным процесс оценки задач в agile мире. Команда собирается, открывает задачу и все должны одновременно назвать, показать или выкрикнуть число, которое они считают верным. Используют карты scrum poker, показывают на пальцах, считают до трех и все должны одновременно написать число. Похоже на секту или развлечение для детей, но уж не на объективный разговор взрослых людей.

Здесь слишком много субъективности — кто-то сказал или написал число первым, несовпадающее с моим. А что если все сказали число ниже? Становится неуютно и хочется не спорить, доказывая правоту, а слиться с толпой и быть как все. И откуда здесь взяться точности в оценках?

Поэтому и story points тоже нужно умножать на два или три, если хочешь получить приближенную к реальности оценку.

Но как же тогда быть? Как оценивать задачи без этих угадалок?

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

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