Процесс разработки продукта

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

Команда состоит из:

  • Team Lead - возглавляет команду
  • Senior (1 или 2 человека)
  • Developer / Programmer (3 или 2 человека)

Распределение обязанностей

Обязанность / Роль Team Lead Senior Developer
сбора требований (если в команде нет аналитика) да нет нет
распределение задач внутри команды (из Sprintlog'а) да нет нет
участие в декомпозиции задач (при необходимости) да да нет
принятие архитектурных решений (с подключением архитектора, если таковой имеется) да да нет
консультации в команде при реализации конкретных задач да да да
непосредственно разработка да да да
проведение ревью (при необходимости подключая кого-то из команды) да да нет
тестирование (если в команде нет тестировщика или в компании нет отдела тестирования) да да нет
деплой (тимлид является релиз-мастером в команде, т.е. отвечает за деплой задач в production) да нет нет
поддержка готовой части ПО (если в компании нет команды эксплуатации) да нет нет
мониторинг выполнения конкретных задач в команде да нет нет
участие в оптимизации процессов разработки да нет нет

Стоит заметить, что обычно на Senior-а возлагается временная ответственность, когда TeamLead уходит в отпуск или увольняется.

Разрешение конфликта приоритета задач

Если во время выполнения Спринта появляются задачи с более высоким приоритетом (выше чем у запланированных), то такие задачи сразу уходят в разработку. Надо помнить, что это исключение, которое относится только к исправлению важных ошибок. При планировании Спринта этот фактор необходимо учитывать и на него нужно закладывать определенное рабочее время разработчиков.

Приоритеты сравниваются таким образом:

  • внутри одного типа задач наверх поднимаются задачи с высшим полем Priority
  • при одинаковых приоритетах Bug выше, чем Task
  • при одинаковых приоритетах задач в работу и задач на проверку, сначала выполняется ревью/деплой готовых задач

Список задач, распределенных на разработчика отображается на Kanban-доске:

Процесс разработки продукта

Разработчику необходимо придерживаться установленных приоритетов задач - самые приоритетные находятся вверху списка "К выполнению".
В работе не должно быть больше одной задачи в момент времени. Если по задаче возникли вопросы, тормозящие выполнение задачи, задача переводится в статус "On Hold". В задаче оставляется обязательный комментарий в чем именно проблема с выполнением и она переводится на того человека, который может предоставить недостающую информацию или оказать другую помощь в решении.

Ежедневные митинги

Проводятся утром в одно и тоже время, время проведения митинга жестко не регламентировано (устанавливается руководством).

Состав участников: руководство отдела разработки, разработчики в полном составе.

На ежедневных митингах с каждым из исполнителей-разработчиков обсуждается:

  • что было сделано вчера;
  • что из запланированного сделано не было и почему;
  • какие проблемы возникли при выполнении задачи;
  • что планируется сделать сегодня.

Правила и порядок работы с репозиторием

  • Ветка master является основной
  • Любые ветки ответвляются только от ветки master (разработчиком)
  • Для каждой из задач (даже для мелкого fix'а) разработчиком создается отдельная ветка, которая именуется согласно правилам:
    • Префикс ветки - номер задачи
    • Разделитель '_' (подчеркивание)
    • Краткое описание наименования задачи (eng), слова склеиваются через тире '-'
    • Примеры:
      • API-123_short-info
      • PERSONAL-AREA-45_short-description
  • Когда задача готова к Code Review, делается merge последних изменений из ветки master и создается Code Review (разработчиком)
  • Если Code Review пройдено, то делают merge / Pull Request в ветку master (Релиз-мастер / TeamLead)
  • Рабочая ветка закрывается (Релиз-мастер / TeamLead)

Код

При написании кода необходимо придерживаться установленных Code Standarts. Если происходит модификация уже существующего кода, то текст должен быть выдержан в стиле уже написанного кода, вне зависимости от текущих требований Code Standarts.
В процессе реализации задачи, разработчиком составляются unit-тесты, которые в последствие используются для модульного тестирования. Перед тем как зарезолвить задачу, разработчик обязан добиться полного прохождения написанных тестов (как для текущей задачи, так и созданных ранее). Код тестов может быть проверен на стадии Code Review.

Изменения в БД, миграции

Если для выполнения задачи требуется внести изменения в структуру БД или добавить/удалить данные, в этом случае оформляется SQL-миграция. Пример именования файла: YYYY\MM\API-123_short-info.php

Code Review

После завершения работ над задачей, она должна в обязательном порядке пройти процедуру Code Review. Разработчик, который занимался выполнением задачи, после завершения работы над ней, должен:

  1. создать ревью-патч в Crusible
  2. перевести задачу в статус Code Review
  3. переключить задачу на Ревьювера (обычно это человек указанный в поле Ревьювер или любой наименее нагруженный программист).

Ревьювер в порядке очереди приоритетов проверяет те задачи которые у него появляются в соответствующем столбце Kanban-доски. Он же принимает решение о том, прошла задача проверку качества или нет. Во время Code Review анализируется код, архитектурные решения, соответствие принятым стандартам кодирования. Если в процессе проверки обнаружены недочеты, задача отправляется на доработку. Ревьювер может подключать к проверке других специалистов и в этом случае необходим коллективный аппрув задачи.

Сборка и выкладка и тестирование

Правильным решением для хорошего качества продукта, нужно чтобы новая версия продукта прошла 3 стадии:

  1. stage - выполняется сборка и прохождение автоматических тестов)
  2. beta - сервер, на котором выполняется ручное тестирование
  3. production - продукт используют клиенты

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

В рамках тестирования выполняется:

  • прохождение всех unit-тестов (автоматические тестирование)
  • прохождение всех функциональных тестов (автоматические тестирование)
  • ручное тестирование функционала согласно описанным требованиям (при отсутствии Project Manager-а выполняется разработчиком)

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

Когда выкладка запрещается

  1. до конца рабочего дня осталось менее 3 часов
  2. в день, перед выходными (пятница или предпраздничный день)

Если на production обнаружилась ошибка

  1. если критичная ошибка - изменения откатываются
  2. если некритичная ошибка - ставится задача на срочное исправление ошибки и создание регрессионных тестов

Взаимодействие с админами (IT Support)

Если нужны какие-то действия от админов, это делается через руководство отдела разработки или ведущего разработчика. Вопросы/требования оформляются в таск-трекере (проект IT Support).

Для новых сотрудников выполняется

  • закрепление тимлида (если компания производит множество продуктов)
  • выдается инструкция по разворачиванию системы/проекта
  • выдается ссылка на документацию

Источник: 1


18.04.2017 08:56