Хабрахабр

Оцениваем процессы в команде разработки на основе объективных данных

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

Сергей Семёнов считает, что это происходит в основном по двум причинам.

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

И предлагает подход к оценке и контролю процессов на основе объективных данных.

Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.

О спикере: Сергей Семёнов (sss0791) работает в IT 9 лет, был разработчиком, тимлидом, продакт менеджером, сейчас CEO компании GitLean. GitLean — это аналитический продукт для менеджеров, технических директоров и тимлидов, предназначенный для того, чтобы принимать объективные управленческие решения. Большая часть примеров в этом рассказе опирается не только на личный опыт, но и на опыт компаний-клиентов со штатом разработки от 6 до 200 человек.

Я не буду на этом подробно останавливаться, а буду ссылаться на статью по некоторым метрикам. Про оценку разработчиков мы уже с моим коллегой Александром Киселевым рассказывали в феврале на предыдущей TeamLead Conf. Сегодня поговорим о процессах и о том, как их контролировать и измерять.

Источники данных

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

  • Git с информацией о коде;
  • Jira или любой другой task tracker c информацией о задачах;
  • GitHub, Bitbucket, Gitlab с информацией о код-ревью.

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

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

Нужно строить не просто Agile, а делать его измеримым (Measurable Agile). Первое правило, которому мы рекомендуем следовать при проектировании и построении процессов, это делать их так, чтобы они оставляли артефакты в данных.

Чтобы вы понимали масштаб — на команду из 15 разработчиков в неделю прилетало примерно 30-40 багов с продакшена. Расскажу страшилку, которую мы встретили у одного из клиентов, который пришел к нам с запросом на улучшение качества продукта. Сначала мы подумали, что это просто ошибка в данных, или тестировщики не обновляют статус задачи. Начали разбираться в причинах, и обнаружили, что 30% задач не попадает в статус «testing». Когда-то была проблема в инфраструктуре, из-за которой 1-2 задачки в итерации не попадали в тестирование. Но оказалось, что действительно 30% задач просто не тестируются. В итоге это привело к более глобальным проблемам. Потом про эту проблему все забыли, тестировщики перестали про неё говорить, и со временем это переросло в 30%.

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

Иногда ради измеримости приходится жертвовать частью принципов Agile и, например, где-то предпочитать письменную коммуникацию устной.

Суть ее в следующем: когда разработчик берет задачу и перетаскивает ее в «in progress», он должен поставить due date, когда задача будет либо выпущена, либо готова к релизу. Очень хорошо себя показала практика Due date, которую мы внедрили в несколько команд ради улучшения прогнозируемости. Эта практика учит разработчика быть условным микро проджект менеджером своих собственных задач, то есть учитывать внешние зависимости и понимать, что задача готова, только когда клиент может использовать ее результат.

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

Подход от проблем

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

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

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

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

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

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

Тогда все смогут своевременно на них реагировать и справляться с обнаруженными проблемами. В идеале мы хотим построить следующую схему работы: чтобы у нас был автоматический сбор данных; по этим данным мы могли бы построить метрики; с помощью метрик находить проблемы; сигнализировать о проблемах напрямую разработчику, тимлиду или команде. Иногда метрики останутся просто метриками, которые придется анализировать, смотреть на значения, тренды и так далее. Сразу скажу, что дойти до понятных сигналов не всегда получится. Даже с данными иногда будет проблема, иногда их нельзя собрать автоматически и приходится делать это руками (буду отдельно уточнять такие случаи).

Далее мы рассмотри 4 стадии жизни фичей:

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

Проблемы с дисциплиной на стадии планирования

Информации очень много, но я уделяю внимание самым основным моментам. Они могут показаться достаточно простыми, но с ними сталкивается очень большое количество команд.

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

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

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

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

Это контролируется элементарно. Первая дисциплинарная проблема — у задач нет описания, или они плохо описаны. Например, следим, что заданы критерии приемки, или для фронтендовых задач есть ссылка на макет. Есть формат, которому должны соответствовать задачи, — проверяем, так ли это. Для бэкэндовой задачи релевантно одно описание, для фронтендовой — другое.
Еще нужно следить за расставленными компонентами, потому что формат описания часто привязан к компоненту.

В результате к концу итерации выясняется, что самые важные задачи так и не были сделаны. Следующая частая проблема — приоритеты проговариваются устно или вообще не проговариваются и в данных не отражаются. Если у команды 90% задач в итерации имеют high priority, это всё равно, что приоритетов нет совсем. Нужно следить за тем, что команда использует приоритеты и использует их адекватно.

Навешиваем на всё это сигналы.
Мы стараемся приходить к такому распределению: 20% high priority задач (нельзя не зарелизить); 60% — medium priority; 20% — низкий приоритет (не страшно, если не зарелизим).

Базовые из них: у задач нет оценок (следует завести сигнал) или типы задач проставлены неадекватно. Последняя проблема с дисциплиной, которая бывает на стадии планирования — не хватает данных, для последующих метрик в том числе. К сожалению, автоматически проконтролировать второй тип проблем не получается. То есть баги заводятся как задачи, а задачи технического долга вообще не отследить. Советуем просто раз в пару месяцев, особенно если вы CTO и у вас несколько команд, проглядывать backlog и убеждаться, что люди заводят баги как баги, стори как стори, техдолговые задачи как техдолговые.

Проблемы с прогнозируемостью на стадии планирования

Переходим к проблемам с прогнозируемостью.

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

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

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

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

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

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

Проблемы с качеством на этапе планирования

Первая проблема: команда не додумывает функциональность выпускаемых фич. Я буду говорить про качество в общем смысле — проблема с качеством, это если клиент говорит, что она есть. Это могут быть какие-то продуктовые недодумки, а могут быть технические вещи.

Суть простая: задачу зарелизили, а потом в течение трех недель достаточно высокий процент ее кода был удалён. Касательно продуктовых недодумок, хорошо работает такая метрика как 3-week churn, выявляющая, что спустя 3 недели после релиза задачи churn выше нормы. Такие кейсы мы вылавливаем и разбираем с командой.
Видимо, задача была не очень хорошо реализована.

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

Эта история легко мониторится, если вы соблюдаете работу с типами, то есть техдолговые задачи оцениваются и заводятся в Jira как техдолговые. Следующая очень стандартная проблема — у команды нет времени на технический долг. Если мы договаривались с бизнесом о том, что это 20%, а потратили только 10%, это можно учесть и в следующем квартале уделить техническому долгу больше времени.
Мы можем посчитать какую квоту распределения времени давали команде на техдолг в течение квартала.

Проблемы с дисциплиной на стадии разработки

Теперь перейдем к стадии разработки. Какие тут могут проблемы с дисциплиной.

Отследить это легко по двум банальным признакам: К сожалению, бывает так, что разработчики ничего не делают или мы не можем понять, делают ли они хоть что-нибудь.

  • частота коммитов — хотя бы раз в день;
  • хотя бы одна активная задача в Jira.

Если этого нет, то не факт, что надо бить по рукам разработчика, но надо знать об этом.

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

Первое, чему мы призываем следовать все команды, это указывать в commit messages task-префиксы из трекера, потому что только в этом случае мы можем связать задачу и код к ней. Также могут нарушаться различные правила работы с Git. На любые дополнительные git-правила, которые у вас есть, например, нельзя коммитить в master, тоже настраиваем git hooks. Тут лучше даже не сигналы строить, а прямо настроить git hook.

На этапе разработки бывает много практик, которым должен следовать разработчик. Это же относится и к оговоренным практикам. Например, в случае Due date будет три сигнала:

  • задачи, у которых due date не проставлен;
  • задачи, у которых есть просроченый due date;
  • задачи, у которых due date был изменён, но нет комментария.

На всё на это настраиваются сигналы. На любую другую практику тоже можно настроить подобные вещи.

Проблемы с прогнозируемостью на этапе разработки

Много чего может пойти не так в прогнозах на этапе разработки.

Мы уже попытались решить эту проблему на этапе планирования — декомпозировать задачи достаточно мелко. Задача может просто долго висеть в разработке. Мы рекомендуем для начала просто настроить SLA на статус «in progress», чтобы был сигнал о том, что этот SLA нарушается. К сожалению, это не всегда помогает, и бывают задачи, которые зависают. Это не позволит прямо сейчас начать выпускать задачи быстрее, но это позволит опять-таки собирать фактуру, на это реагировать и обсуждать с командой, что произошло, почему задача долго висит.

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

Например, вчера у разработчика было мало активности по коду. У разработчика могут быть какие-то проблемы, про которые он не говорит, но которые легко выявить на основе данных. Возможно, он застрял и ему нужна помощь, но он стесняется её попросить. Это не обязательно означает, что есть проблема, но вы, как тимлид, можете подойти и узнать это.

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

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

Проблемы с качеством на этапе разработки

Разработка напрямую влияет на качество. Вопрос в том, как понять, кто из разработчиков больше всего влияет на снижение качества.

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

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

Не буду здесь останавливаться подробно, я подробно рассказывал об этом в прошлый раз. Следующая проблема, которая может быть с качеством на этапе разработки, это то, что мы пишем сложно поддерживаемый код, такую «слоеную» архитектуру. Есть метрика, которая называется Legacy Refactoring, которая как раз показывает, как много времени тратится на встраивание нового кода в существующий, как много старого кода удаляется и меняется при написании нового.

Я надеюсь, что вы за этим уже следите. Наверное, один из самых важных критериев при оценке качества именно на стадии разработки — это контроль SLA для high-priority-багов. Если нет, то рекомендую начать, потому что это зачастую один из самых важных показателей для бизнеса: high-priority и critical баги команда разработки обязуется закрывать в определенное время.

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

Проблемы с дисциплиной на этапе код-ревью

Переходим к стадии Code review. Какие тут могут быть проблемы с дисциплиной? Начнем с, наверное, самых дурацкой причины — забытых pull requests. Во-первых, автор может просто не назначить ревьюера для pull request, который в результате будет забыт. Или, например, тикет забыли передвинуть в статус «in review», а разработчики проверяют, какие задачи нужно ревьюить именно в Jira. Нужно не забывать за этим следить, для чего настраиваем простые сигналы. Если у вас есть практика, что должно быть больше 2-3 ревьюеров на задачу, то это также легко контролируется с помощью простого сигнала.

Тут тоже делаем сигнал — убеждаемся, что в pull request всегда есть ссылка на ticket в Jira и ревьюер может легко с ним ознакомиться.
Следующая история о том, что ревьюер раскрывает задачу, не может быстро понять, к какой задаче относится pull request, ему лень спросить и он ее откладывает.

Всегда бывают огромный pull requests, в которых много всего сделано. Следующая проблема, которую, к сожалению, не получается исключить. В этом случае автор может помочь ревьюеру с онбордингом, а мы можем этот процесс проконтролировать. Соответственно, ревьюер их открывает, смотрит и думает: «Нет, лучше я потом это проверю, что-то тут слишком много». Большие pull requests обязательно должны иметь хорошее понятное описание, которое соответствует определенному формату, и этот формат отличается от тикета в Jira.

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

Для этого внедряется элементарная дисциплинарная практика: ревьюер должен в конце ревью обязательно отписаться специальным комментарием о том, что «я закончил, можно фиксить». Далее проблема, с которой тоже очень часто сталкиваемся, — автор говорит, что просто не знает, когда ему можно начинать всё исправлять, потому что он не знает, закончено ли ревью. Соответственно, можно настроить автоматические уведомления об этом автору.

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

Проблемы с прогнозируемостью на стадии код-ревью

Если задачи продолжают зависать, рекомендуем настроить SLA на то, что задача либо долго ждет фиксов, либо же долго ждет ревью. Соответственно, обязательно пингуем и автора, и ревьюера.

Это время, когда вся команда садится и занимается чисто код-ревью. Если SLA не помогают, рекомендую внедрить в практику утренний "час код-ревью" или вечерний — как удобно. Внедрение этой метрики очень легко мониторить по смещению времени активности в pull request к нужному часу.

Например, в одной из команд CTO стоял у самых истоков системы, всю ее написал, и так уж получилось, что всегда был главным ревьюером. Бывает, что есть люди перегруженные код-ревью, и это тоже не очень хорошо. В какой-то момент всё пришло к тому, что в команде из 6 человек на нём висело больше 50% код-ревью и продолжало копиться и копиться. Все разработчики постоянно навешивали на него задачи на код-ревью. Когда ввели элементарно дисциплинарную практику о том, что на CTO нельзя теперь было навесить больше двух-трех задач в итерацию, в следующую же итерацию команда показала закрытие спринта почти на 100%. В результате, как несложно догадаться, итерации у них закрывались на те же самые 50%, потому что CTO не успевал всё проверить.

Триггеры могут быть такими: Следующая история, которая легко мониторится с помощью метрик — это то, что в код-ревью начался холивар.

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

Все это повод проверить, нет ли холивара в этом код-ревью.

Проблемы с качеством на стадии код-ревью

Прежде всего, проблема может быть в просто очень поверхностном код-ревью. Для того чтобы это мониторить, есть две неплохие метрики. Можно измерить активность ревьюера как количество комментариев на каждые 100 строк кода. Кто-то ревьюит каждые 10 строчек кода, а кто-то целые экраны пролистывает и оставляет 1-2 комментария. Конечно, не все комментарии одинаково полезны. Поэтому можно уточнить эту метрику измерив влияние ревьюера — процент комментариев, которые указывали на строку кода, которая потом была изменена в рамках ревью. Тем самым мы понимаем, кто самый въедливый, и самый эффективный в том смысле, что его комментарии чаще всего приводят к изменениям кода.

С теми, кто подходит к ревью очень формально, можно поговорить и мониторить их далее, смотреть, начинают ли они ревьюить более тщательно.

Метрика здесь — высокий churn кода после код-ревью, т.е. Следующая проблема — автор выносит на ревью очень сырой код и ревью превращается в исправление самых очевидных багов вместо того, чтобы уделить внимание чему-то более сложному, или просто затягивается. процент изменения кода в pull request после того, как начался ревью.

Проверяем, чтобы стилистический рефакторинг был выделен либо в отдельный commit, либо в идеале вообще в отдельную ветку, чтобы не мешать проводить качественный код-ревью.
Случай, когда ничего непонятно из-за рефакторинга, к сожалению, стоит контролировать руками, автоматически это делать достаточно проблемно.

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

Проблемы с дисциплиной на этапе тестирования

Переходим к этапу тестирования и проблемам с дисциплиной на этом этапе. Самая частая, с которой мы сталкиваемся — нет информации о тестировщиках в Jira. То люди экономят на лицензиях и не добавляют тестировщиков в Jira. То задачи, которые просто не попадают в статус «testing». То мы не можем определить возврат задачи на доработки по task-tracker. Рекомендуем на все это настроить сигналы и смотреть, чтобы данные копились, иначе о тестировщике сказать что-то будет крайне сложно.

Проблемы с прогнозируемостью на стадии тестирования

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

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

То время сборки build’а очень большое, то время раскатки системы, то время прогона автотестов — если можете настроить на это метрики, рекомендуем это сделать. Сложный pipeline test-окружения — суперчастая проблема, но, к сожалению, не все на это строят метрики. Если вы этого ни разу не делали, то вам откроется много инсайтов. Если нет, то хотя бы раз в 1-2 месяца рекомендуем садиться рядом со своим тестировщиком на целый день, чтобы понять, что иногда ему живется очень непросто.

Проблемы с качеством на этапе тестирования

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

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

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

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

Методология работы с метриками

Про метрики мы поговорили, и теперь вопрос — как со всем этим работать? Я рассказал только самые базовые вещи, но даже их довольно много. Что со всем этим делать и как это использовать?

Мы пробовали разные каналы коммуникации: и e-mail, и dashboard — не очень хорошо работает. Мы рекомендуем по максимуму автоматизировать этот процесс и все сигналы доставлять в команду посредством бота в мессенджерах. Бота вы можете написать сами, можете взять у кого-нибудь OpenSource, можете купить у нас. Бот зарекомендовал себя лучше всего.

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

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

Вначале надо обязательно согласовать это с разработчиком, проговорить с ним и с командой. Любые сигналы, которые вы делаете публичными, или направляете напрямую разработчику, ни в коем случае нельзя просто взять и включить. Желательно в письменном виде занести в Team Agreement все пороговые значения, причины почему вы это делаете, какие будут следующие шаги и так далее.

Мы не строим концлагерь для разработчиков, где нельзя сделать шаг вправо, шаг влево. Надо иметь в виду, что все процессы имеют исключения, и учитывать это на этапе проектирования. Если бот постоянно ругается по какой-то задаче, которую действительно нельзя декомпозировать, и работа над которой займет 5 дней, надо поставить метку «no-tracking», чтобы бот это учитывал и всё. Все процессы имеют исключение, просто мы хотим о них знать. Если количество задач с меткой «no-tracking» стабильно растет, то, к сожалению, это значит, что те сигналы и процессы, которые вы придумали, тяжелы для команды, она не может их соблюдать, и ей легче их обходить.
Вы, как менеджер, можете отдельно мониторить количество таких «no-tracking» задач, и тем самым понимать, насколько хороши и те процессы, и те сигналы, которые вы выстраиваете.

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

Это переходящая должность человека (раз в неделю), который разбирается с проблемами, о которых сигнализирует бот. Для оптимизации этого процесса мы рекомендуем ввести такую практику, как дежурный по процессам. Тем самым у разработчика повышается мотивация работать с этим продуктом. А вы как тимлид помогаете дежурному разбираться с этими проблемами, то есть курируете его. Тем самым вы снижаете свою уникальность команде и приближаете тот момент, когда команда станет автономной, и вы таки сможете поехать на Бали. Он понимает его пользу, потому что видит, как эти проблемы можно решать и как на них реагировать.

Выводы

Даже если вы сейчас не хотите строить метрики и сигналы, вы сможете сделать крутой, ретроспективный анализ в будущем, если сейчас начнете их собирать. Собирайте данные. Стройте процессы таким образом, чтобы у вас собирались данные.

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

Это не всегда нужно, возможно, если сигналов стало мало — у вас всё хорошо, команда начала работать так, как вы с самого начала хотели, и вы молодец 🙂 Когда сигналов мало уже несколько недель — вы молодец! Мы сталкивались с тем что, когда команда видит, что сигналов становится мало, и вроде ситуация налаживается, она начинает судорожно придумывать еще какие-то практики, начинает что-то внедрять, чтобы снова увидеть эти пачки сигналов.

Конференция в феврале пройдет в Москве и Call for Papers уже открыт. Приходите делиться своими тимлидскими находками на TeamLead Conf.

Подпишитесь на нашу рассылку по управлению, чтобы получать новости программы и не пропустить время выгодной покупки билетов на конференцию. Хотите еще понабраться чужого опыта?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть