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

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

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

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

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

0. Формирование команды

Всё начинается с создания команды, в которой много ролей и каждая роль в дальнейшем будет расписана в рамках workflow. Тут важно построить реальную матрицу ответвенности RACI (можно скриншот, как пример приложить) и собрать основу команды, которые в дальнейшем и будут её расширять, принимать решения о приёме специалистов в команду. Основа команды это владелец продукта или куратор проекта, руководитель проекта, архитектор, тимлид и лиды по направлениям (в зависимости от задач, которые необходимо решать, могут быть лидер аналитики, тех. лид по backend, тех. лид по frontend). QA специалисты входят в команду, но у них другие цели и результаты. Это отдельная большая тема, которая тесно связана с понятием «готовности» ПО )). После формирования основы команды и ряда организационных встреч, на которых решаются глобальные вопросы по срокам, целям, мотивациям, ожиданиям, начинается процесс набора в команду специалистов, так сказать внутренние собеседования. Да, у нас в компании есть отдел разработки, есть свободные ресурсы или ресурсы, которые в ближайшее время освободятся, есть отдел HR, которому можно сбросить требования и он будет искать подходящие ресурсы. В итоге есть кандидаты на роли в команду, и проходит собеседование, в котором участвуют лиды (РП, архитектор, тим.лид, тех. лиды), после собеседования каждый оставляет свою оценку кандидата, а РП принимает окончательное решение о включении специалиста в команду и о его роли. НО, у каждого специалиста есть право вето, если по каким либо причинам кандидат не устраивает, то можно наложить вето и тогда кандидат точно не войдёт в команду. Да, команда может формироваться или изменяться по всему жизненному циклу, можно подключать ресурсы по мере необходимости, но нужно учитывать процесс внутренних собеседований, и время на выделения ресурсов и их занятость в других проектах.

т. е. чётко выделяется костяк (основа) команды, которые берут на себя ответственность за результат, а остальные специалисты закрывают чётко поставленные задачи.

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

1. Сбор и анализ требований

После формирования команды, первым этапом идёт «анализ». Каждый под этим словом понимает разное, кто то бизнес анализ и формирование требований, кто то системный анализ и проектирование UI, АПИ, БД.

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

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

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

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

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

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

• Пользовательские сценарии. Тут очень помогает QA, идёт полное описание всех возможных кейсов при работе. Каждый кейс имеет детальные шаги со ссылками на экранные формы. Идёт описание альтернативных потоков.

• АПИ — детальное описание всех API, которые используются в логике и на прототипах. Описываем входные и выходные параметры, их коды, типы, возможные значения. Также описываем сущности по oData, которые доступны для работы.

• БД — проектирование БД, детально до полей, типов и связей.

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

Самое ценное в этом workflow это этап согласования, которое позволяет повысить актуальность аналитики в разы и довести её до полноценного готового документа постановки для разработки. В процессе согласования участвуют следующие роли:

1. Аналитик — пишет аналитику и отвечает за её актуальность в дальнейшем

2. Архитектор — ключевая роль, с архитектора начинается работа. Как правило, архитектор погружается в задачу, проводит границы, рисует схемы и только после этого проводит демо для всех участников по задаче. В рамках демо всё детально рассказывается, задаются вопросы. Цель, сформировать у команды единую точку зрения.

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

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

Процесс следующий, архитектор делает проработку, проводит демо, далее аналитик формирует ФТ, по готовности переводит на согласование (мы называем это круги согласования), после первого круга появляются замечания, аналитик их изучает и собирает всех на встречу, далее устраняет замечания и переводит на новый круг согласования. Вот таких кругов по началу у нас было до 8, времени уходило уйма, аналитики были в бешенстве. Но через пару месяцев все поняли, что и как нужно описывать, начали актуализировать стандарт, обогатили стандарт примерами и шаблонами, организовали курсы обучения. В итоге у нас в среднем 2–4 круга согласования. В согласовании очень помогает механизмы конфлюенса, где каждый оставляет свой комментарий, далее по нему идёт переписка, и у нас правило, что только автор может закрыть свой комментарий. Пока все комментарии не закроются, аналитика считается не согласованной. Мы считаем это ключевым процессом, который помог нам выйти на новый уровень разработки и описания задач.

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

3. Разработка

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

Итак, разработка начинается после демо аналитики, где каждый разработчик может задать вопросы и погружается в небольшой функционал. Для общения с аналитиком создаются отдельные чаты, группы. Тут начинается основная работа тех. лидов, которые после демо делают детальную декомпозицию и заводят задачи на разработку. Все задачи связаны с историей, в которой прописываются все ссылки на конфлюенс, т. е. каждый разработчик всегда имеет под рукой детальное описание. После декомпозиции начинается процесс оценки задач, мы используем для этого Jira, там есть возможность подключить покер. Оценка занимает от 4 часов до пары дней, тут важно при разбросе оценок выслушать крайних, почему они так разошлись, в итоге оценки приходят к одному значению, выбирается среднее значение. Да, если оценки превышают 30–40 часов, то обычно бьём задачу на более мелкие. Плановые оценки очень важны, т.к. позволяют поддерживать процесс в оперативном режиме и заранее спланировать загрузку ключевых специалистов. Каждый день проходит дейли, где РП внимательно следит за оценками и статусами. Важно заметить, что в оценку входит не только разработка, но и написание юнит тестов, внутреннее тестирование самим разработчиком и багфикс. Да, время на исправление багов будет списываться в исходную задачу и учитываться как багфикс. Это нам помогло значительно повысить качество кода и прийти к нормальному пониманию «готовности» ПО. Workflow у задач разработки отдельный, разработан с учётом специфики Git и участием QA специалистов. После завершения разработки разработчик формирует MR (merge request в GIT) переводит задачу на тех. лида, который проверяет код согласно кодстайлу, также проверяет его корректность. Это так сказать первый фильтр, далее, если всё хорошо, задача уходит в ожидание тестирования. И важно, что перед этим делается accept MR в GIT и код уходит в ветку тестирования, автоматически попадает на тестовый стенд. Далее подключаются QA специалисты, которые проверяют насколько разработанный функционал соответствует требованиям и проходит ли все утверждённые use case. Тут могут быть нюансы, например, для тестирования задачи нужна готовность других задач, т. е. тестирование будет проходит комплексно, поэтому у нас появился отдельный статус задачи с ожиданием тестирования. После тестирования, если нет замечаний, то задача закрывается и переходит в статус «готова». Но это редко бывает с первого раза J, поэтому обычно задачи возвращаются в разработку с указанием комментариев и результатов тестирования. Важно, что всё время должно фиксироваться в одной задачи на разработку, в дальнейшем РП получает детальный отчёт, где проводится анализ плановой оценки, фактической и% багфикса по каждому разработчику.

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

4. Тестирование (QA)

После завершения разработки всей исходной истории, наступает звёздный час QA специалистов. Они уже начинают проводить комплексные тесты, покрывать автотестами написанный код. Для этого в JIRA создаются отдельные задачи на QA, по результатом этих тестов уже появляются баги, отдельные задачи, которые попадают в бэклог и далее стандартный механизм распределения через Тим. Лида. После декомпозиции и оценки задач у нас подключается Тим. Лид, который распределяет задачи между разработчиками и формирует роудмап на спринт. После устранения всех багов проходит MR на стейдж, считаем, что версия ПО у нас готова.

С одной стороны всё банально и просто, но с другой есть нюансы, которые и помогли нам достичь баланса. Если не тратит столько сил на аналитику, то не будет нормальной постановки, а это приведёт к ошибочным оценкам разработчиков и весь процесс сломается. Либо, пропустить этап оценок или сделать его некачественно, тогда вся аналитика будет испорчена и РП не сможет качественно реагировать на процесс и принимать решения. Еще год назад вот такие вопросы очень часто обсуждались на оперативных совещаниях перед дедлайном — «а давайте сократим автотесты», «может быть не будет дождаться архитектора из отпуска, обойдемся без него при согласовании аналитики» и т. п. Сейчас подобные мысли даже не приходят в голову. Понятно, что на этапе внедрения workflow разработки у вас будет этап когда вы потратите больше времени на организацию работы, но это 100% окупится в будущем сокращением работы на исправление фатальных архитектурных и системных ошибок, поэтому на первом этапе обязательно вовлекайте команду в процесс, рассказывайте что и для чего делается, к какому профиту приведет в будущем. Нюансов много, и данный процесс требует творческого подхода, чтобы он запустился, главное, не отступать от стандарта, и если из‑за дедалайнов очень хочется срезать углы не сворачивать с праведного пути и тогда по мере накапливания опыта вы создадите свой стандарт и постепенно научитесь применять этот процесс в потоке и на аутсорсинге.

5. Ретроспектива

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

6. Вместо послесловия

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