Соотнесение оценок задач с пунктами

Меня нередко просят объяснить взаимосвязь между оценками задач, используемыми при планировании итерации, и пунктами или идеальными днями, используемыми для более долгосрочного планирования релиза. По моим наблюдениям, команды сбиваются с пути, когда начинают верить в то, что между пунктами и точным числом часов существует сильная взаимосвязь. Так, сравнительно недавно я работал с одной командой, которая отслеживала фактическое количество продуктивных часов на итерацию и скорость на итерацию. На основе полученных данных она рассчитала, что каждый пункт соответствует примерно 12 часам работы. Команда ошибочно решила, что один пункт всегда равен 12 часам работы. Вместе с тем в реальности мы имеем нечто близкое к тому, что показано на рис. 14.5.

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

Если на рис. 14.5 представлено распределение времени для однопунктовой пользовательской истории, то на рис. 14.6 показано гипотетическое распределение времени для одно-, двух- и трехпунктовой истории. На этом рисунке один пункт эквивалентен в среднем 12 часам. Вместе с тем вполне может оказаться, что реализация некоторых однопунктовых историй занимает больше времени, чем реализация некоторых двухпунктовых историй.

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

Дни недели

Когда я только стал руководить agile-проектами, мои команды обычно начинали выполнение итераций в понедельник и завершали их в пятницу. Мы делали это независимо от того, какие итерации использовались — двух-, трех- или четырехнедельные. Понедельник казался самым естественным днем для начала итерации, а пятница — для ее завершения. Мои представления, однако, изменились после того, как я взялся за обучение команды, разрабатывавшей веб-сайт, который активно использовался в будни и практически не посещался в выходные.

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

Иногда команда утром в пятницу подчищала хвосты — завершала появившуюся в последний момент работу, которую не успела сделать в четверг. Это не было правилом и случалось от силы пару раз, но возможность завершить такую работу за несколько часов в пятницу утром намного лучше перспективы доделывать ее в выходные (что было бы неизбежным, если бы итерации начинались в понедельник).