В софтверном проекте многозадачность еще больше увеличивает разрыв между идеальным и общим затраченным временем. Тренер никогда не скажет футболисту: «Поскольку ты занят не в каждой игре, сыграй-ка еще в этом очень важном хоккейном матче». Разработчик программного обеспечения, которого заставляют работать в многозадачном режиме, в значительной мере теряет свою эффективность в результате переключения между двумя (или более) задачами.
В софтверном проекте мы можем оценивать пользовательские истории или другую работу в
• оцениваемая история — это единственная задача, над которой вы работаете;
• все, что вам необходимо, есть под рукой в момент начала работы;
• перерывы и отвлечения отсутствуют.
Идеальные дни как показатель размера
При оценке числа идеальных дней, необходимых для реализации той или иной пользовательской истории, не нужно учитывать влияние непроизводительных издержек, обусловленных средой, в которой работает команда. Если на разработку конкретной экранной формы мне необходим один идеальный день, то я буду заниматься ею один идеальный день, независимо от того, работаю ли я в стартапе без непроизводительных издержек, в условиях, где меня отвлекают другие сотрудники, или в жесткой бюрократической системе. Количество времени, которое пройдет по часам (или по календарю), конечно, будет другим. Возможно, мне удастся затратить на работу немногим больше идеального дня в стартапе с низкими непроизводительными издержками. Чем больше будет отвлекающих моментов, тем меньше времени у меня останется на разработку продукта для проекта и тем больше будет срок выполнения работы, рассчитанной на один идеальный день.
Если оставить в стороне непроизводительные издержки организации, то идеальные дни можно использовать для оценки размера точно так же, как и пункты. Затем оценку размера в идеальных днях можно преобразовать в расчетный срок выполнения работы с помощью скорости аналогично тому, как это делается с оценкой размера в пунктах.
Одна оценка, а не множество
Если вы выбираете идеальные дни для оценки, присваивайте одно общее значение каждой пользовательской истории. Некоторые команды пытаются оценивать количество идеальных дней для каждого работника или группы, которые работают с пользовательской историей. Например, команда может сделать такую разбивку для конкретной пользовательской истории: два идеальных дня — программист, один идеальный день — инженер по базам данных, один идеальный день — дизайнер пользовательского интерфейса и два идеальных дня — тестировщик. Мне встречались команды, которые записывают оценки по ролям на карточке истории разноцветными маркерами или прикрепляют к ней разноцветные стикеры.
Обычно я не советую этого делать. На данном этапе концентрация внимания на индивидуальных ролях в команде отвлекает от идеологии «мы все работаем над этим вместе», которую хотелось бы видеть в agile-команде. Помимо прочего, это очень сильно увеличивает объем работы при планировании релиза. Если в каждой истории делать оценку для каждой роли, задействованной в работе, план релиза должен корректно учитывать эти роли, а в таком случае необходимо отслеживать скорость и оставшийся объем работы для каждой роли.
Хотя на это редко когда стоит тратить силы, иногда такой подход просто необходим. Не так давно у меня был клиент, работающий с тремя версиями продукта — одна для Macintosh, другая для Windows и третья для карманных компьютеров. В этом случае критически важно обеспечить абсолютно одинаковую функциональность. Более того, члены команды на тот момент не могли переключаться с разработок для Mac на разработки для Windows и карманных компьютеров. В такой ситуации оценка идеального времени для каждой роли по каждой истории может быть полезна. Следует, однако, учитывать, что это увеличивает бремя администрирования.
Резюме
Идеальное время и общее затраченное время — не одно и то же. Идеальное время игры в американский футбол составляет 60 минут (четыре 15-минутных периода). Вместе с тем для завершения 60-минутного матча обычно требуется около трех часов. Такая разница объясняется наличием перерывов в игре.
Количество времени, необходимое для реализации пользовательской истории, легче оценивать в идеальных днях, а не в затраченных днях. Оценка в затраченных днях требует учета всех перерывов, которые могут возникнуть в процессе работы над историей. Если же для оценки используются идеальные дни, то учитывается только время реализации истории. Таким образом, идеальные дни характеризуют размер работы, хотя и не так строго, как пункты.