Надежда Мецкер, Senior QA, DataArt

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

Первое, о чем я расскажу, это Feature Demo — процесс, в ходе которого мы демонстрируем новый функционал приложения внутри своей же команды. Мы рассматриваем, как именно он был сделан, что получилось особенно удачно, а где можно было сделать лучше. Уже после общего рассмотрения и окончательного одобрения функционал может уходить в продакшн.

Команда растет

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

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

Особенности проекта

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

Проект делится на две части, одна — Budget Tool (BT) — более динамичная и составляет 2/3 нашего приложения. Сюда мы вносим параметры и участников эксперимента, там же находятся все требования заказчиков, которые хотят протестировать лекарство. Спецификация активно заполняется, после чего выводится бюджет — конкретная сумма: сколько будет стоить исследование при определенных условиях.

Вторая часть проекта — Budget Tracking Tool, которая в большей степени содержит статическую информацию и фактически представляет собой отчет об исполнении плана, составленного в BT.

Особенность работы системы заключается в количестве внутренних зависимостей. Различные параметры ссылаются друг на друга, их взаимодействие определяют очень длинные формулы (поля у нас позволяют вводить до 5000 знаков, хотя реальные формулы несколько короче), и потеряться в таком потоке достаточно легко. В первой динамической части было проще, сложнее обстояло дело со статистикой. Если в BT какая-то фича оказывается недоделанной, в BTT информация попросту не приходит. И пока бэкенд-команда ищет, что же было упущено, QA-команда вынуждена сидеть и ждать новостей. Затем она может повторить тест и вновь обнаружить баг — такое бывало, процесс даже мог быть увлекательным, но отнимал время. Мы понимали, что нужно работать быстрее, но деться от этих зависимостей никуда не могли.

Планирование и сроки

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

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

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

Workflow Feature Demo

Для начала мы решили признать: каждый не может быть в равной степени вовлечен во все, что делает команда. Зато мы можем разделить ее на части с собственными задачами. Такой задачей может быть, в том числе, разработка отдельной фичи.

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

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

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

Закрепленный за маленькой группой QA приступает к работе морально подготовленным. Он хорошо знаком с требованиями, знает, как работает приложение, что сделали разработчики. Когда тестировщик закончил, бизнес-аналитик показывает результат работы заказчику.

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

Польза Feature Demo

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

Support Activity

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

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

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

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

Первый блин комом

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

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

Мы прикрутили большую красивую синюю кнопку Report an Error на каждой странице. При нажатии на нее нашей команде уходило письмо. Но реакции пользователям все равно приходилось ждать, иногда час, иногда два, а иногда еще дольше. Что делать, если таких писем разом пришло 50 или 100? Отдельных людей, занятых поддержкой системы, изначально у нас не было.

Мы добавили кнопке дополнительную функцию: она не только отправляла письмо, но и создавала для нашей команды приоритетную задачу в Jira, а пользователь получал уведомление, что задача по его комментарию взята в разработку. Однако оставалась проблема: переключаясь на задачу по поддержке, мы теряли в активной разработке.
Тогда мы создали отдельную команду поддержки, выделив для этих задач половину бэкенд-разработчика, одного фронтенд-разработчика и одного QA. Разумеется, речь не о конкретных людях, а о человекочасах. Т. е. условный дежурный сразу начинает выяснять, в чем заключается проблема, действительно ли обнаружен баг и начинает с этим разбираться. Такая реформа позволила нам фиксить 10–15 проблем в неделю и по мере накопления сразу выгружать их в рамках промежуточных релизов.

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

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