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

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

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

График команды "опоздали"

или этого:

График хорошей команды

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

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

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

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

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

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

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

How Backlog types affect buffer in the sprint

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

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

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

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

Какую проблему решает буфер времени при планировании итерации
Tagged on:                     

6 thoughts on “Какую проблему решает буфер времени при планировании итерации

  • Так мы потихоньку придем к еще одной «стародавней» традиции менеджеров: «Ну команда же еще неопытная и несмышленая. Откуда им знать как оценить задачи. А я уже таких проектов делал-переделал. Я лучше за них оценю и буфер оставлю, чтобы уж точно успеть…». 😉

    1. Коля, что же тебе за менеджеры попались, которые тебя так загнобили? 🙂

      Мы же вроде говорим про Scrum команды. Пусть ScrumMaster в какой-то мере и представитель менеджмента, но он все-таки «свой» 😉 И ведет себя обычно более адекватно, чем ты описываешь

      1. Меня как раз так загнобить у них не получалось. А в целом, обернись и посмотри по сторонам — в Украине так большая половина работает. 🙂 И ScrumMaster-ом часто становится бывший менеджер с таким же старым мышлением.

        1. Коля, думаю, что не открою тебе секрет — проблема описанная тобой ВЕЗДЕ 🙂

          Я работаю много вне Украины и проблема «хорошего ScrumMaster’а» стоит почти всегда.

          Поэтому высоки шансы неправильного использования _любого_ инструмента 😉

  • На самом деле, все можно делать намного проще. Считайте не только оценку Product Backlog Item-а в «попугаях», но и ту оценку в часах, которую команда ставит задаче тоже примите «попугаями». И сразу все становится просто. На спринт, мы должны взять не более N «побугаев бэклога», но при расшивровке в задачи, мы должны получить не более M «попугаев задач».
    Тогда, как только получили число часов, которые себе напланировали программисты, сравнили их с M, и сразу становится понятно, что около дела или будем халявить, или будем трудиться в поте лица и все равно не успеем.
    Очень непонятно объяснил? Или терпимо?

    1. Алексей, все точно подмечено.
      Опытные команды приходят к неким «идеальным часам» — ваши «М-попугаи».

      А при планировании Спринта можно и нужно использовать свою среднюю скорость в N и M. Соответственно брать нужно столько, сколько сможете сделать 🙂

Comments are closed.