Процессы против ошибок
Меня зовут Иван Башарин. Я руководитель Лаборатории AI и архитектор решений в компании «Электронная торговая площадка Газпромбанка». В статье я пройдусь по этапам процессов в команде разработки и на примерах покажу, как мы работаем над показателями команды и улучшением наших результатов.
Генераторами новых процессов, как правило, выступают одни и те же группы пользователей: заказчики, аналитики, разработчики, тестировщики и группа управления. Но иногда процессы возникают вследствие ошибок. Из этого вырастают самые любопытные кейсы. Впрочем, обо всем по порядку.
Заказчики: они точно знают, чего хотят
Начну традиционно. С получения требования. Как и у всех, «необходимость» может поступить из любого источника: от внешнего заказчика, который придумал новую фичу; от devops`ов, которые нашли потребляющий 16 Гб оперативки на dev-стенде запуск unit-тестов; от ИБ, обнаруживших публичный demo-стенд; от самой команды разработки, где разработчик откопал «не самую оптимальную реализацию задачи».
В большинстве случаев заказчик хочет сразу получать оценку («Когда будет?») и сложность («Долго делать?»). Раньше мы пытались давать приблизительную оценку, и, конечно, частенько не попадали. Заказчик оставался недоволен, команда выгорала, напряжение росло. Отказать в оценке было невозможно, а проводить глобальный анализ любой стори слишком накладно. И мы на запросы клиента стали отвечать «четырехзарядным револьвером»: задача в нашем представлении может занять «дни», «недели», «месяцы», «Давайте не будем этого делать вообще».
Оценка «револьвером» (оценка по Фибоначчи + оценка «вслепую»)
Оценка времени выполнения задач с использованием последовательности Фибоначчи — это метод, который позволяет оценить объем и сложность задачи, а также время, которое потребуется на ее выполнение.
Принцип метода заключается в том, что каждой задаче присваивается число из последовательности Фибоначчи. Чем выше число, тем сложнее задача и, соответственно, больше времени понадобится.
Обычно в гибкой разработке используется часть последовательности от 1 до 13: 1, 2, 3, 5, 8, 13. Для крупных эпиков или групп историй может применяться 21 и далее.
Преимущества метода:
баллы ставятся по экспоненте: чем труднее задача, тем больше промежуток между соседними оценками. Это помогает детализировать мелкие задачи и оставить запас для сложных;
используются целые числа, которые дают более конкретное представление о величине (их можно соотнести с количеством предметов и почувствовать масштаб);
уменьшает время на планирование: нелинейная последовательность снижает временные затраты на анализ.
Заказчик получил приемлемую точность, а мы — возможность дооценить задачи и адекватно встроить в процесс реализации новую фичу.
При этом к разным задачам мы относились одинаково: по нашему регламенту каждая из них была обычной задачей, попадающей в приоритезацию, в план спринтов, в план релиза, в релизную сборку и, наконец, в прод. Так продолжалось до тех пор, пока мы не вывели задачу, к которой еще был не готов смежный сервис, и пришлось экстренно откатывать релиз, собирать новый, заново регрессить и релизить задачи.
Из этой ошибки мы вынесли чекбоксы — «блокирующие факторы» включения задачи в релизную сборку — и соответствующий регламент для заполнения. Фактически это были просто чекбоксы в форме добавления/редактирования задачи в трекере, но это помогло нам избежать повторения ошибки в дальнейшем.
Аналитики: они знают, как надо
Каждая команда, так или иначе, оценивает сроки реализации задачи, результаты оценки влияют на планирование реализации других задач, сроки спринтов и состояние готовности самого сервиса. Аналитики в нашей команде тоже отвечают не только за преобразование необходимости заказчика в задачу, но и за процесс ее оценки.
В нашем случае мы прошли несколько итераций, чтобы привести процесс оценки к необходимой точности и к необходимым временным затратам команды.
На первой итерации техлид команды примерно оценивал объем задачи и озвучивал сроки. Точность хромала, и все последствия ошибок оценки ложились на плечи команды.
Устав от количества ошибок, мы внедрили самый точный процесс оценки задач: полная вычитка и обсуждение задачи всей командой (ведь необходимо оценить время реализации, а также время тестирования и релизные сроки), отдельные статусы в трекере, оценка «револьвером», дооценка и «сглаживание пиков» в случае расхождения.
Уже на этом этапе мы получили приемлемую точность оценки (до 98% задач в спринте попадали в оценку), но это был настолько длительный процесс, что задачи стали выключаться из него. Получалось долго и дорого — стало проще не попасть в срок, чем тратить время команды на очередную небольшую задачу.
Затем, оценив потери времени и количество типовых оценок группами (большинство оценок попадали в определенные показатели), мы попробовали «маечную» оценку на основе Story Points.
Story Points (SP) — это единица, с помощью которой можно оценить объем усилий и ресурсов, нужных для завершения задачи.
Обычно в оценку закладывается три фактора:
объем работы — количество задач, которые нужно выполнить для успешного завершения проекта;
сложность — насколько технически сложна задача и насколько ясна ее цель;
риски — неопределенности, которые могут помешать работе с проектом.
Единицу измерения команда выбирает сама, но существует множество готовых вариантов.
Story Points — это относительная величина, то есть ценность каждой оценки определяет команда в сравнении с другими задачами проекта и выбранным «эталоном» задачи. [/spoiler]
В нашем случае задачи начали ранжироваться от S до XL по аналогии с размером «майки». Как это работает на практике: выбрали задачу уровня М, привели примеры задач других уровней, начали использовать, получили примерно такой же уровень попадания, как и на первичной оценке техлидом.
И такой чередой итераций из ошибок мы пришли к итоговому процессу оценки любой задачи:
первично для заказчика задача оценивается «четырехзарядным револьвером»;
после оцениваем сложность, без сроков реализации. Например, группе аналитики необходимо проверить всю документацию проекта в Confluence и поменять название типа документов «Заявка» на «Договор». Задача в реализации длительная, однако совершенно несложная (S). И напротив, группе разработки необходимо написать миграцию, меняющую данные документов по сложному условию и с несколькими наборами данных, — задача в реализации краткая, но сложная функционально (M);
в зависимости от сложности задачи меняем дальнейший процесс оценки. Задача уровня S (самая технически простая) не оценивается по срокам, так как чаще всего процесс оценки занимает больше времени, чем сама реализация. Задача уровня М и выше обязательно проходит через этапы общей вычитки и «револьверной» оценки. Задачи уровня XL и выше обязательно декпомпозируются до уровня М и вычитываются отдельно.
Таким образом, мы многократно повысили точность оценки задач на любом этапе и упростили этот процесс для всех сторон.
Разработка: они знают, как будет
Разработка в нашей команде — основной драйвер изменений в процессах. Ей нравится оптимизировать неудобные процессы и тем самым облегчать себе жизнь. При этом мы не ограничиваем влияние на процессы ролью сотрудника. Например, идея одного из наших джуниор-разработчиков выросла в целый процесс планирования через диаграммы Ганта с горизонтом в 2+ недели. И она была доработана отдельными планами спринтов, сотрудников, отчетных периодов для заказчика.
Диаграмма Ганта — это визуальное представление графика работ, построенное согласно плану проекта. На ней отражены задачи и последовательность их выполнения. Диаграмма Ганта состоит из двух осей: вертикальной со списком задач и горизонтальной со сроками. На пересечении осей цветным отрезком обозначают срок, за который нужно выполнить определенную задачу.
Диаграмма Ганта нужна, чтобы показать:
задачи, включенные в проект;
их продолжительность;
даты начала и окончания проекта;
время, которое занимает каждая задача;
исполнителей, работающих над задачами;
способы объединения задач.
Также именно по запросам группы разработки мы добавили пять новых статусов для задач и неоднократно меняли шаблоны для заведения задач.
Тестирование: они точно знают, как оно должно быть
В нашем представлении группа тестирования — это хранители знаний проекта. История задач, корректность их выполнения, планирование вывода, документация — все этапы жизни задачи определяются группой QA. От них же поступают обновления процессов между командами одного проекта и обновления процессов CI/CD. Именно так из жалобы «Нам неудобно проверять все в одном дев-стенде» появились K8S и мультистенды. Из «Нужен удобный процесс мониторинга» — связь сентри, задачи, релизной сборки и логов отладки.
Группа управления: знают, что сделать еще
Управлять гибкими процессами сложно. Это требует огромного количества времени. Поэтому у нас все же есть два неизменяемых регламента.
Первый — обязательная встреча для обсуждения предложений команд, на которой руководителями групп озвучиваются предложения команды и принимается решение апробации. В рамках проверки мы обязательно формируем перечень требований: чего мы хотим достичь, в какие сроки и какими средствами.
И второй — все остальные регламенты должны быть гибкими :)
И что в итоге?
Кто-то уже использует похожие подходы. А кто-то наверняка увидел в описанных процессах общие черты. Все приведенные мной примеры — это постмортем (иногда предупредительный), возведенный в абсолют.
Post-mortem в ИТ — это задокументированный отчет об инциденте, его последствиях, предпринятых действиях для минимизации или устранения причин, а также предотвращения повторения инцидента.
Это возможность для всех участников проекта обсудить, что получилось, что не получилось и что можно вынести из успехов и ошибок.
При работе с процессами используется тот же стек, что и при работе с задачами:
для ведения инцидентов мы используем Youtrack с полями критичности и отдельной доской;
для мониторинга в том же Youtrack организовали дашборды со статусами и алертами о сроках;
для ведения записей о собраниях — Miro и, конечно, ИИ.
Структурный подход к процессам помогает нам не только оптимизировать работу, но и развивать новые направления. К примеру, из попытки вывода задачи (четыре месяца рефакторинга) и последующего отката релиза мы вынесли механизм валидации вывода и миграций в нем. Из повторения (на этот раз успешного) вывода этой задачи — необходимость в продолжении. Из необходимости распределить всю команду на срочные задачи — отдельную группу, занимающуюся поддержкой и рефакторингом.
Гибкие процессы и эффективный постмортем помогли нам достичь высокой эффективности и качества в разработке. Надеюсь, что примеры и подходы окажутся полезными для вас и вдохновят на улучшения в ваших процессах.
