Майк Кон - Agile: оценка и планирование проектов

Во-вторых, даже если работа с историями в таком порядке увеличивает срок выполнения проекта, это не имеет значения, поскольку, надо думать, для отказа от работы в естественном порядке была веская причина. Команда могла изменить порядок работы над историями с тем, чтобы быстрее устранить технический риск. Или владельцу продукта могла раньше потребоваться обратная связь от пользователей по истории, которая при естественном порядке работы была бы реализована позднее. Реализация историй в порядке, отличном от естественного, позволяет команде раньше получить обратную связь и потенциально сэкономить месяц-другой на переделках ближе к концу проекта (когда календарный график сложнее поддается таким изменениям).

Некоторые функции очень трудно разбить на задачи. Так, недавно мне пришлось заниматься планированием совещания для обсуждения небольшого изменения устаревшей функции. Никто не может быть уверен в своей способности предвидеть все без исключения возможные последствия изменения. Мы знали некоторые фрагменты программы, которые будут затронуты, но у нас не было уверенности в том, что изменение не скажется на каких-либо других фрагментах. Изменения во фрагментах, о которых мы знали, были незначительными, поэтому их оценили в сумме в четыре часа. Если бы затрагивались другие фрагменты, то оценка могла бы быть значительно более высокой — вплоть до 20 часов. Без анализа кода мы ничего не могли сказать, однако прерывать совещание из-за этого не хотелось. В результате мы ввели следующие две задачи:

• Определение того, что затрагивается, — два часа.

• Внесение изменений — 10 часов.

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

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

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

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

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

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

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

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

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

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

Создаваемые вами задачи должны иметь примерно такой размер, чтобы каждый разработчик мог завершать в среднем одну из них за день. Подобный размер очень удобен для равномерного выполнения работы в течение всего agile-процесса разработки. Более крупные задачи нередко задействуют одного-двух разработчиков, а остальные члены команды вынуждены ждать, пока те завершат свою работу. Кроме того, если команда проводит короткие ежедневные совещания (Schwaber and Beedle, 2002; Rising, 2002), то однодневные задачи позволяют каждому разработчику отчитываться о завершении как минимум одной задачи практически каждый день.