Один из наших клиентов, руководитель QA-направления в крупной компании, задал нам вопрос:
— Я никогда не слышал, чтобы кто-то говорил: «Мы работаем по Scrum, и у нас всё спокойно». Можно ли постоянно работать в таком ритме, и не выгорать от постоянных дедлайнов? Да, это может быть эффективно и приносить пользу продукту, — но это очень тяжело для самой команды.
Вряд ли кто-то назовёт Agile спокойным, уже само слово «спринт» говорит о высоком темпе и интенсивной работе. В Scrum самоорганизующаяся команда вместе с продакт-оунером сама ставит себе цель, бежит и достигает эту цель. Затем, в начале следующего спринта ставит другую цель, снова бежит, достигает её, и смотрит на результат. Да, это не спокойно, но это не значит, что команда должна работать в стрессе.
Два способа, как относиться к дедлайнам
Чтобы не выгореть в таком ритме, важно понимать, что если к высокой скорости добавить ещё и стресс, то команда долго не продержится. А в Scrum важно держать темп на длинной дистанции. Да, дедлайны будут всегда, но есть два способа, как к ним относиться.
Например, Project manager приходит 15-го числа и говорит:
— Эти фичи надо сделать к концу месяца.
Реакция команды:
— К концу месяца? Успеть нереально. Вот если бы мы раньше знали о сроке..
Ответ от менеджера:
— Вы должны успеть, я уже пообещал заказчику.
Здесь команда просто принимает дедлайн как данность, и в панике срочно начинает делать задачу. Но в Agile мы всё-таки стремимся относиться к дедлайнам чуть иначе — как к ориентиру, про который сначала хочется узнать, откуда он взялся. Потому что дедлайн — это просто дата, которую кто-то когда-то назвал. И важно понять, почему она именно такая.
В Scrum команды стараются делать так, чтобы даже если дедлайн и появился, его поставила сама команда. Например, когда к продакт-оунеру приходит заказчик и говорит, что срочно нужна сборка, продакт-оунер ничего не будет обещать, а сначала уточнит: «А насколько срочно? Почему именно сейчас? Что именно должно в неё войти?» — и соберёт контекст.
Допустим, осталось доделать ещё 5 фичей. Продакт-оунер собирает всех на уточнение бэклога и говорит: «Нужно сделать 5 фичей к такой-то дате». Он объясняет, зачем это нужно и почему именно к такому сроку. Вся команда смотрит на объём работы и оценивает, реально ли успеть — и если да, то когда. Или, например, команда видит, что на эти фичи уйдёт два месяца, а не две недели. И тогда честно отвечает, что за такой срок не получится уложиться.
Что делать, если команда не укладывается в срок
Конечно, сказать «мы не успеваем» — это не самый продуктивный подход. Поэтому команда задаёт себе другой вопрос:
— Если 5 фичей не получится реализовать в том объеме, в котором они сейчас описаны, то что мы, как команда, можем успеть к концу месяца, чтобы максимально закрыть исходный запрос наших заказчиков?
И после этого все вместе выбирают, на чём сосредоточиться в первую очередь, а что можно пока не делать. Иногда, чтобы уложиться в срок, совсем не обязательно сразу выпускать полностью готовое решение.
В Agile никто не может просто прийти и заставить самоорганизованную команду выполнить конкретный объём к нужной дате — если только это не дата, которую согласовала сама команда. Потому что только они знают, сколько времени это займёт.
И если вдруг так случилось, что дату никак нельзя сдвинуть, то команда не старается уместить весь запланированный объём в игольное ушко, а просто задаёт себе вопрос:
— А что мы реально можем успеть к этому сроку и при этом дать максимум пользы?
Все, как и раньше, стараются успеть сделать то, что запланировали на спринт. Но при этом их никто не отрывает от работы посреди недели и не меняет приоритеты. Срочные дедлайны не обрушиваются на команду каждый день — за этим следят Владелец продукта и Скрам-мастер.
У вас тоже часто сдвигаются сроки и меняются приоритеты?
Поможем наладить процесс планирования и оценки сроков, чтобы работа завершалась в срок и заказчики были довольны.
