Какие способы оценки задач используют разработчики

Привет всем! Теория, необходимая для старта в разработке, весьма обширна. У каких-то специалистов (backend-разработчиков на Java и других языках) ее больше, а других (например, frontend-разработчиков на JavaScript — React Native) — чуть меньше. Однако и у одних, и у других должен быть большой запас не только технических, но и “организационных” знаний. Эти “организационные” познания — одна из точек пересечения для frontend- и backend-разработчиков. Сегодня я хочу поговорить об одном из аспектов таких нетехнических, организационных знаний — об оценке задач (estimation). И так как я работал только в Agile методологии (которая по факту считается самой популярной), в его подчасти, Scrum, рассматривать оценку задач буду в контексте Scrum. Сразу скажу, что оценка, называемая ещё эстимацией, трудна. Лично для меня как для разработчика это один из самых трудных / нежелательных аспектов работы. Необходимо учитывать множество различных факторов, которые могут повлиять на оценку задачи. При этом планы по дальнейшей разработке будут отталкиваться от ваших прогнозов.

А что если не угадать с оценкой?

Если разработчик закладывает на задачу гораздо больше часов, чем в итоге будет потрачено, может сложиться впечатление, что он не самый лучший специалист, ведь оценка была очень неточной. Так сказать, пальцем в небо. В то же время, если разработчик не вложится в прогнозированное время, он ставит под угрозу планы заказчика по выпуску продукта/новой фичи. Это бизнес, а бизнес — это деньги, и мало какому заказчику понравится такой прокол. Собственно поэтому я и недолюбливаю эстимацию, ведь иногда так сложно установить точное время выполнения задачи.

Как проводится оценка времени

Как правило эстимация проводится в часах или стори поинтах. Лично мне гораздо ближе процесс оценки именно в стори поинтах. Если часы — это что-то физическое, то, в чём можно ошибиться, стори поинты — это уже немного о другом, более абстрактном. Как правило, команды разработчиков ПО дают оценки в формате времени: часы, дни, недели, месяцы. Такие временные оценки основаны в первую очередь на личном опыте, предположении или интуиции. В таком случае разработчики просто смотрят на задачу и озвучивают предположение, сколько она бы заняла у него времени. В итоге они весьма редко бывают точными, ведь есть слишком много факторов, которые могут повлиять на срок выполнения работы. Поэтому многие команды, работающие по Agile методологии, используют именно стори поинты. Давайте разбираться.

Что такое Story points

Стори поинт — это единица измерения, выражающая оценку общих усилий, которые необходимы для полной реализации определенного участка работы (функционала). То есть, это такая себе относительная сложность. Команды присваивают оценку в стори поинтах в зависимости от сложности работы, объема работы, риска или неопределенности. Как правило эти значения назначаются, чтобы эффективнее разбивать работу на более мелкие части, тем самым устраняя неопределенность. Со временем это помогает командам понять, чего они могут достичь за определенный период времени, и способствует более точному планированию следующих участков работы. Вам это может показаться совершенно нелогичным, но на самом деле эта абстракция весьма полезна: она подталкивает команду к принятию более жестких решений относительно сложности работы. Давайте рассмотрим некоторые причины использовать стори поинты при планировании:

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

Как НЕ надо использовать стори поинты

К большому сожалению, стори поинты часто применяют не по назначению. Стори поинты могут ошибаться, если они используются для оценки людей, определения подробных сроков и ресурсов, а также когда их ошибочно принимают за меру производительности. Вместо этого командам необходимо их использовать, чтобы понять объем / сложность работы в каждой задаче и для расстановки приоритетов. Возможно, что части, которые оценены как более сложные, стоит делать в первую очередь, чтобы их удалось сделать до до конца спринта, ну а более легкие отодвинуть на позже. Напомню вам, что такое спринт в контексте Scrum методологии:Насколько долгий этот временной промежуток, определяется в начале разработки по договорённости команды и заказчика. Это может быть промежуток в две недели или месяц, или любой другой срок. Как правило эстимация задач ведется в начале спринта, чтобы спланировать возможный объём выполненной работы к его концу, когда выполненная работа предоставляется заказчику. Оно помогает видеть ваш прогресс в разработке продукта, получать фидбек от заказчика и скорректировать развитие проекта согласно видению заказчика. Но все же мы немного отвлеклись: вернёмся к эстимации. Оценка задач лишь одним разработчиком была бы слишком субъективной. Поэтому как правило это командная работа. Техник для командной оценки довольно много. Сегодня мы рассмотрим самую используемую из них — Scrum poker. Для этой техники необходим менеджер, который будет кем-то типа ведущего этого Scrum poker-а. Это может быть человек специализации Scrum Master, ну или же PM.

Что такое Scrum Poker

Scrum poker — или покер планирования — это техника оценки, которая основана на достижении договорённости. В основном используется для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке ПО. Сразу отмечу, что Scrum poker — обычная практика при разработке, и вам точно нужно знать, что это за зверь. Для этого процесса обычно используется некое приложение или сайт, который позволяет нам организовывать командную оценку той или иной задачи. Как это происходит? Команда берёт элемент невыполненной работы (новую задачу, функционал), вкратце обсуждает возможные подводные камни и другие нюансы, связанные с ним. После этого каждый участник выбирает карточку с числом, которое отображает его оценку сложности. Ах, да при оценке используются не обычный ряд, а числа Фибоначчи. Числа Фибоначчи так популярны в scrum poker-е потому, что между ними со временем увеличивается промежуток (напоминает уровни пирамиды). Существуют задачи, у которых будет огромная сложность, и малым количеством стори поинтов тут не обойтись. Пояснение для необычных карточек:

неизвестное количество эндпоинтов

бесконечно долгая задача

нужен перерыв

Более редкие способы эстимации:

• в размерах футболок —S, M, L, XL
• или в собаках — чихуахуа, мопс, такса, бульдог и так далее (как по мне, это самая странная единица оценивания задач =D)

Затем команда сравнивает поставленные оценки одной и той же задаче разными разработчиками, и если они сходятся, отлично! Если же нет, необходимо обсудить причины различий в оценке (аргументы). После этого можно сообща прийти к единому эстимейту, с которым все плюс-минус будут согласны. Ну а почему вообще используется покер для планирования серьёзного программного проекта? Ведь это как-то странно. На самом деле подобная геймификация побуждает членов команды мыслить независимо, предлагая им показать свой результат одновременно со своими тиммейтами. Это, в свою очередь, позволяет избежать зависимости от взглядов других членов команды. Ведь иначе менее опытные разработчики будут поглядывать и ориентироваться на оценки более опытных членов команды, что сведёт на нет полезность их собственной оценки. Но при одновременном вскрытии результатов это по сути невозможно. В качестве примера приложения для планирования в формате Scrum Poker можно взять приложение от Atlassian.

Пример оценки задачи

Представим, что ваша команда выделила некоторую шкалу для оценивания в стори поинтах:Начинается Scrum Poker по задаче, и вы оцениваете ее так:

• вы никогда не работали с имплементацией аналогичного функционала ранее — +3
• функционал задачи среднего объема — +2
• реализация задачи имеет высокую сложность — +3
• высокая сложность написания тестов для данного функционала — +3

По итогу получается 11 стори поинтов, но так как такой карточки нет, вы предлагаете 13. Другой ваш коллега оценивает задачу:

• работал с аналогичной задачей ранее — +1
• функционал задачи среднего объема — +2
• реализация задачи имеет среднюю сложность — +2
• средняя сложность написания тестов для данного функционала — +2

В итоге у него получается 7 стори поинтов, но такого в числах Фибоначчи нет, и он ставит карточку с максимально приближенным числом — 8. Другие члены команды, соответственно, ставят оценки, отталкиваясь от своих субъективных взглядов. Далее вы показываете свои результаты и обнаруживаете, что почти все ваши коллеги поставили эстимацию 13, кроме одного разработчика, который поставил 8. В таком случае ему даётся слово, и он приводит доводы. А они, к примеру, такие: он работал ранее с такой же задачей, и она не так сложна, как это может показаться, и в итоге он убеждает остальных членов команды сменить своё решение с 13 на 8 стори поинтов, говоря, что он поможет тому, кто займется этой задачей, разобраться с ней. Либо, в конце концов, выполнит её сам. И во общем-то не важно, прислушаются к его доводам остальные или нет, ведь так или иначе оценка будет присвоена данной задаче, и команда перейдет к ознакомлению со следующей. Первые разы оценки будут неточные, как и прикидки объема работ, которые вы планируете сделать за следующий отрезок времени (спринт). Ведь эти прикидки делаются именно по эстимациям. Спустя какое-то время, примерно месяца через три, команда начнёт более точно оценивать задачи, да и станет виден средний объем работ, который может выполнить команда за спринт. Но это общее планирование объема работ, это больше про время, а в данном случае может быть много разных факторов, оказывающих влияние. Например, ушёл в отпуск на две недели один из разработчиков. То есть нужно вычеркнуть определённый объем планируемых работ (планируемого функционала). Или в команду пришёл новый разработчик, но при этом полноценно на него рассчитывать не надо, т.к. нужно учесть время на адаптацию к проекту, называемое онбордингом. Это может быть недели две, плюс-минус неделя, в зависимости от сложности проекта. На этом у меня сегодня всё, надеюсь я немного улучшил ваши познания в такой нетехнической части знаний как эстимация задач. Если же вы хотите углубиться в данную тему, как и в детали Scrum, настоятельно советую прочитать книгу Джеф Сазерленд "SCRUM". За последствия я не ручаюсь, ведь возможно, после неё у вас появится назойливое желание стать Scrum Master-ом =D