Всем добрый день!

Меня зовут Иван Хахарев и я работаю ведущим системным аналитиком в команде WEB Campaign, это внутренняя разработка Спортмастера для формирования маркетинговых логических цепочек. Я в команде уже полгода, и на момент моего прихода ребята уже почти год двигались к веб-версии. В команде на текущий момент семь человек, трое из которых — разработчики. 

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

Кратко пройдемся по списку

Летучки у нас проходили каждый день, три раза в неделю мы делали их со всей командой из 18 человек. Успешно внедрили декомпозицию — делили задачи после написания ТЗ для разработчиков. Раз в неделю проводились анализы дефектов, чтобы их приоритизировать и быстро разгрести, были встречи по пополнению вместе с бизнесом, где мы отбирали задачи на неделю, был внедрен процесс пополнения бэклога — сами аналитики заводили задачи в Jira. Мы смогли выстроить «Поток поставки ценности», где было видно, как задача появляется, прорабатывается и поставляется на прод. 

Добрались до разделения задач на размеры, у нас были регулярные ретроспективы, которые проходили в разных форматах, ввели достаточно большое количество метрик, в том числе возраст нашего бэклога. Было разработано несколько шаблонов ТЗ, которые помогали оперативно писать задачи. Кроме того, были введены Definition of Ready (условия, при которых задача готова к тому, чтобы ее взяли в разработку) и Definition of Done (условия, при которой задача считается выполненной).

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

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

Определяем ключевые проблемы системы. 

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

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

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

Решил зафиксировать цели, с которыми в дальнейшем продолжил работать:

• Необходимо сформировать шаблон ТЗ и описать весь функционал. 

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

• Повысить прозрачность работы над задачами. Мне нужно знать, кто и что в какой момент делает.

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

Я предположил, что логично будет начать с документации — надо посмотреть, чего не хватает, проанализировать уже сделанное и зафиксировать это. Сделал первый шаблон ТЗ и начал описывать. Через пару попыток я понял, что во многих местах упираюсь в тупик. Очень быстро возник вопрос: стоит ли начинать с документации? Стало ясно, что сейчас этим заниматься рано, тогда решил начать именно со списка мероприятий. 

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

Начинаем налаживать синхронизацию. Для этого добавляем в ритм жизни команды Летучки (Daily)

Решили проводить их три раза в неделю по полчаса. Тем самым процесс синхронизации проходит именно там, а на встречах по проектированию мы этим больше не занимаемся, выиграв от 20 до 30 минут на обсуждение самого проектирования.

Выбор вопроса. Мы внедрили страницу «Горячих вопросов», где начали фиксировать все вопросы по приоритетам и фиксировать, о чем договорились или на чем остановились. Это позволило нам не тратить время на выбор вопроса в начале встречи, а сразу переходить к сути вопроса. 

Благодаря всего лишь двум этим мероприятиям мы выиграли до 40 минут времени на чистое проектирование и раскидали две трети вопросов за ближайшие 2-3 недели.

Поток и Jira

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

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

После этого мы переходим к процессу декомпозиции, который представляет из себя презентацию проанализированного функционала. Мы собираемся всей командой и объясняем, зачем это делается, как это должно работать, что с этим происходит и так далее. Затем мы в онлайн-режиме с разработчиками собираем основные артефакты, например, какие нужны API, есть ли какие-то проблемы бизнесового характера и так далее. На выходе после этой встречи, как показывает практика, будут закрыты 95% вопросов. Таким образом, задача в дальнейшем не застрянет уже по какой-то интеграционной проблеме или по причине отсутствия ответа от бизнеса. Тем самым точно дойдет до прода.

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

Такая схема легла в основу. Она была понятна по старой команде и на 90% укладывалась в новую. На выходе у меня получились следующие типы задач:

• Эпики были только для бизнеса;

• Задача — основной тип, в рамках которого ведется разработка функционала;

• Документирование — техническое описание, отдельные работы, которые могут идти фоном;

• Анализ и проектирование — техническое исследование. Мы оставили его в качестве запасного на случай, если где-то нужно провести исследование для разработчиков;

• Автотесты бегут по своей дорожке и могут делаться в своем темпе;

• Проектирование — задачи для аналитиков;

• Дизайн для дизайнера;

• .Разработка ПО — единственный тип подзадачи для разработчика.

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

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

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

В моем понимании, надо сперва определить шаблон ТЗ. На то есть несколько причин:

• Шаблон ТЗ позволяет уницифициовать подход к описанию — все пишут одинаково.

• Позволяет однотипно структурировать подачу информации. Все понимают, какой объем нужно смотреть и как с этим работать.

• Выполняет функции чек-листа, что позволяет не терять какие-то блоки.

• Является единым местом правды, из которого можно понять, почему так работает функционал.

Вот примеры того, как выглядит шаблон по разделам. (слайд 25.25)

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

Дальше мы вытягиваем все связанные с Jira задачи. История доработок —           наша попытка вести какое-то логирование. Так как доработки описываются в рамках этого же ТЗ, то можно сразу писать всю информацию об истории доработок, что сильно облегчало работу тестировщикам. (слайд 26.18)

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

Далее мы начинаем работать над отображением. То, что сделано в Figma, прикрепляется ссылкой справа, слева же мы делаем статический макет — выбираем ключевые формы и обозначаем их. Снизу в таблице описываем каждый обозначенный элемент этого макета: расписываем тип объекта, что сильно помогает при переводе на другой язык, тип поля, статус поля и описание. (слайд 26.50)

После идет раздел со статусными моделями. Если есть какая-то форма, в которой кнопки остаются, но могут менять свое состояние в зависимости от статуса, то описывается простая матрица, в которой мы указываем, почему эта кнопка недоступна для редактирования или доступна в зависимости от статуса.  (слайд 28.12)

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

Последний пункт — тест-кейсы для тестировщиков, в нашем случае их пишут аналитики. 

Мы пишем тест-кейсы, потому что был момент, когда члены команды потеряли он важный бизнес сценарий из  ТЗ и поставили без него на прод. В этот момент мы поняли, что должны быть какие-то тест-кейсы для обязательной проверки. Дальше тестировщики могут добавить еще свои проверки на валидность, на числа и тому подобное. (слайд 29.11)

Итого, мы ввели летучки, появилась декомпозиция. После того как мы выстроили поток, появились шаблоны ТЗ, а также отпала необходимость использовать чек-листы, потому что шаблоны ТЗ нам это перекрывают. Добавлю про структуру документации, потому что это достаточно полезная тема. Мы долго искали вариант, как формировать структуру описания тех. заданий, и поняли, что надо отталкиваться от интерфейсов. Кроме того, все дочерние функционалы пишутся дочерними страницами. Допустим, есть формы выгрузки в Excel и отправки обратной заявки, которые вызываются по кнопке, и список заявок. Список заявок пишется в основной странице, а в дочерней странице будут выгрузка в Excel и отправка обратной связи. Отмечу, что доработки мы ведем в рамках оригинальной страницы на первоначальную разработку.

Разберем пример одной из наших структур. 

Есть общий раздел — ТЗ на объект Образцы, блок «Список заявок» и дочерние «Выгрузка списка заявок», «Список фильтров», которые возможны по этим заявкам, «Уведомления по заявкам», которые также относятся к этому списку, но не влияют на его построение; «Форма истории RFC» и «Форма создания RFC». Последние представляют из себя два поп-апа, которые вызывались кнопками, относились к этому списку и косвенно с ним взаимодействовали, но на построение списка не влияли. (слайд 32.03)

Итоги

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

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