Из чего состоит разработка в команде

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

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

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

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

Итак, что за этапы:

• Задача в работе
• Декомпозиция
• Разработка
• Ревью кода
• Тестирование
• Релиз
• Мониторинг
• Ретроспектива

Задачу взяли в работу

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

Зачем это нужно. Проектирование нужно, чтобы оценить сложность задачи и рассчитать необходимые ресурсы.

Декомпозиция

В чём суть. Большая и сложная задача превращается в несколько задач поменьше. Каждая такая мини-задача должна быть осмысленной и даже по отдельности нести пользу для компании.

Зачем нужно. Каждую мини-задачу можно разрабатывать отдельно и релизить отдельно.

Разработка

В чём суть. Обычно по понедельникам разработчики разбирают задачи на спринт или руководитель группы назначает разработчикам задачи.

Зачем это нужно. Код сам себя не напишет.

Code Review

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

Зачем это нужно. Это помогает избегать соблазна оставить всё как есть, ведь «и так работает». Да и выпущенному коду обычно не хочется возвращаться.

Кто проводит ревью. Зависит от процессов, но в большинстве случаев проверяющего назначает руководитель группы, либо каждый разработчик может взять ваш Merge request из очереди и отсмотреть.

Как проходит ревью:

1. Вы пишете код;
2. Покрываете его unit-тестами;
3. Собираете все изменения по коммитам (git commit) и отправляете в ветку в общем репозитории (git push);
4. На основе сделанных изменений создаете MR (merge request);
5. Кто-то из коллег-разработчиков берет Ваш MR и проверяет его, оставляя комментарии по спорным и проблемным местам;
6. Вы исправляете все недочеты и обновляете MR;
7. Ревьюер (не обязательно тот же самый человек) снова отсматривает ваш код и принимает его.

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

В чём суть. Проверить, что всё работает как надо.

Зачем это нужно. Способ отловить ошибки ещё на этапе разработки и сохранить нервы в процессе эксплуатации сайта, приложения или веб-сервиса. Если при тестировании обнаружены ошибки, то задача возвращается разработчику на доработку.

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

Релиз

В чём суть. QA-инженер, либо разработчик релизит задачу в Production отдельно или в составе большого релиза — зависит от принятых в группе процессов.

Как проходит. После переключения Production на новую версию приложения наступает короткий этап мониторинга, который, как правило, длится от нескольких минут до нескольких часов.

В это время команда изучает логи ошибок приложения (Error logs), графики, проводит Smoke-тестирование и так далее — в общем всё то, что позволяет принять решение о качестве выпущенного релиза. На основании этого этапа принимается решение о закрытии релиза или о его откате.

Закрытие релиза — ряд процедур, после которых новые изменения остаются в Production среде «навсегда» и становятся частью системы. Но если в релизе обнаружены проблемы, его откатывают.

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

Мониторинг и оценка ценности

В чём суть. Оценка проделанной работы. Обычно на этом этапе собираются необходимые метрики и данные для бизнеса.

Зачем нужно. Чтобы оценить влияние выпущенного релиза на бизнес, ключевые показатели и общую работоспособность системы.

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

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

Зачем это нужно. Ретроспективы помогают своевременно устранить мешающие процессы и закрепить эффективные.

На этом всё. Запомните _г_лавное — процессы отличаются, но основы везде примерно одинаковые. Если вы понимаете, из чего состоит разработка, а не просто пишете код, то сможете добиться в IT большего.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.