Как построен процесс утверждения тасков с клиентом
Сегодня мы с вами поговорим о том, как происходит получение, распределение, утверждение и выполнение задач в нашей компании. На первом этапе заказчик совместно с нашим менеджером определяет команду разработки. Такая команда формируется по требованию заказчика и в зависимости от нужд проекта. Как правило, команда разработки состоит из бизнес-аналитика, тимлида, проджект-менеджера, фронтенд разработчиков, бекенд разработчиков, дизайнера и тестировщика.
На первом этапе, когда полная команда разработки сформирована, необходимо проверить доступы к проекту и ко всем ресурсам, которые необходимы для стабильной и продуктивной работы. На втором этапе нам необходимо получить задание от заказчика. Задание формируется на этапе непосредственного общения с заказчиком. Сначала бизнес-аналитик и проджект-менеджер обсуждают с заказчиком его видение на продукт и сроки выполнения работ. На данном этапе бизнес аналитик обсудит и расскажет, как лучше со стороны бизнеса выполнить задачи, которые заказчик хотел бы видеть в своем веб приложении. Далее бизнес-аналитик на встрече с проджект-менеджером обсудят задание клиента и разделят его на определенные задачи для команды разработки. Затем это задание обрабатывается бизнес-аналитиком и проджект-менеджером. Они составляют план разработки, описание проекта и первоначальную документацию.
На этапе составления документации наша компания в лице проджект-менеджера и тимлида разрабатывают документы, в которых содержатся основные этапы разработки. В первую очередь описывается, как будет происходить процесс разработки, а именно, как будет происходить доставка задач заказчику, как будет происходить распределение задач в команде и как будет проводится ревью написанного кода. Также на этом этапе наша компания составляет диаграммы разработки. Диаграммы разработки отображают структуру приложения, также по ним объясняется весь путь прохождения пользователем по всему приложению. Диаграммы относятся к предмету проектирования веб приложения, которое как раз и описывает весь процесс создания и мануал пользования готовым веб приложением.
В качестве Agile (гибких) методологий наша компания использует Scrum и Kanban методологии. На большинстве проектов применяется Scrum подход. Это значит, что проджект-менеджер или бизнес-аналитик заполняют беклог проекта, где находятся все задачи, которые необходимо выполнить во время реализации продукта. Следующий шаг - это установка временных промежутков (обычно это одна, либо две недели) в этот период времени команда разработки выполняет задачи и закрывает спринт, а после этого назначается дата проведения демо заказчику по проделанной работе за этот спринт.
На этапе построения диаграмм наша компания предоставляет заказчику два типа диаграмм. Первая - это sequence диаграммы, в которых будут показаны основные этапы моделирования взаимодействия объектов. И вторая - это диаграмма вариантов использования, в данном виде диаграмм описывается путь взаимодействия пользователей с системой.
Данные диаграммы помогают не только заказчику разобраться в продукте и оценке его ожидания от продукта, но также и команда разработки будет следовать этим документам и не отклоняться от поставленных задач и флоу проектируемого веб приложения. Также такой вид взаимодействия между пользователем и системой, который описывается в диаграммах, поможет на этапе разработки создать именно такой продукт, который был первоначально заказан клиентом.После утверждения и предоставления заказчику и команде документации к выполняемому проекту, а также ознакомления заказчика с созданными задачами, начинается процесс разработки продукта командой разработки. Формируется спринт и выбираются скоуп задач на спринт. После этого начинается процесс создания прототипов и дизайна, который в дальнейшем будет утвержден с заказчиком и реализован командой разработки. Создается репозиторий для бекенд и фронтэнд части приложения. Также происходит установка необходимых зависимостей и библиотек, настройка CI/CD, создание инвайрементов для продукта (девелопмент и production). После того, как реализована непосредственно задача, которая содержит в себе функциональную часть и соответствует макету дизайна, открывается пулл реквест (пулл реквест - это этап, когда разработчик закончил выполнение задачи и готов предоставить свои наработки компетентному специалисту, который просмотрит написанный код. В случае возникновения каких-либо замечаний, разработчик поправит их.). После этого пулл реквест проходит процесс слияния, а именно в стадии разработки у проекта существует несколько сред разработки проекта, зачастую это development и production. После того, как разработчик закончил выполнение задачи, он отправляет свои наработки непосредственно в development. После того как задача будет выполнена разработчиком, и наработки будут отправлены в development, то наступает этап тестирования задачи, после которого данная задача уже отправляется в production, где ее также может увидеть заказчик.
После того, как заканчивается спринт, и реализованные задачи попали в production, производится показ выполненных задач тимлидом или проджект-менеджером заказчику. После проведения демо заказчик может увидеть, на каком этапе находится реализация продукта, высказать идеи и конструктивную критику, если таковая имеется. После этого проводится спринт ретроспектива, в которой участвует вся команда разработки и делится своими впечатлениями, либо высказывает мнение об улучшении этапов разработки. Далее наступает этап оценки и взятия задач в новый спринт, по завершении которого происходит весь описанный выше процесс.
В заключении хотелось бы отметить, что залог успешного проекта - это правильно выбранная компания, которая предоставит полный цикл разработки любого продукта, предоставит краткое руководство о пользовании и поддержании уже реализованного проекта. Хотите работать с нами? Заполните форму обратной связи https://www.it-justice.com/contacts . Спасибо за доверие! Мы свяжемся с вами в течении 2-х часов.
