fbpx
Опасная практика использования буферов в Scrum

буфера в оценках

Прочитал статью Тима Евграшина “Когда подстилать соломку или планирование Спринта с учетом вашей реальности” и понял, что в этом вопросе наши мнения и опыт сильно расходятся. 🙂 Мои комментарии были слишком большими и я решил вынести их в отдельную статью.

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

А вот по поводу буферов я категорически не согласен. На мой взгляд, данная техника является чуть ли не самой опасной. Во-первых, это попытка не учиться на своих ошибках, а обложиться буферами, чтобы минимизировать их влияние. Вспомните как раньше делали оценки – менеджер закладывал буфер в магические X% от оценки команды, чтобы “обезопасить себя от этих имбицилов”. Мы же в Scrum пытаемся научиться давать надежные оценки на короткий срок. Спрятавшись за буферами, трудно будет найти свои ошибки и их исправить. Для этого понадобится анализ использования буфера, что приведет к дополнительной работе над сбором и анализом метрик.

Во-вторых, буфер на исправление ошибок в спринте – одна из самых нелогичных вещей в IT. Вводя такой буфер, мы как бы говорим: “Мы заранее знаем, что напишем код с багами!”. А как же критерий готовности, забота о качестве (quality assurance), инженерные практики и надежная поставка? Неужели кто-то может оценить с такой позиции сколько займет фикс багов для задач в спринте? Это же оценки пальцев в небо! Нельзя оценить то, объем чего тебе неизвестен. Зато можно попытаться оценить усилия на предотвращение багов и включить их в изначальную оценку задачи. Ведь на планировании мы все задачи разобрали в деталях и знаем о них все!

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

Буфер на выплату технического долга также противоречит идее “разноцветному бэклогу”. Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. И их тоже нужно оценивать. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным.

Последний тип буфера (у Тима он упоминается первым) – время на погрешность в оценках. У него практически те же минусы, что у предыдущих буферов, но существует подход, который действительно может обезопасить вас от неверных оценок безвредно. Просто выбросите последний день итерации из доступного времени, введя правило “никакой работы над задачами в последний день итерации”. Если в итерации что-то пошло не так, то это критическая ситуация и данный день послужит буфером. Но это нарушение правила команды и ставит вопрос на ретроспективу для обсуждения. Если же все нормально, то в этот день можно будет качественно подготовить демо, закрыть мелкие дефекты по задачам в итерации, отдать часть технического долга или даже начать работать над новыми задачами из бэклога.

Еще один способ обезопасить себя с оценками – “принцип 80 на 20”. Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе.

А вообще, Agile подходы несут в себе прозрачность, предсказуемость и постоянный самоанализ в качестве основных ценностей. Любой буфер идет в разрез с этими принципами и пытается “замазать” проблемы и скрыть их. Поэтому будьте осторожны и не используйте их в своей работе!

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (8)

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

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

По поводу последнего дня – в том то и дело, что это буфер очень видимый. Если в последний день что-то делается, то есть проблема и надо обсуждать на ретроспективе. Значит оценки неправильные были или еще что-то…

Со многим согласен в статье. Но как вы разбираетесь с лайв багами – наследием ошибок прошлых поколений?

И, имхо, практика последнего дня, тот же буфер, только с ограничениями.

Спасибо! Я действительно забыл про такую важную штуку как Velocity. Буфера ее смазывают и это нехорошо.

Полностью согласен с Николаем. Плюс хочу добавить, что важная и полезная метрика Velocity команды (как для команды так и для PO) с буферами теряет всякий смысл

Так задача прозрачного процесса (каким является Scrum) – добиться предсказуемости и доверия. Я уже написал, что количество багов оценить невозможно, а время на их починку и подавно. Получается, что мы добавляем еще один элемент неопределенности в процесс – буфер времени на исправление багов. Он будет то работать то не работать. И что тут классного? Будет ли доволен заказчик, что любая итерация может завершиться неудачей?

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

Ось тут відчувається різниця між ПМом і Тім/Тех лідом.
Першому важливо щоб замовник був happy і не важливо якщо щось десь іде не так, а другому важливо щоб все робилося правильно, що теоретично, в майбутньому теж має зробити замовника щасливим.
Нехай Тим Евграшин і замаскує якісь внутрішні проблеми за рахунок буферів, зате при роботі з клієнтом все буде чудово.
Тобто хочу сказати, що в ПМа і в Тім ліда принципово різні цілі, тому і підхід відрізняється.

Leave a Reply

Your email address will not be published. Required fields are marked *

Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online