Agile: оценка и планирование проектов - [22]

Этот последний момент очень важен. В результате многолетней практики большинство футбольных болельщиков знают, что время окончания матча 16:00 — всего лишь оценка. Никто не удивится, если игра продлится до 16:15 (превышение на 8 %). Болельщики могут расстроиться или рассердиться, но не удивиться. Почему же тогда мы удивляемся, если проект по разработке программного обеспечения, оцененный в 12 месяцев, занимает 13 месяцев (превышение на те же 8 %)? Какой срок труднее оценить?

Идеальное время и разработка программного обеспечения

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

• поддержка текущего релиза;

• отсутствие из-за болезни;

• совещания;

• демонстрации продукта;

• работа с персоналом;

• телефонные переговоры;

• специальные проекты;

• повышение квалификации;

• электронная переписка;

• анализ сделанного и прогоны;

• собеседования с кандидатами;

• переключение на другие задачи;

• устранение ошибок в текущих релизах;

• управленческий анализ.

Кроме того, при выяснении причин, по которым идеальное время не соответствует общему затраченному, учтите, что руководители могут непрерывно работать от одного отвлекающего события до другого не более пяти минут (Hobbs, 1987). Даже если типичный разработчик отвлекается в три раза реже, время его непрерывной работы составляет всего 15 минут.

Проблемы могут возникать, когда руководитель задает члену команды неизбежный вопрос: «Сколько времени на это потребуется?» Член команды отвечает «Пять дней», а руководитель отсчитывает пять дней в своем календаре и помечает срок окончания работы жирным красным знаком Х. Член команды, однако, на самом деле хотел сказать: «Пять дней, если я буду заниматься только этим, но у меня полно других дел, поэтому примерно две недели».

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

В софтверном проекте мы можем оценивать пользовательские истории или другую работу в идеальных днях. При оценке в идеальных днях следует исходить из следующего:

• оцениваемая история — это единственная задача, над которой вы работаете;

• все, что вам необходимо, есть под рукой в момент начала работы;

• перерывы и отвлечения отсутствуют.

Идеальные дни как показатель размера

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

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

Одна оценка, а не множество

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

Обычно я не советую этого делать. На данном этапе концентрация внимания на индивидуальных ролях в команде отвлекает от идеологии «мы все работаем над этим вместе», которую хотелось бы видеть в agile-команде. Помимо прочего, это очень сильно увеличивает объем работы при планировании релиза. Если в каждой истории делать оценку для каждой роли, задействованной в работе, план релиза должен корректно учитывать эти роли, а в таком случае необходимо отслеживать скорость и оставшийся объем работы для каждой роли.