x
Что делать, если выбыл разработчик в середине спринта или релиза
08-17-2023 12:21
Спланировали двухнедельный спринт, бизнес уже получил сроки по всем задам и остался ими вполне доволен, команда начала разработку. День делали, два делали и все прекрасно успевали и даже уходили вовремя домой. Тем временем, на город опустилась чума эпидемия гриппа. Сначала разработчики держались стойко, кое-кто даже повесил на шею чеснок (он конечно же помог). На четвертый день спринта, послышался первый кашель. На пятый кашляющего изолировали и заперли дома с температурой, но урон спринту был уже нанесен. Над командой начали сгущаться тучи.
С подобной ситуацией сталкивалась каждая команда. Как бы мы хорошо и правильно не планировали, форс-мажорные ситуации случаются, и иногда что-то изменить мы не в состоянии. Как минимизировать ущерб текущей работе и сохранить лицо команды в лучшем свете? Сейчас разберем алгоритм.
Что нужно подготовить заранее
Во-первых, если к беде не готовиться, то она обязательно застанет тебя врасплох. Поэтому, если вы не хотите в случае форс-мажора упасть в грязь лицом, то совершите некоторые приготовления. Самое важное, что вам нужно получить от бизнеса, по какому бы фреймворку вы не работали, это приоритеты. Мы никогда не устанем говорить о важности приоритетов. Именно они помогут команде при любых изменениях быстро сориентироваться и выдать лучшее, что они могут.
А можно просто работать по ночам и все затащить?
Вы можете задать законный вопрос: а почему бы просто не компенсировать выбывшего человека переработками? Вы вполне можете это сделать, особенно если у вас нет личной жизни и вы не планируете ее заводить. Но что делать, если выбыл не один человек, а два, а три? Все сильно зависит от команды и от плотности набранных задач. Но можно со всей уверенностью сказать, что рано или поздно ночные бдения вам не помогут.
Что делаем вместо бессонных ночей
Итак рассмотрим алгоритм, по которому надо действовать в таких ситуациях.
- Первое, что вам нужно сделать, это посмотреть на приоритеты своих задач в спринте;
- Посмотрите на цель своего спринта, проверьте не страдает ли она из-за того, что выбыл разработчик;
- Определить какие задачи были на выбывшем человеке, их приоритеты и их статус;
- Если разработчик работал над целью спринта или высокоприоритетными задачами, то необходимо перераспределить работу между оставшимися разработчиками таким образом, чтобы без исполнителя остались самые низко-приоритетные задачи. Соответственно, если выбывший уже работал над самыми низкоприоритетными задачами, то все оставляете, как было;
- Обязательно оповестите своего владельца продукта и всех заинтересованных, о том, что выбыл человек, поэтому вместимость команды в этом спринте уменьшилась. Расскажите какие конкретно задачи из-за этого пострадали и не будут сделаны. Обязательно упомяните, что цель спринта не пострадала и все задачи с более высоким приоритетом будут готовы в срок.
Итак, самое важное, что нужно помнить: ваша главная задача не умереть на работе сделать все, что запланировано в спринте во что бы то ни стало, а донести до пользователя максимально возможную в имеющейся ситуации ценность.
Если хотите легко разруливать такие ситуации, все необходимое вы найдете в нашей книге "Гибкие методологии на практике". Там мы подробно расписали и о целях спринта, и о приоритетах, и о вместимости команды, и о том, кто за что отвечает, чем важно донесение ценности и что это вообще такое, а главное, как работать с такими форс-мажорами. В общем, все, что необходимо любому участнику команды для ежедневной работы.
Если у вас остались вопросы, вы можете воспользоваться формой для связи или оставить комментарий ниже.
Комментарии
Чтобы оставить комментарий, пожалуйста, авторизуйтесь
Подписывайтесь на рассылку, участники первыми узнают о скидках
Последние статьи из нашего блога
ИП Шаламова Александра Сергеевна
ИНН 662007045961 / ОГРН 320774600352647
Телефон +7 (925) 219-07-88 Пн-Пт с 10:00 до 18:00 (Москва, UTC + 3)
Для связи: info@oros-it.ru
