Меня зовут Иван Башарин. Я руководитель Лаборатории AI и архитектор решений в компании «Электронная торговая площадка Газпромбанка». В статье я пройдусь по этапам процессов в команде разработки и на примерах покажу, как мы работаем над показателями команды и улучшением наших результатов.

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

Заказчики: они точно знают, чего хотят

Начну традиционно. С получения требования. Как и у всех, «необходимость» может поступить из любого источника: от внешнего заказчика, который придумал новую фичу; от devops`ов, которые нашли потребляющий 16 Гб оперативки на dev-стенде запуск unit-тестов; от ИБ, обнаруживших публичный demo-стенд; от самой команды разработки, где разработчик откопал «не самую оптимальную реализацию задачи».

 В большинстве случаев заказчик хочет сразу получать оценку («Когда будет?») и сложность («Долго делать?»). Раньше мы пытались давать приблизительную оценку, и, конечно, частенько не попадали. Заказчик оставался недоволен, команда выгорала, напряжение росло. Отказать в оценке было невозможно, а проводить глобальный анализ любой стори слишком накладно. И мы на запросы клиента стали отвечать «четырехзарядным револьвером»: задача в нашем представлении может занять «дни», «недели», «месяцы», «Давайте не будем этого делать вообще».

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

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

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

Аналитики: они знают, как надо

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

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

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

Устав от количества ошибок, мы внедрили самый точный процесс оценки задач: полная вычитка и обсуждение задачи всей командой (ведь необходимо оценить время реализации, а также время тестирования и релизные сроки), отдельные статусы в трекере, оценка «револьвером», дооценка и «сглаживание пиков» в случае расхождения.

Уже на этом этапе мы получили приемлемую точность оценки (до 98% задач в спринте попадали в оценку), но это был настолько длительный процесс, что задачи стали выключаться из него. Получалось долго и дорого — стало проще не попасть в срок, чем тратить время команды на очередную небольшую задачу.

Затем, оценив потери времени и количество типовых оценок группами (большинство оценок попадали в определенные показатели), мы попробовали «маечную» оценку на основе Story Points.

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

И такой чередой итераций из ошибок мы пришли к итоговому процессу оценки любой задачи:

• первично для заказчика задача оценивается «четырехзарядным револьвером»;

• после оцениваем сложность, без сроков реализации. Например, группе аналитики необходимо проверить всю документацию проекта в Confluence и поменять название типа документов «Заявка» на «Договор». Задача в реализации длительная, однако совершенно несложная (S). И напротив, группе разработки необходимо написать миграцию, меняющую данные документов по сложному условию и с несколькими наборами данных, — задача в реализации краткая, но сложная функционально (M);

• в зависимости от сложности задачи меняем дальнейший процесс оценки. Задача уровня S (самая технически простая) не оценивается по срокам, так как чаще всего процесс оценки занимает больше времени, чем сама реализация. Задача уровня М и выше обязательно проходит через этапы общей вычитки и «револьверной» оценки. Задачи уровня XL и выше обязательно декпомпозируются до уровня М и вычитываются отдельно.

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

Разработка: они знают, как будет

Разработка в нашей команде — основной драйвер изменений в процессах. Ей нравится оптимизировать неудобные процессы и тем самым облегчать себе жизнь. При этом мы не ограничиваем влияние на процессы ролью сотрудника. Например, идея одного из наших джуниор-разработчиков выросла в целый процесс планирования через диаграммы Ганта с горизонтом в 2+ недели. И она была доработана отдельными планами спринтов, сотрудников, отчетных периодов для заказчика.

Диаграмма Ганта нужна, чтобы показать:

• задачи, включенные в проект;

• их продолжительность;

• даты начала и окончания проекта;

• время, которое занимает каждая задача;

• исполнителей, работающих над задачами;

• способы объединения задач.

Также именно по запросам группы разработки мы добавили пять новых статусов для задач и неоднократно меняли шаблоны для заведения задач.

Тестирование: они точно знают, как оно должно быть

В нашем представлении группа тестирования — это хранители знаний проекта. История задач, корректность их выполнения, планирование вывода, документация — все этапы жизни задачи определяются группой QA. От них же поступают обновления процессов между командами одного проекта и обновления процессов CI/CD. Именно так из жалобы «Нам неудобно проверять все в одном дев-стенде» появились K8S и мультистенды. Из «Нужен удобный процесс мониторинга» — связь сентри, задачи, релизной сборки и логов отладки.

Группа управления: знают, что сделать еще

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

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

И второй — все остальные регламенты должны быть гибкими :)

И что в итоге?

Кто-то уже использует похожие подходы. А кто-то наверняка увидел в описанных процессах общие черты. Все приведенные мной примеры — это постмортем (иногда предупредительный), возведенный в абсолют.

Post-mortem в ИТ — это задокументированный отчет об инциденте, его последствиях, предпринятых действиях для минимизации или устранения причин, а также предотвращения повторения инцидента.

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

При работе с процессами используется тот же стек, что и при работе с задачами:

• для ведения инцидентов мы используем Youtrack с полями критичности и отдельной доской;

• для мониторинга в том же Youtrack организовали дашборды со статусами и алертами о сроках;

• для ведения записей о собраниях — Miro и, конечно, ИИ.

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

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