Хабрахабр

Как не сойти с ума от Scrum? Опыт растущего проекта

Надежда Мецкер, 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, для них создают отдельный чат, куда при необходимости добавляются и лиды.

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

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

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

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

Польза Feature Demo

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

Support Activity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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