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

Мы - два сотрудника Ростелеком ИТ Алешин Алексей и Сердюк Нэлля. Наши проекты — большие порталы по видеонаблюдению на государственных мероприятиях (Единый день голосования, Единый государственный экзамен).

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

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

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

Анализ

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

Сейчас на первом этапе за работу берутся наши команды менеджмента и анализа. Их задачей является:

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

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

На выходе у нас появляется страница в Confluence с описанием пожеланий заказчика по новому функционалу или доработкам текущего. На каждый блок доработок заводится отдельная страница. После чего назначается ответственный аналитик для проработки данных изменений. В результате проработки аналитик выделяет одну или несколько user story и описывает технические задачи для достижения нужного результата. В команде анализа есть практика перекрестного ревью готовых задач для проверки внутренних требований к конечному результату. У команды аналитики есть чек‑лист, по которому они проверяют, как должна выглядеть user story, заполнение лейблов и визуализация макета фронтовой задачи. Важным элементом является логичное разделение «хотелок» на стори и дальнейшие задачи. Так как в случае, если задачи будут слишком большие или, наоборот, очень маленькие — это может принести множество проблем на этапах их реализации. Что‑то не реализовали, или разработчик просто потерял суть фичи в огромной задаче на несколько листов.

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

Grooming

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

Для нас груминг — это общая встреча команды для понимания будущих изменений. Задачи для будущего груминга аналитик скидывает в общий чат. Так команда сможет с ними ознакомиться и прийти на встречу уже с базовым пониманием области изменений, своими вопросами и предложениями. Есть похожая практика, которая называется «3 Амиго». В рамках нее лиды или ответственные конкретно за эту доработку специалисты собираются вместе для обсуждения будущих задач. У нас на проекте специалисты одной области работают без конкретных привязок к кускам функционала, поэтому в груминге участвуют все члены команды (бэкенд, фронтенд, qa и тд). В рамках этой активности аналитик рассказывает про будущие доработки и свой план, как это может выглядеть. В процессе могут задаваться вопросы, вноситься коррективы, которые аналитик по результатам встречи добавляет в задачи.
В результате мы получаем готовые к разработке задачи, с которыми команда уже знакома и готова брать в работу. Таким образом, все требования, которые выставляет заказчик, понятны всем членам команды.

Разработка

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

Unit тесты и их улучшения. Ими покрыта существенная часть бэкенда, что добавляет уверенности при рефакторингах и помогает не допускать большого количества ошибок при проверке функционала. Но для улучшения качества покрытия команда тестирования проводила крекеры по техникам тест дизайна для команды. Крекерами в нашей компании называют небольшие митапы на различные темы.
Тестирование на машине разработчика. Этот шаг мы используем в основном для фронтенд задач. Разработчик может попросить посмотреть результат своей работы qa, менеджера или аналитика. В рамках такого 5-ти минутного теста другой сотрудник новым взглядом может посмотреть на результат и базово оценить результат. Это позволяет разработке, не выходя из контекста решаемой задачи, исправить недочет и отдать задачу уже на полноценное тестирование. Смена контекстов является довольно затратной операцией как по времени, так и по энергии. Поэтому важно уменьшать количество таких моментов. В рамках этой активности примерно в каждой третей задаче находились какие‑то неточности, которые сразу устранялись.
Code review. Это довольно стандартная инженерная практика, но у нас есть пара особенностей. В код ревью участвует вся команда, а не какие‑то выделенные роли. Это позволяет всей команде понимать, что делают остальные, быть в контексте изменений и повышать свой уровень за счет решения более опытных коллег. Также мы иногда практикуем варианты, когда вся команда совместно смотрит сложные куски изменений для более качественной проработки конкретного решения.

Тестирование

После попадания задачи на этап тестирования на неё в нашей системе хранения тестов пишется чек‑лист с необходимыми проверками. Это позволяет структурировать подход к тестированию, например, понять, что нужно проверить дополнительно, если задача возвращалась обратно в разработку. И эти чек‑листы пригодятся нам в будущем. Замечу, что мы не пишем чек‑листов / тест кейсов до этапа тестирования. По нашему опыту это неэффективно по затратам ресурсов.

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

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

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

Если все задачи внутри user story успешно прошли проверку — на команду тестирования переставляется отдельная задача на написание регрессионных тестов в наш тест трекер. Это необходимо для будущих проверок функциональности.

Тут нам и пригодятся чек‑листы, которые мы писали при тестировании каждой задачи. Исходя из них, будет быстрее и проще сформировать новые тест кейсы для всей user story.

Мы стали создавать отдельную задачу в Jira на тест кейсы, так как раньше мы забывали/откладывали обновления тестовой документации. Это иногда приводило к печальным последствиям. Представьте, вам нужно собрать тест ран для прогона по какой‑то фиче, а тесты со старой информацией внутри или их просто нет. История неприятная и требующая дополнительных временных затрат с решением прямо сейчас. Для избежания таких ситуаций просто заводим на это отдельную задачу еще на этапе формирования user story. Ее выполнение будет индикатором выполненной работы.

Теперь мы предполагаем, что новый функционал работает так, как мы ожидали. А для проверки старого у нас есть автоматизированное тестирование. Мы стараемся покрывать основной функционал и сценарии автоматизированными проверками. Для этого в нашей команде есть отдельный специалист, который занимается api и ui тестами. Он кстати использует тест кейсы, которые команда обновляет в процессе проверок сторей. Поэтому после обновления задача по написанию регрессионных тест кейсов попадает к нему для анализа объемов доработок автотестов. Наличие автотестов помогает нам не делать глобальных регрессов системы после каждого релиза. Мы смотрим лишь основной функционал и моменты, которые изменились в текущем релизе. Релизы чаще всего небольшие: 10–15 задач. На проверку изменений на внешних окружениях у одного специалиста может уйти 1–1,5 часа максимум. При этом пользователи не замечают, что был релиз, и могут дальше пользоваться порталами без каких‑либо ограничений.

Документация

Многие не любят ее писать, но рады когда она есть на проекте

По завершении реализации user story отдельной задачей оформляется/дополняется страница в Confluence по результатам изменений. Текстовым наполнением занимается наш технический писатель, который проделывает существенную работу по сбору всей информации и ее переносу в итоговую документацию. Этот технический писатель сотрудничает не только с нашим проектом, а помогает всему направлению. Это позволяет ей лучше понимать архитектуру, термины и быть в курсе работы системы. При этом для ускорения процесса техпис в том числе использует «итоговые комментарии» для детального описания задач. В статье обычно описывается итоговый вид функционала с описанием возможностей и параметров использования. Раньше этим тоже занимались ребята с этапа тестирования. Но как и с тест кейсами, были случаи когда не хватало времени и усидчивости для выполнения, кажущихся, второстепенных задач.

После написания статья передается команде тестирования на проверку. Казалось бы, зачем передавать написанную статью на еще одну проверку в тестирование, но:

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

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

По итогом выполнения всех задач в user story (технических + тест кейсы + документация) сама сторя тоже проходит проверку тестированием и командой анализа. Это этап сверки ожидания в начале и конце реализации. И бывали случаи, когда аналитик, посмотрев на конечный результат, возвращал задачу на доработку или заводил мелкие баги. Это случалось, когда реализация задачи не соответствовала желанию заказчика даже несмотря на то, что при описании старались учесть все требования. Но в процессе кто‑то что‑то понял не совсем так, как нужно.

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

Общение

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

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

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

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

И почти сразу же было введено еще одно правило — «Одна проблема — один тред»
Команда, отвечая на вопрос, создавала ветку (тред), в которой продолжала общение по этому вопросу. Так другие члены команды были в курсе, что обсуждается, но если их это непосредственно не касалось, перестали отвлекаться на процесс обсуждения. При этом ссылкой на такой тред всегда можно поделиться с любым членом команды, чтобы ввести в курс дела. Это как ветка форума, в которую легко вернуться в любой момент, перечитать сообщения и быстро вникнуть в суть.

Вместо итога

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

Сложно выделить главный фактор из тех, что мы описали. Но каждый из них внес свою лепту в итоговый показатель. И это только внешний показатель. Многие новички, кто приходят сейчас в команду, отмечают полезность многого, о чем мы говорили, и удивляются, почему они не встречались с этим раньше, хотя эти шаги простые в исполнении, но имеют положительное влияние на конечный продукт. Этому способствует четкая релизная политика без деплоев по пятницам. Количество овертаймов и доработок по выходным снизилось по сравнению с периодом два‑три года назад. Это ли не чудо:)

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

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

Продукт, который можно «пить»