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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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 отдельно или в составе большого релиза — зависит от принятых в группе процессов.

👉 Staging, production, devel — что это и зачем. Разбираемся с экспертом.

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

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

👉 Smoke-тестирование — максимально быстрые автотесты, которые показывают, что основная функциональность работает.

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

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

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

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

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

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

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

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

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