Архив рубрики: Разработка

Процессы, процедуры, проектные цикли и прочая документация

Процесс сборки билдов и релиза

Процесс сборки билдов и релиза

С целью более скорого выпуска деливери, содержащего только запланированный функционал, разработка должна вестись с помощью ветвления кода (branching).

В один момент времени может быть до 2х веток кода:

  • Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
  • Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).
  • 0й – разработка
  • 1й – тестирование, fix, разработка, сдача этапа (деливери)
  • 2й – тестирование, fix, разработка, сдача этапа (деливери)
  • 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

  • 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
  • 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
  • 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
  • 4. PM планирует объем функционала {Ф} для следующего деливери.
  • 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
  • ! У дефектов приоритет всегда выше, чем у нового функционала!
  • 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
  • 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
  • ! Деливери собирается и отправляется только после одобрения QA!
    • Деливери отправляется заказчику вместе с сопроводительной документацией.
  • 8. PM инициирует слияние двух веток.
  • 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
  • 10. Процесс повторяется до выпуска финальной версии.

Роли в команде разработчиков ПО.

Роли в команде разработчиков ПО

Каждый ИТ специалист идет по пути наименьшего сопротивления, как правило пытаясь сбросить часть работы на коллегу. Для избегания возможных конфликтов в команде нужно четко разграничить участок работ каждого участника, в том числе заказчика. Для этого предлагаю сопоставить каждому участнику проекта соответствующую роль.

Роли в команде разработчиков ПО:

Менеджер Проекта (PM) ответственный за:

  • организацию процесса разработки;
  • координацию и контроль всех видов деятельности в проекте;
  • разработку плана проекта (Project Plan);
  • проведение регулярных статус митингов в проектной группе;
  • контроль готовности деливери и нового билда для QA;
  • предоставление заказчику документации и промежуточных версий для просмотра и утверждения или комментирования;
  • регулярное общение с заказчиком, выяснение требований;
  • предоставление отчетов о статусе проекта.

Бизнес аналитик (Business Analyst) ответственный за:

  • выяснение и анализ всех требований заказчика;
  • фиксирование всех требований заказчика (в багтрекинговой системе и в функциональных спецификациях), прослеживание всех изменений в требованиях;
  • написание и поддержка спецификаций.

Системный аналитик (Technical Leader) ответственный за:

  • координацию и контроль деятельности по дизайну, архитектуре и кодированию;
  • поддержку контроля версий;
  • настройку скрипта для авто-билдера и своевременную сборку версий.

QA менеджер (QA manager) ответственный за:

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

QA аналитик (QA Analyst) ответственный за:

  • подготовку тест дизайна;
  • написание тест кейс спецификаций;
  • проведение тестирования;
  • регистрацию багов;
  • прослеживание и проверку багов;
  • написание документации пользователя.

Разработчик (Developer) ответственный за:

  • разработку качественного кода;
  • проведение модульного тестирования;
  • поддержку контроля версий;
  • написание пользовательской документации, относящейся к инсталляции и администрированию.

Заказчик (Customer) ответственный за:

  • своевременный просмотр спецификаций и других присылаемых документов (с целью утвердить документ, дать комментарии, исправить неточности и т.п.);
  • внесение замечаний, дефектов, пожеланий в багтрекинговую систему.
  • своевременный просмотр каждого деливери после его поставки и предоставление комментариев.

Зная, какую работу выполнить каждому участнику в определенный момент времени избавляем себя от возможных конфликтов при реализации проекта. Все роли описываются в план разработки проекта. Таким образом зная свою роль в команде обрекаем проект на успех!