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

Действительно, любой здравомыслящий человек, прежде чем применять новый подход, должен задаваться вопросом: “Какую проблему я решаю?”.

Итак, какую проблему мы решаем с помощью буфера времени? Моя статья была навеяна проблемой планирования итерации, которую я обсуждал со своими клиентами. Вы наверное видели ниспадающие (burndown) графики в Cпринте, вроде этого:

или этого:

Они говорят о том, что команда планирует больше, чем реально может сделать. Это может происходить из-за того, что при планировании итерации считается максимальный запас рабочего времени в команде (capacity) и потом берутся на себя обязательства по максимуму. Как результат, что-то в Спринте идет не так, как хотелось бы, и в итоге команда делает не все из запланированного или прилагает к этому излишние усилия.

Чем это плохо? Прежде всего, команда не выполняет взятые на себя обязательства – это ведет к подрыву доверия к команде со стороны Владельца Продукта и заказчиков. Опять же, сама команда де-мотивируется из-за того, что не все сделано, и со временем может прийти к состоянию, когда все будут мыслить: “чего напрягаться, все равно все не сделаем”. А даже если и сделаем, то ценой дополнительных усилий и переработок. Ну и другие подобные негативные последствия – список можно еще продолжать и продолжать.

Выход из описанной ситуации с избыточным планированием многие команды находят эмпирически. Я уже неоднократно слышал, как Скрам Мастера говорят, что они вычитают из суммарной “мощности” (capacity) команды какой-то процент времени, как буфер времени, мол, “на риски”. В прошлой статье, я рассказал, для чего именно и как выбирать размер этого буфера. Уверен, эта техника поможет объяснить, зачем вы делаете буфер и лично Скрам Мастеру и команде и заинтересованным лицам.

Следует четко понимать, две вещи:

Первое, у такой комплексной проблемы есть много факторов и решать ее нужно с разных сторон. Т.е. не следует надеяться, что вы примените одну технику и все само собой решится. Действительно, есть риск “замаскировать” проблему, если бездумно применять техники. Я учу команды, с которыми работаю, копать до причин и устранять проблемы “на корню”.
Например, одновременно с применением этой техники, стоит работать над повышением точности оценок, тогда можно снизить первый тип буфера “времени на погрешность оценок”. Также стоит работать над повышением качества и устранением дефектов, которые находятся поздно, во время верификации, тогда можно снизить второй тип буфера “времени на баги”. Ну и технический долг лучше не накапливать, тогда и платить его почти не придется 🙂

Второе, на что стоит обратить внимание – это то, что никогда не стоит делать буфер на конкретную задачу или даже конкретный элемент Бэклога! Об этом я достаточно подробно рассказывал в своем докладе “Почему совместные оценки все-таки помогают Agile командам” – полистайте, там есть жизненные примеры ;-).
Когда вы делаете “запас” на отдельной задаче, то тут-то вас и настигает “закон Паркинсона” во всей его красе. В итоге, время тратится, а риски все равно “выстреливают” и сдвигают планы – погрешность накапливается и приводит к опозданию всей Истории или срыву планов всего Спринта. Как я говорил в докладе: “Ставить буфер в конце цикла, а не локально в каждую задачу/требование“.

В принципе, об этом же и говорила картинка, которую я вставил в прошлую статью:

И если вам понадобится кратко пересказать суть подхода коллегам, то я рекомендую запомнить следующее:

• Ставить буфер в конце цикла, а не локально в каждую задачу/требование
• Буфер делается отнимая часть “мощности” (capacity) команды и на него просто не планируются конкретные работы в Спринте
• Нужно постоянно работать над контролем использования и уменьшением размера буфера – тогда вы оптимизируете весь процесс

Надеюсь теперь стало понятнее.

Оставайтесь с нами, мы еще не раз вернемся к теме управления проектами.