Из чего состоит разработка в команде
- 4 октября 2022
Или как выглядит жизненный цикл проекта в при работе в команде. Это поможет лучше представить, чем предстоит заниматься на работе.
Любая разработка начинается с идеи от кого угодно в компании, но часто есть целый отдел, который отвечает за идеи и исследования. Подробнее об этом — в другой статье. Идею формулируют, анализируют и принимают решение, делать или нет. После этого идея превращается в задачу и отправляется в бэклог разработки.
Бэклог — длинный список задач, которые кто-то когда-то поставил. Иногда из бэклога «достают» задачи и начинают их делать. Например, владелец продукта или заказчик может решить, что прямо сейчас какая-то задача важнее других, тогда он переносит её наверх списка.
Это называется приоритизацией — когда у задач меняются приоритеты. Это нужно, чтобы делать только то, что важно.
Итак, что за этапы:
- Задача в работе
- Декомпозиция
- Разработка
- Ревью кода
- Тестирование
- Релиз
- Мониторинг
- Ретроспектива
Задачу взяли в работу
В этот момент тимлид составляет техническое задание. Если задача — исправить баг, то это может повлиять на архитектурную схему проекта. То есть раньше мы думали, что проект работает как-то определенным образом, но с учётом бага. А после исправления
Зачем это нужно. Проектирование нужно, чтобы оценить сложность задачи и рассчитать необходимые ресурсы.
Декомпозиция
В чём суть. Большая и сложная задача превращается в несколько задач поменьше. Каждая такая мини-задача должна быть осмысленной и даже по отдельности нести пользу для компании.
Зачем нужно. Каждую мини-задачу можно разрабатывать отдельно и релизить отдельно.
Разработка
В чём суть. Обычно по понедельникам разработчики разбирают задачи на спринт или руководитель группы назначает разработчикам задачи.
Зачем это нужно. Код сам себя не напишет.
Code Review
В чём суть. Один или несколько членов команды проверяют код — смотрят на используемые паттерны, наличие логических ошибок, соответствие принятому в команде стандарту кода.
Зачем это нужно. Это помогает избегать соблазна оставить всё как есть, ведь «и так работает». Да и выпущенному коду обычно не хочется возвращаться.
Кто проводит ревью. Зависит от процессов, но в большинстве случаев проверяющего назначает руководитель группы, либо каждый разработчик может взять ваш Merge request из очереди и отсмотреть.
Как проходит ревью:
- Вы пишете код;
- Покрываете его unit-тестами;
- Собираете все изменения по коммитам (
git commit
) и отправляете в ветку в общем репозитории (git push
); - На основе сделанных изменений создаете MR (
merge request
); - Кто-то из коллег-разработчиков берет Ваш MR и проверяет его, оставляя комментарии по спорным и проблемным местам;
- Вы исправляете все недочеты и обновляете MR;
- Ревьюер (не обязательно тот же самый человек) снова отсматривает ваш код и принимает его.
Тестирование
В чём суть. Проверить, что всё работает как надо.
Зачем это нужно. Способ отловить ошибки ещё на этапе разработки и сохранить нервы в процессе эксплуатации сайта, приложения или веб-сервиса. Если при тестировании обнаружены ошибки, то задача возвращается разработчику на доработку.
Как это работает. QA-инженер забирает задачу в работу и вместе с разработчиком начинает над ней работать. Чем больше комментариев и подсказок разработчик оставит тестировщику в задаче, тем лучше будет финальный результат, и тем больше QA-инженер проверит сложных или редких сценариев, выбивающихся из «обычного» сценария.
Релиз
В чём суть. QA-инженер, либо разработчик релизит задачу в Production отдельно или в составе большого релиза — зависит от принятых в группе процессов.
Как проходит. После переключения Production на новую версию приложения наступает короткий этап мониторинга, который, как правило, длится от нескольких минут до нескольких часов.
В это время команда изучает логи ошибок приложения (Error logs), графики, проводит Smoke-тестирование и так далее — в общем всё то, что позволяет принять решение о качестве выпущенного релиза. На основании этого этапа принимается решение о закрытии релиза или о его откате.
👉 Smoke-тестирование — максимально быстрые автотесты, которые показывают, что основная функциональность работает.
Закрытие релиза — ряд процедур, после которых новые изменения остаются в Production среде «навсегда» и становятся частью системы. Но если в релизе обнаружены проблемы, его откатывают.
Откат релиза — это переключение на состояние системы до релиза. Обычно это промежуточный этап, в ходе которого команда исправляет найденные ошибки, чинит проблемы и запускает цикл заново.
Мониторинг и оценка ценности
В чём суть. Оценка проделанной работы. Обычно на этом этапе собираются необходимые метрики и данные для бизнеса.
Зачем нужно. Чтобы оценить влияние выпущенного релиза на бизнес, ключевые показатели и общую работоспособность системы.
Ретроспектива
В чём суть. После завершения спринта или работы над задачей команда и все заинтересованные стороны собираются, чтобы обсудить ход работы: что-то прошло хорошо, что не так, что можно улучшить, кто молодец.
Зачем это нужно. Ретроспективы помогают своевременно устранить мешающие процессы и закрепить эффективные.
На этом всё. Запомните _г_лавное — процессы отличаются, но основы везде примерно одинаковые. Если вы понимаете, из чего состоит разработка, а не просто пишете код, то сможете добиться в IT большего.
«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.
Читать дальше


Как попасть в компанию мечты, если там закрыты все вакансии. Советует HR
Не сдавайтесь — способы есть.
- 14 февраля 2023


Работа в удовольствие: как электронщик ушёл в айти и не жалеет об этом
История Алексея Груднова.
- 3 февраля 2023




Какие вопросы задают на собеседованиях
Нужно ли фронтендеру уметь вообще всё.
- 1 декабря 2022

