По моему опыту средних компаний, разработка строится по командно. Каждая команда разработчиков ориентирована на проекты, закрепленные за ней. Возглавляет команды руководитель разработки.
Команда состоит из:
Обязанность / Роль | Team Lead | Senior | Developer |
сбора требований (если в команде нет аналитика) | да | нет | нет |
распределение задач внутри команды (из Sprintlog'а) | да | нет | нет |
участие в декомпозиции задач (при необходимости) | да | да | нет |
принятие архитектурных решений (с подключением архитектора, если таковой имеется) | да | да | нет |
консультации в команде при реализации конкретных задач | да | да | да |
непосредственно разработка | да | да | да |
проведение ревью (при необходимости подключая кого-то из команды) | да | да | нет |
тестирование (если в команде нет тестировщика или в компании нет отдела тестирования) | да | да | нет |
деплой (тимлид является релиз-мастером в команде, т.е. отвечает за деплой задач в production) | да | нет | нет |
поддержка готовой части ПО (если в компании нет команды эксплуатации) | да | нет | нет |
мониторинг выполнения конкретных задач в команде | да | нет | нет |
участие в оптимизации процессов разработки | да | нет | нет |
Стоит заметить, что обычно на Senior-а возлагается временная ответственность, когда TeamLead уходит в отпуск или увольняется.
Если во время выполнения Спринта появляются задачи с более высоким приоритетом (выше чем у запланированных), то такие задачи сразу уходят в разработку. Надо помнить, что это исключение, которое относится только к исправлению важных ошибок. При планировании Спринта этот фактор необходимо учитывать и на него нужно закладывать определенное рабочее время разработчиков.
Приоритеты сравниваются таким образом:
Список задач, распределенных на разработчика отображается на Kanban-доске:
Разработчику необходимо придерживаться установленных приоритетов задач - самые приоритетные находятся вверху списка "К выполнению".
В работе не должно быть больше одной задачи в момент времени. Если по задаче возникли вопросы, тормозящие выполнение задачи, задача переводится в статус "On Hold". В задаче оставляется обязательный комментарий в чем именно проблема с выполнением и она переводится на того человека, который может предоставить недостающую информацию или оказать другую помощь в решении.
Проводятся утром в одно и тоже время, время проведения митинга жестко не регламентировано (устанавливается руководством).
Состав участников: руководство отдела разработки, разработчики в полном составе.
На ежедневных митингах с каждым из исполнителей-разработчиков обсуждается:
При написании кода необходимо придерживаться установленных Code Standarts. Если происходит модификация уже существующего кода, то текст должен быть выдержан в стиле уже написанного кода, вне зависимости от текущих требований Code Standarts.
В процессе реализации задачи, разработчиком составляются unit-тесты, которые в последствие используются для модульного тестирования. Перед тем как зарезолвить задачу, разработчик обязан добиться полного прохождения написанных тестов (как для текущей задачи, так и созданных ранее). Код тестов может быть проверен на стадии Code Review.
Если для выполнения задачи требуется внести изменения в структуру БД или добавить/удалить данные, в этом случае оформляется SQL-миграция. Пример именования файла: YYYY\MM\API-123_short-info.php
После завершения работ над задачей, она должна в обязательном порядке пройти процедуру Code Review. Разработчик, который занимался выполнением задачи, после завершения работы над ней, должен:
Ревьювер в порядке очереди приоритетов проверяет те задачи которые у него появляются в соответствующем столбце Kanban-доски. Он же принимает решение о том, прошла задача проверку качества или нет. Во время Code Review анализируется код, архитектурные решения, соответствие принятым стандартам кодирования. Если в процессе проверки обнаружены недочеты, задача отправляется на доработку. Ревьювер может подключать к проверке других специалистов и в этом случае необходим коллективный аппрув задачи.
Правильным решением для хорошего качества продукта, нужно чтобы новая версия продукта прошла 3 стадии:
В рамках тестирования выполняется:
В случае успешного прохождения всех видов тестов, задача считается готовой к деплою на production. Иначе, возвращается разработчику с подробными комментариями о том, что нужно исправить и доделать.
Если нужны какие-то действия от админов, это делается через руководство отдела разработки или ведущего разработчика. Вопросы/требования оформляются в таск-трекере (проект IT Support).
Источник: 1