Как мы избавились от пинг-понга задачами между разработкой и QA
Как показалось из рассказа и как я знаю из собственной практики, секрет успеха в выравнивания квалификаций обеих команд. В данном случае через навязывание правильных софт-скиллов, отказ от философии «моя хата с краю» и вовлечение в планирование. Пинг-понг маловероятен, если и разработчики и QAшники в среднем имеют миддл+ скилл.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Привет, спасибо за ответ. Если под мидл+ идет soft skills — то да согласен =) Ключевой здесь момент — качать софты — это относится к процессам типа груммингов, планирований, да и просто построения команды и меж-командных коммуникаций со стороны ребят. В командах с развитыми софтами и джуны хорошо и гладко вливаются в процессы, а потом и растут быстрее — проверено как раз на этой же команде.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
«Проблема заключается в том, что в такой системе случается пинг-понг задачами. У нас такое бывало. Разработка передаёт задачу в QA, QA её проверяет и возвращает разработке с багами. Разработчик правит эти баги, снова отправляет задачку в QA, а QA находит новые баги.»
А где тут пинг-понг? Стандартный рабочий процесс. Найдены дефекты по задачи — задача возвращается на доработку.
«Порядка 30% задач могли возвращаться с уточнением требований.»
Похоже на проблемы с аналитикой, формализацией требований задачи. У вас нет аналитиков в команде?
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Действительно аналитиков в команде нет, но это не мешает на этапе грумминга уточнить все требования — если подключать тестирование с этого этапа активно — не зря одним из видов тестирования является тестирование требований. Пинг-понгом мы называем ситуацию когда одна юзер стори может кататься между разработкой и тестированием более 2-3 раз.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
ну вот, появился этап анализа задачи (пусть и смлами QA ) сразу упал процент до 10%
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
А как организованы команды? Они кросс-функциональны или есть отдельно фронт, бэк и т.д.?
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В основном команды бьются backend/frontend, есть несколько кросс-функциональных. Конкретно в статье речь идет о backend команде, единственная часть фронта у команды — админка для внутренних клиентов (менеджеры/техподдержка). Обычно в команде присутствует tl + devs + qas + automation отдельно идут scrum master и PO (работают с командой очень плотно но относятся к другим веткам/отделам). Сейчас есть стремление qa + automation перевести в этакий qa fullstack, чтобы один инженер писал тест-кейсы и автоматизировал их в то же время — это позволит повысить вовлеченность и ускорить покрытие.
doctor Brain
Команда ping проверяет связь с определенным сетевым узлом в локальной сети или в Интернете.
Синтаксис команды имеет вид:
ping
где является доменным именем или сетевым (IP) адресом.
Пример исполнения команды ping имеет следующий вид:
PING ya.ru (87.250.250.242): 56 data bytes 64 bytes from 87.250.250.242: icmp_seq=0 ttl=250 time=32.702 ms 64 bytes from 87.250.250.242: icmp_seq=1 ttl=250 time=14.315 ms 64 bytes from 87.250.250.242: icmp_seq=2 ttl=250 time=22.952 ms 64 bytes from 87.250.250.242: icmp_seq=3 ttl=250 time=22.265 ms 64 bytes from 87.250.250.242: icmp_seq=4 ttl=250 time=42.417 ms 64 bytes from 87.250.250.242: icmp_seq=5 ttl=250 time=15.399 ms ^C --- ya.ru ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 14.315/25.008/42.417/9.838 ms Команда отправляет запрос на сервер и получает от сервера ответ.
По умолчанию ping продолжает отправлять запрос на сервер каждую секунду, до тех пор пока процесс не будет прерван сочетанием клавиш Ctrl + C .
С помощью опции -c можно ограничить количество запросов, отправляемых тестируемому сетевому узлу:
ping -c 2 ya.ru По окончании исполнения команды ping на экран выводится статистика запросов: процент потерянных пакетов и статистики производительности сети. На экран выводится IP-адрес опрашиваемого командой хоста, и время, которое понадобилось для получения ответа.
Не все серверы поддерживают команду ping , в таком случае будет получен ответ request time out :
PING ya.ru (87.250.250.242): 56 data bytes Request time out for icomp_seq 0 Request time out for icomp_seq 1 Request time out for icomp_seq 2 Request time out for icomp_seq 3 Request time out for icomp_seq 4 Request time out for icomp_seq 5 --- ya.ru ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss Иногда выполнение команды ping на сервере блокируется специально, чтобы снизить нагрузку на ресурс или скрыть сервер.
Команда ping использует протокол ICMP (Internet Control Message Protocol) — это протокол сетевого уровня, такой же как TCP или UDP.
В запросе на сервер отправляется пакет с сообщением ECHO_REQUEST , а сервер возвращает сообщение ECHO_REPLY — это основной механизм работы команды ping .
Команда полезна для того, чтобы узнать доступность сетевого узла и его удаленность, с точки зрения времени необходимого на обмен данными. Обычно, исходя из простых физических законов, чем ближе сервер — тем быстрее будет возвращаться ответ.
Команда ping работает в Linux, MacOS, WSL — в любой среде, основанной на UNIX.
Спасибо за внимание.
Новые публикации
JavaScript: сохраняем страницу в pdf
2021-07-12
HTML: Полезные примеры
Как различается работа backend и frontend разработчика?
Backend и frontend разработчики – это специалисты, обеспечивающие возведение, поддержание и успешное функционирование любого Интернет-ресурса. Когда речь заходит про веб-разработку, стоит понимать, что это обширная сфера деятельности, которая включает в себя множество терминов, видов манипуляций. Как следствие, появляются узкоспециализированные разработчики, в зоны ответственности которых входят различные задачи.
В представленной статье мы подробно разберем, что такое front-end и back-end разработка, чем различаются квалификации специалистов, работающих в этих сферах, с какими инструментами они взаимодействуют и какие цели достигают в процессе своей профессиональной деятельности.
Ключевые отличия между backend и frontend разработчиками
Если задаться вопросом «frontend и backend что это?», то можно выделить ряд отличительных особенностей между указанными направлениями. Наиболее существенные различия обычно проявляются в следующих аспектах взаимодействия с программным обеспечением:
- Области, в которых разбираются эти программисты.
- Применяемые в деятельности технологии и инструменты.
- Языки, на которых пишутся каждая из сторон веб-проекта.
- Требования, предъявляемые специалистам и необходимые навыки.
Стоит отметить и то, что у этих направлений проектирования интернет-порталов стоят совершенно различные условия. Так, если мы говорим о бэкэнд разработке, то рядовой пользователь сайта с большой долей вероятности никогда не увидит результаты трудов команды специалистов в этой сфере. Вся оболочка, написанная в бэк-энде, обращена полностью к серверу. Он выполняет свои функции в фоновом режиме той структуры, для которой создается, чтобы либо воссоздать обособленный сервер-интерфейс, либо сделать возможным реализацию внешних обработок.
Внешний interface, в свою очередь, относится к техническим решениям, представленным на видимой для пользователей стороне веб-ресурса, в котором применяется. Это клиентский уровень, обеспечивающий эксплуатацию ресурса с помощью таких элементов, как компьютерный браузер, кнопки и текст.
Что включает в себя бэк-энд сайта или сервиса?
Бэкэнд — это та часть разработки портала, которая обращена непосредственно к серверу. В некоторых случаях это применяется для того, чтобы разработанная платформа обращалась непосредственно к серверу. Это применяется при реализации внутренних баз данных или файловых серверов, функционирующих в фоне и содержащих в себе ресурсы компании.
Однако, довольно часто он связан также и с юзер-интерфейсом, обеспечивая процессы его функционирования. В качестве примера здесь можно выдвинуть сайты знакомств, формирующие базы данных пользователей, и определяющих собранную информацию в профайл.
Написание алгоритмов и скриптов в бэеэнд-разработке применяется большой перечень языков, в числе которых отдельного внимания заслуживают:
При этом, стоит понимать, что для пользователей функционирование алгоритмических операций в бэк-энде остается незримым, так как они взаимодействуют с ресурсом исключительно посредством применения open-интерфейса.
Основные задачи фронт-энд составляющей
Фронтэндинтернет портала представляет собой область данных, с которой напрямую взаимодействует юзер. Ключевой задачей представленной составляющей ресурса является применение внутренних ресурсов сервиса для осуществления оперативной доставки информации по запросами, а также обеспечение возможности для конечного юзера использовать веб-сервис, не вникая при этом в индивидуальные особенности его функционирования.
Юзер-интерфейс содержит в себе множество составляющих элементов, обеспечивающих удобство восприятия информации и взаимодействия с ней. В их число можно отнести таблицы, текстовое представление, цветовую палитру, кнопки управления и иные модули визуализации операций.
Как и в предыдущем случае, для осуществления эффективной разработки необходимо использовать несколько различных языков. В число наиболее распространенных, вошли JavaScript, HTML, а также CSS.
Ключевыми процессами в деятельности специалиста, осуществляющего написание внешней оболочки приложения или сайта, являются повышение производительности сервис-портала, а также повышение скорости его реакции на действия пользователя. Это необходимо для того, чтобы ресурс загружался быстро и хорошо показывал себя на всех типах устройств.
Для чего осуществляется разделение?
Front-end и back-end, на текущий момент, имеют строгое разделение по нескольким основным причинам. В первую очередь стоит отметить тот факт, что для оформления требуется применение различных языков программирования, механизмов и фреймворков. Что, в свою очередь, ведет к необходимости наличия различных компетенций у специалистов, которые задействованы в производстве системы.
Казалось бы, и то, и другое, завязано на реализации одной конкретной задачи – обеспечения бесперебойного функционирования интернет-портала или программного обеспечения. Так почему бы их не объединить между собой под одним единым термином?
Дело в том, что их можно рассматривать как единую экосистему под общим понятием «разработка». Однако, если смотреть на этот вопрос именно под таким углом, то мы имеем дело лишь с обобщающей категорий знаний и профессиональных действий, в которую также можно отнести абсолютно все типы кодирования, проработку дизайна и строительство архитектуры сайта.
Также под обобщение можно подвести и термин «стек-разработка», подразумевающий под собой полный комплекс работ по генерации пользовательского интерфейса и серверной составляющей проекта.
Проектирование веб-сайта очень похоже возведение здания. Вполне очевидно, что один человек не в состоянии построить дом самостоятельно. Это по меньшей мере не эффективно. Кроме того, такой подход требует большого количества знаний от одного конкретного человека, что ведет к снижению их глубины. Может ли один человек построить дом самостоятельно? Конечно, но это менее эффективно и потребует от этого человека обучения многим навыкам. Фронтенд- и бэкенд-производство обладает схожими особенностями. По сути, они являются составными частями глобальной веб-разработки, так как обладают уникальными возможностями. Такое разделение позволяет упростить поиск людей, оптимально подходящих на заданную роль, так как снижается перечень необходимых компетенций.
Если продолжать проводить аналогии со строительством, то специалиста по внешним обработкам можно сравнить с профессиональным маляром, который создает отделку, видимую для жителей. И если тут все понятно, то backend разработчик кто это? В такой парадигме его можно сравнить с электриком, который управляется с системами, невидимыми для глаза, но, при этом, являющимися жизненно важными. Несомненно, у одного специалиста может быть какой-то опыт работы в смежной сфере. Однако, он никогда не сможет действовать в одиночку также эффективно, как два профессионала, каждый из которых занят своим делом.
Для чего используются фреймворки в серверной части?
Суть такого инструмента разработчика, как фреймворки, заключается в создании устойчивой основы для ускоренного выпуска в работу различных интернет-сервисов. Они позволяю избавиться от необходимости в каждом новом проекте воспроизводить с нуля уже созданные ранее структуры. Ведь уже давно заложены базовые основы с общими файлами сайтов, типами баз данных и множеством других элементов, которые уже готовы к эксплуатации на старте проекта.
Применение описанного механизма экономит время, позволяет работать со стандартизированными алгоритмами написания кода. Как следствие, компании получают возможность существенно упростить процесс масштабирования своих веб-ресурсов.
Применение фреймворков для создания пользовательской стороны
Когда речь заходит о произведении внешнего поля, в отличии от бэкэнд разработчиков, здесь специалисты имеют возможность выбирать между использованием framework и библиотек, так как грань между ними является достаточно тонкой.
Учитывая, с чем предстоит столкнуться разрабатываемой с их помощью инфраструктуре, основными процессами можно назвать:
- Стилизацию веб-сайта;
- Управление запросами AJAX;
- Согласование действий с серверной оболочкой.
Часть популярных библиотечных хранилищ по своей сути приближены к фрейворкам, а те, в свою очередь, содержат в себе информационные блоки и возможности, которые могут классифицироваться, как библиотеки. Библиотечные паттерны могут помочь программисту выполнять ряд важных для разработки действий, но, при этом, не ограничивают его в формате архитектуры разрабатываемого сервиса.
Что же касается фреймворков, то они содержат в себе меньший объем пакетных файлов, но принуждают вести свой проект по строго определенным для данного набора правилам. На практике такой подход является более эффективным, так как упрощает задачу для специалиста. Выбор библиотек же оптимален для тех, кто предпочитает больше творческой свободы, которая дается в процессе разработки.
Что входит в задачи специалистов?
Как было отмечено ранее, фронт-энд и бэк-энд несут в себе разные функциональные возможности, совместная реализация которых является необходимой для нормального функционирования интернет-ресурса. Как следствие, проектные условия программистов, работающих в соответствующих сферах, также будут различаться.
Так, в обязанности тех, кто занимается юзер-интерфейсом, в том числе входят:
- Объединение всех предоставленных визуальных элементов от команды дизайнеров в единую систему, для запуска портала в работу в соответствии с заданными алгоритмами.
- Сбор информации от тестировщиков и пользователей о работе портала для составления дальнейшего плана доработки и реализации в виде прикладного решения.
- Постоянная работа с системами и инструментами проработки дизайна для его оптимизации под различные устройства.
- Управление AJAX для оптимизации представления ресурсами интегрированных интерактивных элементов при осуществлении динамической загрузки в фоновом режиме без ребута страницы.
В это же время для работающих над сервер-оболочкой характерны:
- Работа с логическим представлением и реализацией приложений, функционирование которых обращено непосредственно к сервер-системе, а также определение методик интеграции инструментов в общую инфраструктуру.
- Оптимизация работы информационных баз для надежного хранения и оперативного доступа к записанным файлам.
- Координированное взаимодействие со специалистами внутри компании для организации обслуживания внутренней серверной инфраструктуры.
- Обеспечение расширения функционала информационной базы, обеспечение более комфортного предоставления сервером обеспечения для конечного приложения, а также интеграции системы обмены данными между фронт-бэк.
Стоит понимать, что все перечисленные манипуляции являются лишь малой частью того, что выполняют разработчики при ведении того или иного проекта. Но это позволит получить примерное представление о том, в каком направлении движется деятельность специалиста.
Андрей Минин, автор блога
Как мы избавились от пинг-понга задачами между разработкой и QA
Меня зовут Никита Пимошенко. Сейчас я IT-Head департамента General Development в Quadcode, а до этого три года был тимлидом команды Billing API . Я успел поработать в ряде интересных проектов, но самым большим своим достижением на данный момент считаю налаживание процессов в моей Billing-команде. Статья — именно об этом. Расскажу о наших проблемах во взаимодействии между разработчиками и QA-инженерами и том, как мы эти проблемы решали.
Чего мы хотим
Перед тем как углубиться в процессы, определимся, какую ценность они должны приносить. Если мы говорим про IT-отрасль, то бизнес хочет предсказуемый и повторяемый результат. Разработчики и QA-инженеры, как ни странно, хотят писать код и тестировать функционал. На выходе же мы все хотим получить качественный продукт.
Процесс продуктовой разработки в Quadcode
У разных компаний и команд разные требования к безопасности кода. Мы работаем с финтехом, поэтому наш процесс разработки довольно тяжёлый и разлапистый. В нём есть ряд этапов, которые требуются для того, чтобы обеспечить безопасность кода и его отказоустойчивость.
Детализация этапов процесса
Этапы подготовки задачи:
- Backlog — задача создана и описана.
- Groomed — задача разобрана командой (dev+QA). Её описание понятно команде, мы оценили её сложность.
Этапы разработки задачи:
- Current Sprint — задача запланирована в текущий спринт.
- In Progress — задача взята в разработку.
- Need Fix — задача ожидает фикса после review или тестирования.
- Review — задача на code review.
- Hold — задача в ожидании решения блокера от нас или внешних команд.
- Ready to Test — задача готова к тестированию (очередь на тест).
- Testing — задача тестируется в Sandbox.
- Deploy to Int — очередь тестирования на окружении Integration.
- Verify on Int — проверяем на окружении Int/прогоняем регресс.
- Security Review — задача отправлена на review безопасности.
- Deploy to Prod — задача готова к релизу на прод.
- Verification — задача ожидает проверки на проде со стороны QA/QC, либо мы просто мониторим работу в метриках в течение какого-то времени.
- Done — верификация завершена.
Весь процесс можно формально разделить на три блока:
- Разработка.
- Тестирование.
- Верификация, когда функционал уже на проде.
Релизным менеджментом у нас занимаются разработчики: деплой в прод идёт со стороны разработки автоматизированными средствами Jenkins.
Если взглянуть на схему, то кажется, что мы видим чёткий вход в тестирование на шаге ready to test, где задачка переходит QA-инженерам. Долгое время так и было, но этот процесс породил ряд проблем.
Проблемы взаимодействия QA и разработки
Разные процессы с чёткими границами. Несмотря на то, что общий процесс один, у нас был конкретный этап разделения задач между разработкой и QA. И, конечно, у каждого специалиста должна быть своя зона ответственности. Но если мы сильно её ограничиваем, то создаём ситуацию, когда люди начинают только отвечать за свой кусочек и не смотрят за его пределы.
Как мы уже отметили, ключевая цель процесса разработки — делать качественный продукт для пользователей. Когда мы чётко разделяем границы ответственности, разработчики заняты на своём участке работы, а QA-инженеры — на своём. И здесь может произойти следующее. Разработчик подумает: «Окей, я сейчас напишу таску, пройду code review, отправлю её в QA. Дальше дождусь ответов и задеплою, если всё клёво, а если что-то не клёво, буду править. Но после этапа разработки мои полномочия всё». А у QA-инженера может сложиться ощущение: «Я сейчас забираю задачу с ready to test, работаю над ней и откидываю обратно в разработку».
Проблема заключается в том, что в такой системе случается пинг-понг задачами. У нас такое бывало. Разработка передаёт задачу в QA, QA её проверяет и возвращает разработке с багами. Разработчик правит эти баги, снова отправляет задачку в QA, а QA находит новые баги. В итоге вместо того, чтобы быстро пообщаться, найти точки соприкосновения и эффективно разрешить сложности, люди накапливают недовольство, а задачи зависают.
Старые неактуальные регламенты. Когда вы начинаете что-то делать на новом месте, то можете столкнуться с тонной регламентов, которые были написаны до вас. Причём может быть так, что большая их часть написана крайне скудно и только для людей, которые понимают, о чём идёт речь.
Например, у нас были регламенты, написанные за пару лет до внедрения свежих. Они содержали неактуальные данные по процессам, также там описывался flow работы с предыдущим TMS, с которого мы перешли на новое хранилище тестовых артефактов. В регламентах не хватало актуальных описаний новых инструментов тестирования и требований к тестовой документации. Это осложняло онбординг новых специалистов и вводило в заблуждение текущих. Держать в голове все нюансы большого проекта сложно — я бы даже сказал, невозможно, — и тут спасает актуальная документация.
Оценка задач разработкой. Часто в продуктовых командах, которые работают по Scrum, и где существуют свои QA-инженеры, в оценке задач в большей степени участвует разработка.
В команде мы начинали с того, что оценивали как разработку, так и тестирование задачи в одной сложности по complexity points. При такой истории разработчики не могут корректно заложить затраты на тестирование. А тестировщики, естественно, не могут заложить разработку. Происходит определённый диссонанс. Он преодолим: со временем всё притирается, и ребята начинают оценивать задачи плюс-минус похоже на правду, вы заводите какие-то эталоны для оценки, и это начинает работать. Но процесс всё равно непрозрачный.
Это плохо тем, что мы не понимаем, как распределяется нагрузка по разработке и тестированию. То есть не контролируем ресурсы команды: у нас есть абстрактная задача и ресурсы в общем виде. Это мешает качественно планировать спринты с учётом рисков отпусков, больничных, да и банально большого потока задач, которые легки в разработке, но сложны в тестировании.
Спринт хорош тогда, когда команда готова принять на себя обязательства по его закрытию и выполнению. А команда готова, когда она понимает, какие ресурсы у неё есть и сколько их потребуется для закрытия спринта. Чем прозрачнее процесс, тем трезвее команда оценивает риски и более готова их принять и/или смягчить.
Тимлид из разработки. Будем честны, чаще всего тимлидами становятся разработчики. И проблема здесь в том, что тимлид, который вышел из разработчиков, может по первости не чувствовать каких-то болей QA, которые есть в его команде.
Управленцу нужно понимать боли своей команды в целом, либо уметь их находить, собирать и обрабатывать. Если ты не видишь, не разделяешь, не учитываешь болей в коллективе, то коллектив может закрыться в позиции «мой руководитель меня не понимает», «он не представляет, каково мне работать», «руководитель не хочет нас слышать». Часто в таком случае пропадает честность и открытость в общении. Это приводит к разладу в команде и ухудшению коммуникации руководитель-сотрудник. Как следствие, у руководителя становится все меньше информации для эффективной работы.
Общие группы проблем. Если суммировать наши проблемы, то они подразделялись на две группы:
- Эмпатические.
- Эмпирические.
В первую группу входило то, что общая оценка задачи без разделение на разработку и тестирования вызывала неприятие разработчиков и тестировщиков, так как навязывала ответственность за оценку чужой области работы. Сотрудникам было сложнее коммититься на задачу и сроки её выполнения.
Эмпирическая же часть заключалась в том, что было сложно отследить capacity разных этапов — сложна ли задача в разработке или в тестировании. Это затрудняло планирование ресурсов команды и делало его непрозрачным. На старте спринта у нас не было точного понимания, что мы успеем сделать, — бывают случаи, когда за спринт сложно сделать задачу целиком и проще разделить её на разработку и тестирование. Плюс отдельная оценка тестирования позволяла бы точнее планировать ресурсы QA-инженеров, которые задействованы не только в тестировании конкретной юзер-стори, а ещё и в приёмке фичей, написании документации и автотестов, а также приёмке изменений платформы.
В 2020 году мы приступили к оптимизации процесса. Тогда у нас ещё не было ясной картины внедрения — просто было понимание, что мы хотим меняться.
Решение проблем
Чтобы переломить проблемную ситуацию, нужно поменять образ мышления команды.
Зафиксированные договорённости. Кажется, что все прекрасно знают, что разработка и QA — это части одного процесса. Но пока вы не зафиксировали эту договорённость на бумаге, не собрали всю команду, не пообщались и не произвели изменений изнутри, это знание, к сожалению, не всегда работает. Понимать команда всё понимает, но паттерны поведения остаются старыми.
Идея такая, что наш итоговый артефакт — это функционал в проде у клиентов, донесённая добавочная стоимость к продукту. Очень важно, чтобы все участники процесса разработки согласились с этим пунктом. После того, как этот пункт чётко засядет в головах у команды разработчиков и QA-инженеров, это задрайвит коммуникации. Человек, который чувствует себя частью команды и разделяет ценности этой команды, будет подключаться к решению проблем в процессных историях.
Прийти к единому пониманию помогает Scrum retro — встреча, на которую выносятся плюсы и дельты команды, и где принимаются договоренности о том, как с этим работать. Ключевой момент здесь в том, что новые договорённости не всегда легко приживаются, и нужно мониторить изменения. В среднем нужны 2-3 спринта, чтобы новые ритуалы стали привычкой.
Но бывают и более сложные ситуации. Например, если изменений требует квартальное планирование. Чтобы успешно внедрить и сделать традицией изменения, которые затрагивают процессы периодичностью в 3 месяца, может уйти до года. Да, внедрить обновлённый процесс можно прямо на следующем ритуале, но вот традиция зарождается с повторением. Это усложняет приземление изменений в процессах, рассчитанных на долгий цикл периода.
Актуальная документация. После фиксации договорённостей следует часть, которая не всем нравится. Нужно написать документацию: в идеале выкинуть все старые регламенты и написать новые. В документации точно нужны основные термины и описания для будущих поколений процесса, по которому мы работаем.
Базовые регламенты мы написали буквально за неделю. Не придумывали их с потолка, а просто собрались и договорились описать то, что уже есть. Занимался этим в основном я как руководитель: собирал информацию с разных членов команды и агрегировал её в документацию.
Чтобы проверить получившиеся регламенты, можно пригласить ребят из другой команды почитать их. В идеале коллеги должны понять, как что работает, и подсветить неочевидные изнутри пробелы. Цель — сделать так, чтобы человек со стороны мог прочитать регламент и сказать: «Окей, мне всё понятно».
Общий процесс. Для эффективной работы в новых процессах кроме договоренностей и документации нужна обратная связь. Обратная связь должна быть налажена как внутри команды, так и с бизнесом. Причём бизнес — немаловажная история. Если коммуникация с ним налажена хорошо, то мы можем чётко разрабатывать и тестировать фичи, можем менять требования к фичам на этапе оценки и проработки.
Всё ведёт к тому, что QA-инженер должен активно включаться с момента получения командой задачи на фичу. Как это работает у нас? Бизнес приходит с идеей нового функционала. Мы собираемся командой и брейнштормим: о чём этот функционал, что требуется для его реализации, какие есть подводные камни, как мы будем его проверять.
В итоге наши QA-инженеры могут делать черновики тест-планов с момента появления идеи функционала и груминга задачи. Когда разработчик получает задачу, QA-инженеры продолжают описывать тест-дизайн более подробно. Это позволяет начать проверять хэппи-кейсы, как только задача появляется в code review и есть какой-то готовый код, который работает в наших тестовых окружениях.
Поэтому дальше, когда задача после разработки переходит в QA, многие хэппи-кейсы уже будут пройдены в тестовом окружении. Между основными задачами тестировщиков на этапе ready to test и задачами в состоянии написания кода приоритет отдаётся первым. Поэтому сценарий работает, когда QA-инженеры не перегружены общей очередью на тестирование и у них есть возможность подключаться на code review.
Это упрощает коммуникацию: QA-инженер может обратиться к разработчику на моменте in progress, задать вопросы или прояснить определённые моменты, которые он нашёл в задаче. Для разработчика это тоже удобно: когда он решает задачу, у него уже есть понимание потенциальных проблемных мест, на которые следует обратить внимание.
Параллельный процесс решил дня нас проблему с пинг-понгом. В результате его внедрения практически повсеместной стала ситуация, когда с этапа тестирования в разработку возвращается всего порядка 10% задач. Это круто работает на мораль команды.
Бонус такого процесса в том, что он сохраняет контекст. Мы работаем с потоком задач. Разработчик берёт таски, потом передаёт их в тестирование. Пока QA-инженер тестирует эти задачи, разработчик берёт следующую задачу из пула. Ключевой проблемой пинг-понга является именно изменение контекста, потому много времени тратится, чтобы выйти из своей текущей задачи и вернуться в контекст той, которую ты делал неделю назад. Именно поэтому и QA-инженер и разработчик должны работать совместно на протяжении всего жизненного цикла задачи.
Роль тимлида. Тимлиду нужно учиться понимать боли всех участников процесса и работать с ними. Моя рекомендация для новичков в этой роли: если вы заступаете на должность руководителя команды, то посмотрите, что уже есть, пообщайтесь со всеми ребятами, узнайте, какие договорённости были до вас. Это поможет не напороться на какую-то ловушку, о которой вы даже не знаете.
Особенное внимание уделите той части процессов, с которой вы не очень знакомы. Допустим, если вы были разработчиком в прошлой жизни, то посмотрите в сторону тестирования. Если вы были тестировщиком — в сторону разработки. Попробуйте разобраться в том, как работают ребята в команде, встать на их место и понять, чем вы можете им помочь.
До и после: как изменился процесс
Внедряли изменения мы довольно быстро, потом собирали обратную связь на ретро и дорабатывали процессы в случае неудачи. Процесс в том виде, в котором мы хотели его видеть, организовался буквально за один квартал. Но перед нами также стояли задачи изменения подходов к квартальному планированию и к оценке ресурсов команды: менять их мы могли в среднем раз в квартал, и поэтому получилась большая петля обратной связи и реакции. Общая трансформация процессов заняла примерно год.
В итоге всё неплохо получилось, потому что все в команде хотели меняться. Без этого желания вряд ли что-то получится. Мы поправили процессы, изменился наш образ мышления. Мы зафиксировали новые ценности и стали работать эффективнее.
До изменений
После изменений
Активное подключение QA после Review.
Активное подключение QA на этапе Grooming.
Оценка задачи включает разработку и QA.
Оценка задач разделена. QA закладывает тест-кейсы автоматизации и полный цикл работ.
Единая оценка задач вызывала напряжение у разработчиков, а также скрывала пласт работ QA.
Поняли, что для нас важна доставка кода до прода, что сняло напряженность в общении между QA и разработкой.
Проблемы в коммуникации разработчиков и QA-инженеров.
Зафиксировали новые ценности команды, что сняло проблемы в коммуникации.
Порядка 30% задач могли возвращаться с уточнением требований.
Возвращается не более 10% задач со сложной бизнес-логикой.