Несколько вещей, о которых следует помнить при оценке задач программирования
Оценка — одна из самых сложных вещей в программной инженерии, особенно если это то, что инженеры ценят и стремятся сделать правильно. Оценка формирует неформальный контракт между разработчиком, работающим над задачей, и более широкой командой, и когда она выполняется для каждой задачи, она превращается в единицу аппроксимации для всего проекта. Это, однако, независимо от того, сколько обдумывания, инструментов и опыта в него вложено, является догадкой, и циклы разработки программного обеспечения всегда будут полны непредвиденных обстоятельств. Препятствия могут быть техническими, исследование ошибок или способы решения конкретных проблем часто не являются простыми. Или они также могут быть связаны с человеческим капиталом. Способность и возможности посвятить блоки времени глубокой работе могут повлиять на скорость разработки.
Хотя обычно мы учитываем такие вещи, как объем кода, который необходимо написать, сколько сервисов будет затронуто задачей, риск зависимостей или технических неизвестных, вот еще несколько моментов, о которых следует подумать при оценке заявок.
Хорошо написанные задачи
Задачи должны быть четко определены, с четким определением выполнения и всей информацией, необходимой для этого тикета. Оценка сама по себе достаточно сложна, пытаться сделать это на основе неясных требований — не что иное, как притворяться предсказателем судьбы. Если вы сталкиваетесь с задачей, которая не была написана должным образом, либо отодвигайте ее, чтобы переписать, либо, если вы должны продолжать, не оценивайте. Есть лучшие способы потратить свое время, чем давать вводящие в заблуждение оценки.
Возможности
Рассмотрите возможности людей, которые могут взять на себя эту задачу. Этот аспект часто игнорируется, исходя из предположения о единообразии возможностей всей команды разработчиков. Однако независимо от того, насколько хороши ваши разработчики, индивидуальные способности будут различаться, как и их доступность (электронная почта, встречи, наставничество для младших), чтобы сосредоточиться на задачах. В идеале, оценка конкретных задач должна выполняться после назначения, или, когда она выполняется на высоком уровне, более глубоко обдумывать все разработчики, включенные в контекст.
Демократизировать процесс
Привлеките команду разработчиков и попросите их оценить индивидуально. Это способствует разнообразию мыслей, и вы также быстрее найдете различные аспекты задачи. Если оценки разных членов команды различаются, они могут представить свое дело, и после обсуждения команда может принять фактическую оценку. Это обсуждение важнее, чем просто придумывание числа, так как именно здесь задача распутывается и часто добавляется больше деталей, особенно связанных с реализацией. Это может значительно облегчить выполнение задачи.
Обновление оценок
Не бойтесь обновлять оценку, которую вы имеете для задачи. Поскольку оценка, в конце концов, является всего лишь предположением, эмоциональная привязанность к числу контрпродуктивна. Скомпрометировать качество может быть не очень хорошей идеей большую часть времени. Поэтому после выполнения задачи, если вы считаете, что это может занять больше времени, оценку следует обновить. Это, в свою очередь, способствует лучшему общению с другими заинтересованными сторонами и позволяет людям узнать, чего им следует ожидать. Иногда, начав работу с билетом, вы можете понять, что требуется более тяжелая работа, чем вы предполагали изначально. В таких случаях не бойтесь разделить билет и переоценить.
Учитывайте прошлые оценки
Сравните сложность задачи с выполненными билетами. Сколько времени заняло предыдущее подобное задание? Насколько различаются риски, трудозатраты или общая сложность? Есть ли разница в возможностях разработчиков? Не бывает двух одинаковых билетов, но оценка прошлых оценок и того, как они отражались на практике, даст важный контекст. Если выполнение задачи заняло намного больше времени, чем предполагалось, вы также должны выяснить, почему это стоит. Это размышление поможет вам воздержаться от подобных ошибок в будущем.
Независимо от того, насколько тщательна ваша тактика оценки, скорее всего, вы будете ошибаться чаще, чем нет. Однако вы живете и учитесь, и со временем и зрелостью проекта оценки будут выглядеть все более и более точными. Хорошей практикой является использование оценки в качестве приблизительной оценки и поддержание хорошей связи с командой и заинтересованными сторонами проекта. Это будет держать всех в курсе о времени и усилиях, связанных с задачей, и значительно облегчит поиск помощи в случае необходимости.
Больше контента на blog.devgenius.io.
