Оценка задач

We use cookies. Read the Privacy and Cookie Policy

Следующий этап планирования итерации на основе скорости — оценка каждой задачи. Одни команды предпочитают оценивать задачи после того, как все они будут идентифицированы, другие — по мере идентификации. Оценки задач выражаются в идеальном времени. Так, если я считаю, что задача займет у меня шесть рабочих часов, то даю оценку «шесть часов». Я даю такую оценку, даже если шесть часов чистой работы над задачей потребуют от меня затраты целого восьмичасового дня.

Хотя я согласен с общепризнанным мнением, что лучше всего оценивает тот, кто выполняет работу (Lederer and Prasad, 1992), на мой взгляд, оценка в agile-проекте должна быть коллективным занятием. Для этого есть четыре причины.

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

Во-вторых, даже если мы предполагаем, кто именно будет выполнять задачу, и даже если этот исполнитель знает больше всех о данной задаче, это не означает, что другим нечего добавить. Допустим, во время совещания по планированию итерации Джеймс говорит: «Мне потребуется примерно два часа, чтобы запрограммировать функцию, — это тривиально!» Однако вы помните, что в прошлом месяце у Джеймса была похожая задача и он дал такой же комментарий, но на выполнение той задачи ушло почти 16 часов. В этот раз, когда Джеймс скажет, что такая задача требует всего лишь два часа, вы можете добавить: «Но, Джеймс, в прошлый раз, когда ты работал над похожей задачей и тоже оценивал ее в два часа, на нее в действительности ушло 16 часов». Скорее всего, Джеймс назовет разумную причину, по которой в этот раз все будет иначе, однако он может согласиться с тем, что с такими задачами связаны определенные трудности, которые он систематически упускает из виду.

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

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