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

Разработка строится покомандно. Каждая команда разработчиков ориентирована на проекты, закрепленные за ней.

Команда состоит из 3-4 разработчиков, возглавляет команду - тимлид. Автоматически каждый из тимлидов является релиз-мастером команды, т.е. отвечает за деплой задач в production.

В обязанности тимлида входит:

  • распределение задач внутри команды (из Sprintlog'а)
  • участие в декомпозиции задач (при необходимости)
  • принятие архитектурных решений (с подключением архитектора)
  • участие в оптимизации процессов разработки
  • консультации в команде при реализации конкретных задач
  • мониторинг выполнения конкретных задач в своей команде
  • проведение ревью (при необходимости подключая кого-то из команды)
  • деплой
  • непосредственно разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ветка 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)

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

Если для выполнения задачи требуется внести изменения в структуру БД или добавить/удалить данные, в этом случае оформляется 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. Иначе, возвращается разработчику с подробными комментариями о том, что нужно исправить и доделать.

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

до конца рабочего дня осталось менее 3 часов

в день, перед выходными (пятница или предпраздничный день)

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

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

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

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

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

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

Похожие статьи:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Сколько будет Οдин + Τри
Главная
X

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2017 YaPro.Ru

Главная » Веб-мастеру » Интересное »