Введение
Мы — команда Platform в Playrix, и мы предоставляем серверную инфраструктуру, CI/CD и сервисы автоматизации. Платформа состоит из трёх мини-команд, две из которых являются операционными. В этой статье я хочу рассказать, как мы победили хаос в этих командах и сделали их работу прозрачнее, эффективнее и спокойнее. Мы прошли непростой путь, но сейчас довольны (почти) результатом и готовы про него рассказать.
Проблема и её решение
Глава 1. Зарождение хаоса
Многие из нас проходили через это. Небольшая команда, небольшое количество сервисов, понятный бэклог, скромный поток входящих запросов. Всё решается быстро и оперативно, все друг друга знают. Но вот компания растёт, появляется один сервис, потом другой. Запросов становится всё больше, начинает появляться техдолг. В какой-то момент становится невозможно за всем уследить, только взял одну задачу, как требуют внимания в двух других. Плывут сроки, начинает складывается ощущение, что везде пожар.Так начался наш путь.
Проблемы:
Большое количество задач, сложно ими управлять, размывается фокус внимания, невозможно планировать.
Решение:
А давайте назначим тимлида? Пускай он и занимается планированием, распределением задач и общением с заказчиком.
Глава 2. Первая кровь
Разумеется, появление тимлида положительно сказывается на команде. Он замыкает на себя общение, приоритезирует задачи, организует планирование. К тому моменту в команде естественным путём возникла разновидность Kanban. Как только инженер доделывал текущую задачу, он брал следующую по критичности и делал её. И вот тут стала очевидна следующая проблема: невозможность планирования.Хаос был доволен.
Проблемы:
- Невозможно было ответить на вопрос «Когда?». Заранее было неизвестно, какие задачи появятся и вытеснят текущие, поэтому сроки постоянно смещались. На тот момент команду и заказчиков устроил бы горизонт планирования хотя бы на неделю.
- Невозможно было эффективно делать крупные стратегические задачи. Не хватало фокусировки.
Решение:
А давайте применим Scrum? Будем фиксировать набор задач на короткий спринт. Всё некритичное будем откладывать на следующий спринт, а критичное будем как-то делать минимально, только если очень надо. Крупные задачи будем декомпозировать и брать понемногу в каждый спринт.
Глава 3. Хаос наносит ответный удар
Как и с тимлидом, изменение улучшило жизнь команды и заказчиков на какое-то время. Инженеры выдохнули, у них был понятный план на неделю. Все счастливы, хаос повержен, расходимся.Не так быстро.
Проблема:
К тому моменту команда уже была достаточно крупной и в оперировании был один большой сервис (на 600+ человек) и множество мелких. Все они генерировали запросы (иногда очень срочные) и инциденты. Очевидно, эти штуки нельзя было откладывать до следующего спринта. В итоге инженеры не успевали закрывать свои задачи по спринту. Опять срыв сроков.
Решение:
Давайте заложим процент от времени на всякие инциденты и запросы для каждого инженера в спринт. Это поможет и время выделить, и планировать точнее.
Глава 4. Удар ниже пояса
Решение с выделением фиксированного времени было очень плохим. Оказалось, что процент в разные спринты разный на разных людей. Бывали такие ситуации, что один человек дико перегружен, а другой в это время ничего не делает. Как результат — срыв сроков и демотивация команды.Это был конец. Казалось, что пора возвращаться в Kanban.
Проблема:
Было непонятно, как сделать так, чтобы команда могла не отвлекаться от спринта с одной стороны, но при этом оперативно реагировать на изменяющуюся ситуацию с другой. Для нас это был неразрешимый парадокс на тот момент.
Финальное решение:
И тогда мы решили модифицировать наш Scrum, добавив в него новую роль — дежурного. Мы решили включить в его обязанности следующее (по уменьшению приоритета):
- оперативное разрешение инцидентов;
- реакцию на входящие запросы;
- техническое обслуживание и сопровождение сервисов;
- исследование новых технологий и решений на своё усмотрение.
Глава 5. Новый рассвет
Ситуация стабилизировалась. Спринты стали более прогнозируемые, крупные задачи стали двигаться, у заказчиков появилось понимание, когда будут сделаны их запросы, инциденты стали разрешаться оперативно. Параллельно мы работали над системой стратегического планирования, что позволило значительно расширить горизонт планирования (но об этом в отдельной статье).Остаётся только добить поверженного врага.
Плюсы и минусы
Как и у всякого решения, наша идея с дежурными обладает как плюсами, так и минусами:Плюсы
- Повышается предсказуемость. Если команда не отвлекается, то результат прогнозируется лучше. Пускай команда делает меньше, зато надёжней, прозрачней и предсказуемей.
- Повышается качество разработки. Все на своей шкуре испытывают последствия некачественного кода, ибо дежурным приходится всё это разгребать. Очень неприятно, когда из-за твоей небрежности кто-то будет страдать на дежурстве.
- Снижается bus factor. Когда все немного знают про всё, то, в случае форс-мажора, вы сможете закрыть задачи другими людьми, поскольку они уже в курсе.
- Улучшается обмен знаниями. В процессе дежурный неизбежно знакомится со всеми сервисами и инструментами. Лучше погружается в архитектуру и кодовую базу.
- Team building. Это уравнивает всех в команде, каждый чувствует участие в результатах и успехе команды.
- SLA. Появляется возможность определить SLA и быть уверенным, что вы его не нарушите.
- Новые технологии. По сути, у дежурного появляется «законное» время на изучение новых технологий.
Минусы
- Обучение. Необходимо понимать, как работают все сервисы в команде. Изучение занимает какое-то время, поэтому новичкам будет несладко.
- Уменьшение velocity. Ребята на дежурстве НЕ занимаются задачами со спринта. Формально это снижает мощность команды.
- Различные типы задач. Очень плохо работает, если у вас разные типы задач (оперирование, программирование, аналитика). Дежурный просто не сможет их обрабатывать сам.
- Маленькие/большие команды. Плохо работает для небольших команд из 2-3 человек. Они слишком проседают по велосити, дежурства слишком частые. Неизвестно, как это работает в больших (больше 7 человек), мы не проверяли. Подробнее про оптимальный размер команд мы поговорим ниже.
Топология команды
Количество дежурных
Как определить, сколько вам нужно дежурных? Разбиваем задачи на 5 типов:
- Запросы.
- Инциденты.
- Фичи.
- Рефакторинг.
- Исследования.
Запросы — 15% времени, инциденты — 5% времени, фичи — 60% времени, рефакторинг — 10% времени, исследования — 10% времени. Запросы + инциденты = 20%, значит, вам нужен 1 дежурный.
Мы не рекомендуем делать много дежурных. Если у вас их получается больше 3, то стоит подумать про выделение первой линии для вашей команды либо вынесение части текущей команды в отдельную команду разработчиков.
Размер команды
Есть два условия, при которых схема работает проверенно хорошо:
- размер команды 4-8 человек,
- дежурных 1-3 человека.
Ротация дежурных
В наших командах ротация происходит раз в неделю и не зависит от размера команды и длительности спринта. Для дежурных мы планируем нагрузку с учётом того, что часть спринта они дежурят и не участвуют в нём.
Вопросы и ответы
Во время нашего пути мы часто задавали сами себе вопросы, чтобы найти оптимальное решение.Почему дежурных не вынести в отдельную команду?
Можно попробовать. Условия, при которых это разумно, мы описали в пункте «Размер команды». Однако, если это возможно, лучше, чтобы команда чувствовала ответственность за свои решения. Иначе получится линия противостояния у двух команд: «ЪУЪ, эти опять наговнокодили, а нам разгребать» и «ЪУЪ, эти саппорты тупые и не могут разобраться». Здесь же единый центр ответственности — команда.
Почему этим не может заниматься техлид или тимлид?
Может (и даже занимался у нас какое-то время). Но время реакции и bus-factor у такого решения сильно хуже. Плюс время работы тимлида, как правило, дороже, и его всегда не хватает.
Почему нельзя чередовать технический и фичевый спринт?
Можно. Но у нас не получилось, так как мы не смогли гарантированно предсказывать отсутствие внезапных запросов или инцидентов.
Что делать, если дежурный не может устранить инцидент?
У нас есть определённая процедура работы с инцидентами. Основная цель — вернуть сервис на тот уровень, на котором он был. Если это не удаётся, то, к сожалению, его необходимо эскалировать до команды и/или лида. Таких инцидентов должно быть минимальное количество. Если это не так, значит, дежурный не готов дежурить.
Что делать, если инцидентов нет?
Дежурный продолжает разбирать входящие запросы, сокращая бэклог. Если входящих запросов нет, то занимается обслуживанием сервисов (анализ дашбордов, поиск проблемных мест). Если и тут всё готово, то может поизучать что-то новое и поделиться результатами с командой.
Почему нельзя брать задачу из спринта?
Можно. Но лучше этого не делать, так как если через 5 минут прилетит запрос или инцидент, то задачу придётся бросить на полпути. И не факт, что появится возможность её закончить. Также постоянное переключение на внешние факторы будет снижать качество выполнения.
Заключение
После внедрения таких дежурств нам стало жить проще. Мы точнее планируем, оперативнее реагируем на запросы, спокойно ходим в отпуска и на больничные.
У нас есть ещё про что рассказать. Например:
- Как мы проводим планирование спринтов, как оцениваем задачи, как оцениваем результаты.
- Как мы организуем высокоуровневое планирование и собираем потребности с заказчиков.
- Как мы применяем OKR и в чём отличие с SLA и KPI.
- Какие роли ещё есть в команде и как у нас организовано карьерное развитие.
- Как организован процесс дежурств в разных командах и почему именно так.
Спасибо за внимание!
Путь от хаоса к порядку. Как справляться с инцидентами и успевать достигать цели? Делимся опытом
Введение Мы — команда Platform в Playrix , и мы предоставляем серверную инфраструктуру, CI/CD и сервисы автоматизации. Платформа состоит из трёх мини-команд, две из которых являются операционными. В...
habr.com