# Проблемы процессов и их решения ## Мотивация В результате проведенной ретроспективы наша команда пришла к выводу, что мы испытываем определенные трудности в работе. Я подготовил документ, в котором выписал проблемы и предложил пути их решения. ## Цели Результатом работы над командными процессами должены стать: - [Проблемы процесса разработки](#Проблемы-процесса-разработки) - - [Постановка задачи](#Постановка-задачи) - - [Требования к коду](#Требования-к-коду) - - [Требования к тестам](#Требования-к-тестам) - - [Требования к документации](#Требования-к-документации) - - [Требования к инфраструктуре](#Требования-к-инфраструктуре) - - [Процесс ревью](#Процесс-ревью) - - [Процесс деплоя](#Процесс-деплоя) - - [Поддержка](#Поддержка) - [Поэтапный план внедения процессов](#Поэтапный-план-внедения-процессов) ## Проблемы процесса разработки ### Постановка задачи В данный момент процесс постановки задачи является довольно разнородным: - Задачи могут поступать из чатов. - Мы можем договариваться устно. - Иногда мы вообще не регистрируем задачу в таск-менеджере. Текущая практика не идеальна, поскольку команде не ясна нагрузка на конкретного разработчика, и основной фокус команды теряется. Для решения этой проблемы предлагается регистрировать задачу в таск-менеджере для каждой поступающей заявки. Задачи больше не должны поступать из чатов; вместо этого задача должна быть зарегистрирована в таск-менеджере. Хорошим примером служит подход команды DevOps. #### Как должна быть оформлена задача Необходимо внедрить стандартизированный шаблон для оформления задач, который будет служить не только средством облегчения процесса для нас, но также станет полезным инструментом для лица, создающего данную задачу. Задача должна быть выполнена только при условии, что она соответствует установленным стандартам шаблона, обеспечивая тем самым ее четкое и понятное восприятие со стороны нашей команды. Также, помимо базового оформления, необходимо поддерживать актуальность карточки задачи, включая следующие аспекты: - Описание хода выполнения. - Подкрепление результатов выполнения метриками/тестами. - Выделение неочевидных моментов, встреченных в процессе выполнения. В результате мы получим инструмент, позволяющий вести асинхронную коммуникацию. #### Решение - шаблон для Issue на Github - шаблон для задач в таск-менеджере - шаблон для оформления RFC #### Cтадии подготовки задачи Между столбцом "todo" и "done" необходимо ввести дополнительные этапы о ходе выполнения наших задач. На обсуждении прозвучала идея, что при переходе задачи из статуса "in-progress" в "review" передавать выполнение задачи на ревьювера. ## Требования к коду Необходимы прозрачные правила оформления кода. Это могут быть как лучшие практики из книги "Чистый код", так и простые договоренности в команде. Согласно этим договоренностям, мы можем проводить ревью код-стиля дополнительно к код-ревью. ### Зачем это нужно В настоящее время у нас наблюдается хаотичный стиль написания кода, что в конечном итоге замедляет командную работу. Это усложняет процесс ревью кода и процесс интеграции новых сотрудников (онбординг). ## Требования к тестам Необходимо определить, какие тесты необходимы, каким образом они должны охватывать код, и в какой степени. Также важно обсудить взаимодействие с командой QA. В настоящий момент мы значительно улучшили этот аспект процессов, и важно продолжать работу в этом направлении. ## Требования к документации В настоящее время у нас в каждом проекте имеется README, однако это оказывается недостаточным. Необходимо создать документацию высокого уровня, способную обеспечить успешный онбординг нового разработчика. Переход от формата "как запустить" предполагает использование формата Wiki для более полного и структурированного предоставления информации. ## Требования к инфраструктуре Под инфраструктурой мы понимаем библиотеки, фреймворки, окружения, CI/CD и автоматизацию. На данный момент наш подход к этим аспектам основан на принципе остаточной поддержки, и важно настроить процесс поддержки и регулярного обновления. ## Процесс ревью В настоящий момент у нас возникают проблемы из-за нехватки сотрудников, у которых достаточно контекста или времени для его усвоения.Также проблемой является слишком большие ПР ## Процесс деплоя В настоящий момент наша слабая сторона заключается в отсутствии контроля над процессом развертывания, особенно в отношении отсутствия фьюча-бранчей, быстрых деплоев и возможности быстро изменять конфигурации. Это приводит к страху перед деплоем, накоплению больших объемов изменений и редким релизам, раз в полгода. Согласно лучшим практикам, рекомендуется выполнять деплои один-два раза в неделю. Для достижения этой цели предлагается следующий план: 1. **Внедрение фьюча-бранчей:** Реализация механизма фьюча-бранчей позволит собирать релизные ветки, облегчая управление изменениями и деплои. 2. **Внедрение механизма фича-флагов:** Добавление механизма фича-флагов позволит параллельно разрабатывать функционал и оперативно внедрять его. Это также устранит взаимные блокировки участников команды. 3. **Blue-Green Deployment для определенных приложений:** Реализация механизма Blue-Green Deployment для некоторых приложений обеспечит безопасное внедрение изменений с возможностью быстрого отката в случае проблем, бесшовное обновление. 4. **Механизм быстрых роллбеков:** Для остальных сервисов необходим механизм быстрых роллбеков, чтобы минимизировать воздействие проблемных обновлений. Учитывая особенности наших приложений, предлагается внедрить стратегию обновления у клиентов через Blue-Green Deployment, но без использования аппаратной реализации. Мы будем информировать лишь часть клиентов о необходимости обновления, следить за логами и метриками, и принимать решение о дальнейшем развертывании на основе полученной обратной связи. ## Поддержка Уже готов документ, описывающий онколл полиси: https://www.notion.so/ValSet-OnCall-076c4b6ccfff4230b4a752eea510d755 ## Поэтапный план внедения процессов Предлагаю оценить каждый подпроцесс от 1 до 10 и выделить наименее эффективные части для последующего улучшения. - [планирование] — 0-10 - [постановка задачи](#Постановка-задачи) — 0-10 - [требования к коду](#Требования-к-коду) — 0-10 - [требования к тестам](#Требования-к-тестам) — 0-10 - [требования к документации](#Требования-к-документации) — 0-10 - [требования к инфраструктуре](#Требования-к-инфраструктуре) — 0-10 - [процесс ревью](#Процесс-ревью) — 0-10 - [процесс деплоя](#Процесс-деплоя) — 0-10 - [поддержка](#Поддержка) — 0-10 После оценки и приоритизации предлагаю назначить группу ответственных за улучшение наименее эффективных подпроцессов и начать его реализацию.