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

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

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

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

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

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

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

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

  • внутри одного типа задач наверх поднимаются задачи с высшим полем 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).

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

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

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


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

Новые заметки:

Про что мы забываем когда делаем оценку задачи по времени

Список вопросов для собеседования разработчика по телефону

Symfony2 авторизация без Doctrine2 для чайника

Phpstorm7 LiveEdit

Жесткий хабр или не хабр, тогда кто?

Яндекс.Деньги мошенничество

Как узнать какие страницы в поиске яндекса или это секрет

Последние комменты:

Yapro CMS:

Здравствуйте, Гость | Войти | Регистрация | Карта сайта | RSS ленты | Ошибка в тексте? Выделите её мышкой и нажмите: Ctrl + Enter

youtube.com/watch?v=7hFivbgIEqk

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

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