Максим Цепков - Менеджмент цифрового мира

За подготовку и необходимую детализацию задач отвечает Product Owner. Как уже говорили, Она выполняется не заранее, а по мере продвижения проекта только для ближайших спринтов. Потому что детальные проработки проекта целиком имеют печальное обыкновение сгнивать раньше, чем добираются до реализации, и оказываются бесполезной работой.

Если такая подготовка задач к будущему планированию требуют заметных трудозатрат, то их надо планировать в предыдущим спринте, а если ограничивается обсуждениями, то отдельное время не выделяется, оно учитывается как общие накладные расходы. Процесс такой подготовки называется backlog grooming или backlog refinement. Груминг – первоначальное название, и оно соответствует сути, однако у него есть негативные сленговые коннотации, поэтому в официальных документах оно было заменено на refinement, подробности можно прочитать в этой статье.

Подготовка бэклога показана на моей рисовке схемы отдельным процессом, хотя часто ее помечают просто надписью на содержании спринта. Этот процесс требует организации. Простой способ – добавить к скрам-доске три колонки слева, в первую из которых Product Owner будет вывешивать задачи, ожидающие подготовки, во второй – те, которые готовятся на данный момент и в третьей – готовые к включению в будущий спринт. Но если процесс более сложен и требует внешних согласований, то такой способ может оказаться недостаточен. Тогда для подготовки бэклога можно организовать отдельный Kanban-процесс – об этом есть хороший доклад Алексея Пименова на SECR-2016 « Discovery Kanban для управления беклогом Scrum-команды».

Еще один вариант организации подготовки бэклога – уже упоминавшийся в главе «Завершение спринта в Scrum – демо и ретро» splitting sprint, разделение спринта на два со сдвигом.

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

Оценка работ.

Об оценке трудоемкости следует сказать отдельно. Она может выполняться в физических единицах, например в человеко-часах, в том числе в разрезе конкретных специалистов. В этом случае понятно, как определять, сколько задач поместиться в спринт: у нас есть общий ресурс часов команды, с учетом текущих отпусков, есть нормированные накладные расходы и резерв на регулярные потоки работ, если команда их делает, и дальше мы просто учитываем загрузку специалистов. Такая оценка практикуется, при этом, однако, важно не стремиться к излишней точности оценки. Обычно это достигается применением карточек, где оценка дана в числах Фиббоначи (1, 2, 3, 5, 8, 13, 20, 40) или степенями двойки. Но практика показывает, что при относительно однородном потоке задач не менее точной, зато гораздо более быстрой является оценка не в часах, а условных единицах Story Point или в условных размерах: S, M, L, XL. При этом на нескольких спринтах эта оценка калибруется и емкость спринта или скорость команды определяется именно в таких единицах. Практика показывает, что члены команды могут давать оценку в размерах даже для задач, в которых они не являются специалистами-исполнителями, обучаясь на предыдущем опыте работы.

Опишем процедуру оценки, для этого используется planning poker: после представления задачи члены команды выкладывают карточки с оценками, а потом одновременно их переворачивают. При больших расхождениях идет обсуждение, обычно это означает, что разные члены команды поняли задачу сильно по-разному, что и выясняется в обсуждении. Потом следует повторное голосование.

На планировании вполне вероятной является ситуация, когда оценка задачи получается слишком дорогой для ее ценности. Тогда следует такт обсуждения с Product Owner, который на планировании представляет интересы стейкхолдеров. Во-первых, бывает, что у стейкхолдеров есть на этот случае План-Б, и задачу просто не нужно делать. Во-вторых, возможно, команда может предложить какое-то более легкое решение для реализации, которое удовлетворит основные потребности – правило Парето говорит, что чаще всего это возможно. Это – конструктивное обсуждение.

А вот переход в этом случае к различным способам давления чаще всего не имеет смысла. Потому что наиболее распространенный результат – команда соглашается, а потом просто не делает. И в результате вместо четкого представления о том, что какой-либо функционал не будет получен через две недели, стейкхолдеров обнаруживают это постфактум, две недели спустя, когда они рассчитывали его получить. Не обязательно тот, по поводу которого было давление – может оказаться, что его сделали, но не сделали что-то другое. А если не сделали именно его – то на него при этом уже затрачены определенные ресурсы, и далее надо доделывать или выбросить. Конечно, может оказаться, что сознательная команды сделает этот функционал за счет личного времени. Но, как показывает практика, на это может сработать один-два раза, а вот на регулярной основе это приводит к негативным последствиям: либо команда выгорает и производительность падает, а сотрудники уходят, либо команда начинает систематически завышать оценки, чтобы было, куда отступать при давлении. В любом случае, прозрачность процесса и сотрудничество в достижении цели – разрушается, что разрушает эффект использования Agile-подходов.

Планирование – контракт на спринт.

Вообще надо отметить, что планирование представляет собой заключение контракта на спринт между командой и стейкхолдерами, при этом интересы стейкхолдеров представляет Product Owner. Этот контракт может иметь разную жесткость. В свое время была популярной идея о том, что «настоящая команда» на планировании всегда дает обещание, commitment, которое потом выполняет почти любой ценой. Такой взгляд очень нравится стейкхолдерам и, на первый взгляд, отвечает их интересам. Однако, практика показывает, что это неверно. В долгую это ведет к выгоранию команды либо к сознательному завышению оценок, в котором еще и не сознаются, тратя выигранное время по своему усмотрению и превращая работу в agile- курорт. И этому есть системная причина – длинный хвост распределения в оценках IT-работы, о чем есть хороший доклад Андрея Бибичева « Пуассоново горение сроков».