Вся жизнь IT-команды в одной статье.

Последние полгода у меня зрела мысль поделиться накопленным опытом нашей ИТ-команды, но подходящего повода не находилось, пока я не попал на мероприятие по «практикам прозрачных процессов». Там я снова услышал знакомую проблему — одни и те же абстрактные ответы без примеров и конкретных решений на вопросы коллег. Хотя я всего лишь рядовой участник воркшопов, а не спикер, регулярно замечаю эту тенденцию.

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

Статья подойдёт:

• Новичкам в IT — тем, кто только начинает разбираться в Agile и хочет увидеть реальные процессы «изнутри».

• Коллегам из других сфер — если ваш опыт работы отличается, здесь вы найдёте конкретные примеры и, возможно, идеи для своих проектов.

• Критикам и экспертам — если вы замечаете спорные моменты или хотите поделиться альтернативным подходом, добро пожаловать в комментарии!

• Моей команде — как напоминание о наших договорённостях и повод для дальнейшего улучшения процессов.

Это моя первая статья поэтому я буду рад вашим комментариям и ценным советам.

Пара слов о команде

У нас мультифункциональная команда которая разрабатывает фронтовое Web приложение, в состав её входят: .NET backend (middle) разработчик, JS frontend (front) разработчик, system analyst (SA), quality assurance tester(QA), designer.

Вы спросите: «middle, это грейд разработчика?». Нет мы фронтовая система и middle — это наш разрабатываемый backend, поскольку за ним ещё череда систем, так принято называть.

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

Отдельно стоит сказать про Product Owner (PO). Формально эта роль не входит в IT-команду, но мы хорошо понимаем, что именно на PO лежат ключевые задачи:

• Точка входа любых задач в команду.

• Постановка требований от бизнеса.

• Управление ресурсами и приоритетами.

• Календарное планирование.

• Защита команды от внешних помех.

Такое сочетание компетенций и ответственности обеспечивает стабильность, помогая команде надежно закрывать новые бизнес-потребности.

Теперь перейдём к делу.

Спринты и командные встречи

Мы работаем по Scrum с 10-дневными спринтами. У нас нестандартное расписание:

• Старт: среда, в 13:00.

• Завершение: среда, 12:00 через неделю.

Вы спросите: «Куда исчезает 1 час?». Расскажу об этом интересном нюансе позже!

По факту у нас не так много регулярных встреч для синхронизации команды: 

• daily scrum meeting (дейли);

• product backlog refinement (PBR); 

• demo (обзор спринта);

• retrospective (ретроспектива);

• sprint planning (планнинг);

• встречи по компетенциям команды.

Дейли

Ежедневная встреча для обсуждения задач спринта (кроме дней старта и завершения).

Время выбрано не случайно. Начинаем в 11:00 — когда-то в команде шутили: «Влад раньше не просыпается», но это время оказалось идеальным:

• Успеваем доделать задачи, перенесённые с прошлого дня.

• К этому времени у всех уже есть 2-3 часа активной работы — обсуждение получается содержательным.

• Комфортный ритм без утренней спешки.

Как у нас проходит дейли?

Сама встреча короткая — от 5 до 15 минут. Мы специально сделали её не как допрос, а как краткое обсуждение задач. Так получается живее и полезнее.

Что помогает:

• Бот напоминает — никто не забывает.

• Ведущий меняется — все вовлечены.

• Короткий формат — только по делу.

• Обсуждение вместо отчётов — работаем как команда.

Как мы обсуждаем задачи на дейлике? 

Задаем всего три ключевых вопроса:

№1. «Какой статус по задаче?». Если изменился, сразу обновляем в Jira.

№2. «Какие проблемы возникли?» (в разработке, тестировании или выкатке). Если есть блокировки, ставим в Jira: флаг (1) «Блокер» и комментарий (2) с причиной.

Потом всё это видно в задаче (1) и в статистике (2) спринта.

№3. «Успеваем ли по срокам?». Если есть риски, всей командой ищем решение.

Что это дает:

• Прозрачность: вся команда и PO видят реальную картину.

• Поддержка: каждый знает, кто над чем работает и может предложить помощь.

• Контроль: в Jira сохраняется полная история по каждой задаче, полный контроль.

Вы спросите: «Что делать, если нужно больше времени на обсуждение?» Но ведь такое случается не всегда. В таком случае просим остаться нужных участников после встречи или же собираем отдельную встречу в удобное время для всех. Отделяем «мух от котлет».

Обзор спринта

Раньше мы проводили демонстрации в конце каждого спринта, показывая все изменения по всему клиентскому пути(кп). Это требовало значительных усилий по подготовке, а иногда мы демонстрировали решения, которые еще требовали доработки. Основная сложность заключалась в том, что такие встречи происходили слишком часто — каждые 10 дней, содержали много повторяющейся информации и ключевые стейкхолдеры не всегда могли присутствовать на каждой из них.

Со временем перешли на более эффективный формат — ежемесячные обзоры.

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

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

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

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

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

PBR

Раньше мы, как и многие в Scrum-сообществе, называли эту встречу привычным термином «Grooming» (от англ. «причесывание» бэклога). Но со временем от этого названия пришлось отказаться — оно казалось слишком неформальным и могло вызывать неоднозначные ассоциации.

Теперь используем более точное и профессиональное название — Product Backlog Refinement (PBR), а суть осталась прежней:

• Уточняем и детализируем задачи.

• Оцениваем сложность.

• Готовим бэклог к планированию.

Почему такой формат работает?

• Регулярность — не копим неразобранные задачи.

• Удобное время — к концу дня уже есть понимание текущего контекста.

• Гибкость — если в один день не успели проработать всё, используем второй слот.

Мы сознательно не делаем наши 1.5-часовые слоты в понедельник и четверг жестко обязательными. Это скорее зарезервированное время «на случай», чем строгое правило.

Вот как это работает на практике:

• О предстоящей встрече мы объявляем на дейлике, после чего публикуем задачу в отдельном канале, чтобы участники могли заранее с ней ознакомиться.

• Если задач для уточнения нет — просто отменяем встречу.

• Если появляется срочный вопрос (критичный баг или горячая бизнес-задача) — любой из участников может предложить «Давайте используем ближайший слот для его обсуждения».

• Когда накапливается много задач — проводим обе запланированные сессии. 

• Зовем на встречу только коллег с нужными компетенциями по задаче — остальные не тратят время впустую.

• Декомпозируем задачи на части, которые можно взять в спринт — сокращаем время при планирование.

• Задача не делятся по компетенциям, проводим оценку в стори поинтах (1, 2, 3, 5, 8 ... sp) — оцениваем сложность всей задачи (разработка, тестирование, документация, деплой).

Главное преимущество такого подхода в том, что есть гарантированные «окна» для обсуждений, когда они нужны, а принудительных встреч ради встреч нет. Так сохраняется возможность оперативно реагировать на срочные вопросы.

Инструменты PBR

• Poker для оценки задач: мы используем open source инструмент для онлайн-голосования.

• Декомпозиция задачи: для создания подзадач мы используем формат таблицы Excel, который переносится в дальнейшем в Jira задачу.

• Эталонные задачи — то, что мы не раз уже делали и знаем условия их разработки/доработок.

Вы спросите: «Почему не используете плагин Jira?» Потому что на PBR у нас еще нет задач в таск трекере. Создание задач происходит после встречи, чтобы не тратить время.

Три формата PBR в нашей команде:

• Предварительная оценка. PO приносит задачу для грубой оценки. Эти данные используются для квартального планирования.

• Готовим задачу к разработке. После Spike (аналитика/разработчика) у нас есть: четкие требования; алгоритм для разработки; доступы; дизайны. Теперь задачу можно оценить и распределить на планировании.

• Чистка бэклога. Обычно проводим в четверг после старта спринта: проверяем актуальность задач/багов, а при необходимости тестируем на стендах и решаем, оставить с приоритетом или закрыть

Каждый формат решает свою задачу без лишних встреч.

Вы спросите: «Что такое Spike?» Это задача на исследования: задача на аналитика, как подключить новую интеграцию; задача на разработчика, как перевести проект на Kubernetes; как подключить авто-кодревью; и тп.

Ретроспектива

Наше «неформальное» рабочее общение.

Мы работаем удалённо из разных городов и все наши встречи — строго о работе. Ретро — исключение. Это время, когда мы разбираем «неудобные» вопросы, но без обвинений, а с поиском решений:

• «Почему дизайнер и фронтенд не договорились?»

• «Зачем аналитик снова меняет требования?»

• «Почему тестирование затянулось?»

• «Почему тестовый стенд не работает и как с этим бороться?»

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

• «Кем бы вы были в мире животных?».

• Составь своего персонажа из частей.

• Мини-игры «Найди 5 отличий» в скриншотах интерфейса.

• Угадай фильм по изображению.

• «Немного обо мне» — знакомимся.

• Просто смешные мемы про разработку.

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

• Какие проблемы есть в проекте.

• Какие технические практики или инструменты можно внедрить.

• Выносим рабочие договоренности на обсуждение: DOR, DOD, командные чаты, внедрение ботов, резервирование слотов.

• Кто кому помог в спринте.

• Какие маленькие победы были.

• Где мы стали лучше, чем в прошлый раз.

• Да просто говорим «Спасибо!" и шутим.

• Проводим воркшопы.

Вы спросите: «Что такое DOR и DOD?» DOR (Definition of Ready) — это критерии, которым должна соответствовать задача, чтобы команда могла взять её в работу в спринте. DOD (Definition of Done) — это наш чек-лист критериев завершенности задачи. Только когда все пункты выполнены, задача считается действительно готовой.

Используем формат:

• наш стандартный шаблон ретро-техник;

• шаблоны от DariAgile.

Планнинг

Тот самый «час» из начала статьи.

Данная встреча состоит из нескольких этапов.

Первый этап — закрытие спринта. 

Мы проходим по доске текущего спринта, финализируем статусы задач и решаем их судьбу: закрываем или переносим в следующий спринт. При закрытии задач мы следуем нашему DOD (чек-листу завершенность проекта).

Да мы «не красим траву». Если задача не выполнена — переносим её в следующий спринт.

В последний день спринта бот присылает два важных сообщения. В 9:00 бот отправляет опрос: «Сегодня последний день спринта, оцените как он прошел (1-10)». Результат удовлетворенности в дальнейшем используется при закрытии спринта.

Второе сообщение в 12:00 — напоминание о времени встречи для закрытия спринта.

После закрытия спринта мы смотрим на три вещи: как команда оценила спринт (по шкале 1-10), какие задачи «переехали» в следующий и сколько процентов работы выполнили. Это помогает сразу увидеть результат закрытия спринта, эти критерии мы можем обсудить на ретроспективе.

Второй этап — распределение задач.

Для этого у нас есть специальная доска в Excel Sprint Backlog. Да, это примитивная таблица Excel и она проста, понятна и работает.

Процесс следующий:

• Выбираем задачи по приоритету сверху вниз, у которых есть оценка и заполнены все DOR (критерии попадания задачи в спринт).

• Смотрим на какие подзадачи распределены и какие компетенции участвуют.

• Проверяем загруженность коллег по направлениям и наличие отпусков.

• Резервируем дни загруженности по каждой подзадаче в разрезе компетенций.

• Планируем ИТ и deploy.

Так делаем по каждой из задач, пока все слоты у специалистов не будут заняты.

Приоритет по задачам предварительно выстраивает PO — важные/срочные вверху.

Если же бэклог не полностью покрывает загруженность команды, тогда берем тех.цели/баги для этого у нас есть отдельно сгруппированные списки. Если и этого не хватает, или мы знаем, что планируется еще задача, тогда оставляем свободные слоты и после очередного PBR также распределим по исполнителям.

Завершаем встречу — старт нового спринта. 

Мастер названий Антон придумывает очередное название спринта («мы не всегда понимаем причины, почему у спринта такое название») — так получается. PO озвучивает ключевой результат и фиксируем 2-3 цели спринта, жмем START.

Но есть правило. Начиная со среды первой недели спринта (6 день) мы не «вкидываем» в работу задачи сложнее 5 sp. А в последние два дня спринта и вовсе избегаем новых задач. Это ограничение — результат нашего общего решения, принятого на ретроспективе.

Благодаря регулярным PBR на планнинг мы тратим не больше часа, не обсуждаем задачи, смотрим сложность и согласно оценки примерно резервируем время на решение задач(и).

На этом можно было бы и закончить.

Немного подробнее об инструментах

Наши чаты.

Мы договорились вести командные чаты по проблематике, вот такой у нас список:

• Front — тут «фронтендеры» согласуют PR по своим задачам, обсуждают проблемы проекта, оповещают об общих созвонах.

• Test — тут происходит тестирование задач, обсуждение дефектов с Пром среды, обсуждение стандартов QA, регулярные встречи тестировщиков.

• Deploy — тут есть следующая договоренность «После того как тестировщик или тестировщица даёт добро на мёрж в мастер пишем сообщение в формате: Название задачи, cсылка, тэги причастных людей. Далее всё общение по данной раскатке происходит в ТРЕДЕ. После того как заявка на раскатку заведена, оборачиваем сообщение реакциями.» Пример.

• Analytics — тут территория аналитиков, постоянные вопросы про стандарты документации/архитектуры, согласование PR doc as code, регулярные встречи, запросы от PO.

• Design — в этом чате QA создают треды для дизайн-ревью, аналитики совместно с PO обсуждают особенности реализации и клиентские пути, делятся ссылками на макеты.

• PBR — в данном чате мы указываем дату, даем ссылку на задачу в confluence и запрос компетенций на встречу.

• Technical-team — обсуждение технических вопросов по всем компетенциям, не работает приложение, как проверить работу клиентского пути и тп.

• Шашлычная/Кальянная — шуточное название онлайн-переговорок, зарезервированные комнаты для созвонов. Т.е. есть вопрос обсуждения «на троих» и более, говорим «пойдем в Шашлычную».

• Обеды — чат для оповещения, что будешь отсутствовать, отошел на обед.

DOR и DOD подробнее:

Вы спросите: «А что такое трифт?» Thrift — это фреймворк для кросс-языкового формата контракта API(удалённого вызова серверных процедур), разработанный в Facebook (сейчас Meta) и позже переданный в open source. Т.е. версия контракта написанного в middle сервисе, совпадает с ожидаемым контрактом на front.

Моя доска КСМ.

Это рабочая панель «как у летчиков», где видны все активности и метрики.

Я создал эту доску для своего удобства — она помогает мне быстро отвечать на частые вопросы команды: что уже готово к выкатке, сколько задач завершено в текущем спринте, есть ли пересечения в выкатках, какие есть блокеры и что требует особого внимания.

• Фильтры по задачам — важные списки deploy/баги/уязвимости.

• Диаграмма поставок — количество поставок(задач) на Пром (зеленые выкачены, красные готовятся).

• Диаграмма сгорания — выполнение задач в спринте.

• Осталось дней — количество оставшихся дней до завершения спринта.

• Диаграммы по предыдущим спринтам — для сравнения видна общая картина.

• Прогресс спринта — процент выполнения, оставшийся процент, процент "вбросов" задач.

КСМ - Командный Скрам-мастер. Участник команды, который берет часть функций Скрам-мастера, совмещая роль КСМ с ролью бизнес-эксперта или разработчика, аналитика, тестировщика. КСМ проводит стандартные командные события, организует улучшение работы команды в рамках типовых процессов и  контролирует соблюдение правил работы в Jira, выделяя на это 10-15% рабочего времени.

Эволюция, а не революция

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

В завершение — огромное спасибо моей команде за то, что мы всегда на одной волне. Без вашей гибкости, открытости к экспериментам и способности находить баланс между правилами и здравым смыслом — ничего из описанного не работало бы.

Хотите глубже разобрать какое-то конкретное правило или узнать историю, как оно появилось? Приходите в комментарии...

Читайте также материал, который моя статья дополняет:

Онбординг здорового дизайнера: шаблон для интеграции новичка в продукт

Всем привет! На связи Гузель — дизайнер цифровых продуктов в Альфа-Банке. В одной компании я была св...

habr.com