Всем привет, меня зовут Алексей Федоров, я тимлид команды финансов в Ситимобил. В этой статье я хочу поделиться тем, как устроен процесс гибкой разработки в нашей команде.

Ситимобил — второй крупнейший агрегатор такси в России. За год мы выросли примерно в 10 раз и не собираемся сбавлять обороты. Такой быстрый рост накладывает некоторые ограничения: нам нужен очень короткий time-to-market (TTM), время от возникновения идеи до ее использования реальными клиентами должно быть как можно меньше. Из-за того что мы минимизируем TTM, мы не собираем релиз, а катим каждую задачу/фичу по отдельности. Также у такого подхода есть важный плюс — в случае проблем в проде сразу понятно, из-за какого изменения они возникли. Это позволяет сделать точечный откат задачи, а не всего релиза.

Почему не Скрам

В IT-индустрии уже несколько лет популярна методология Agile и ее разновидность Scrum (далее «Скрам»). Скрам пытаются так или иначе внедрить в каждой компании. И опыт внедрения у каждого свой, но, как правило, редко носит позитивный характер. Чаще наступает разочарование и откат к прежним процессам.

На мой взгляд основные проблемы скрама:

1. Фиксированные спринты.
   Редко получается закрыть спринт вовремя так, чтобы все было сделано. Как правило, остается какая-нибудь мелочь, которую недофиксили или недопроверили. Доработки переносятся на другой спринт, и чтобы успеть вовремя, команда берет меньше задач. Сбалансировать спринт по задачам, чтобы у всех была работа, сложно. Задачи RnD в целом плохо укладываются в фиксированные рамки. А главное, фиксированные спринты редко просит сам бизнес.
2. Разнообразные митинги.
   В скраме очень много активностей: ежедневные митинги, планирование и ретроспектива каждого спринта. Часто эти встречи проводятся для галочки и больше утомляют, чем приносят пользу.

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

Команда

В становлении процесса ключевую роль играет команда и ее устройство. У нас в команду входят разработчики и тимлид. Опционально PM, QA, аналитики, дизайнеры. Команда должна восприниматься единой боевой единицей. Это серый ящик, на входе которого требования, а на выходе — продукт. Внутренняя организация полностью отдается на откуп команде, и внутри себя она может работать по любому процессу, который ее устраивает.

Как у нас

Наша команда выбрала процесс сильно похожий на Kanban. У нас много источников задач: найденная службой поддержки бага, новые фичи от продуктов, технический долг, фича смежной команды и т.д. Не важно, откуда пришла задача, она должна быть оформлена в таск-трекере, желательно самим автором. Любая поступившая задача проходит через несколько обязательных статусов: «Новая», «В работу», «Выполняется», «Тестируется», «Готова к деплою».

Задачи движутся слева направо на доске, редко возвращаясь назад. Приоритет распространяется сверху вниз и справа налево. Для примера, выкатить задачу в прод приоритетнее, чем тестировать, а тестирование приоритетнее новой разработки. Колонка «В работу» по сути образует бэклог команды — приоритизированный линейный список задач на пару недель вперед. Как только разработчик разбирается со своей текущей задачей, он берет следующую сверху колонки.

Задачи заранее не закрепляются за конкретным разработчиком, этот подход позволяет балансировать выполнение задач, повышает общее знание кода всеми разработчиками, повышает bus-factor. Мы стараемся бороться с узкой специализацией внутри команды. Каждый член команды должен уметь сделать любую задачу из бэклога. Если разработчик взял задачу себе, то он полностью контролирует ее движение по доске вплоть до ее появления в проде. Он же проверяет, как задача ведет себя в реальных условиях.

Из встреч у нас есть ежедневные митинги, на этом митинге мы обсуждаем не только планы, проблемы и выполненные задачи, но также подходы к решению задач, предложения и вообще все, что волнует членов команды. Встреча редко занимает больше 30 минут для 4 человек. Ежемесячно мы проводим ретроспективу по скрам-образцу: что хорошего/плохого было, что мы с этим можем сделать, план повышения эффективности на следующий месяц. Выделенного планирования у нас нет, по необходимости устраиваем планирование, если начинаем разрабатывать крупную задачу.

Мы стараемся логировать время по каждой задаче, не менее 75% рабочего времени. Этим мы добиваемся двух целей:

1. Ищем и устраняем тайм-киллеров: задачи, которые были трудоемки, но не приносили ожидаемой выгоды.
2. Оцениваем задачи на основе уже сделанных, тем самым повышаем точность оценки.

Также у нас есть еженедельные дежурства: один из разработчиков отвечает на вопросы от второй линии поддержки, выискивает новые проблемы в логах/мониторинге, решает срочные задачи и делает то, что не укладывается в запланированный бэклог. Это позволяет остальным разработчикам больше концентрироваться на их задачах, не отвлекаясь в мессенджерах и т.п.

Итог

Описанный процесс с небольшими вариациями я применял в нескольких командах и компаниях. Он зарекомендовал себя как наиболее гибкий и прозрачный для всех.

Мы не останавливаемся на достигнутом, с каждой новой ретроспективой мы делаем процесс нашей работы все лучше и эффективнее. Каждый раз мы пересматриваем используемые практики. У нас нет «священных коров» — то, что работало раньше может перестать работать, а многие хорошие в теории идеи на практике себя показывают не лучшим образом. Мы отбрасываем их без сожаления.

Процесс постоянных улучшений — основа нашей команды.