Приемо-сдаточные испытания

Приемо-сдаточные испытания

Для того, чтобы сделать процесс сдачи проекта (этапа) более четким и однозначным, должны быть введены четкие приёмочные критерии, при выполнении которых заказчик обязан «принять» этап.

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

Изначально, на старте проекта, с заказчиком необходимо обговорить процесс сдачи каждого этапа и проекта в целом.

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

Набор тестов может быть прислан и заказчиком.

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

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

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

С целью более скорого выпуска деливери, содержащего только запланированный функционал, разработка должна вестись с помощью ветвления кода (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. Процесс повторяется до выпуска финальной версии.

Управление изменениями проекта.

Управление изменениями проекта в ИТ.

Управление изменениями проекта

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

Что входит в управление изменениями проекта:

  • Анализ и сбор всех требований Заказчика.
  • Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
  • Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
  • Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
  • Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
  • После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
  • Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

  • Все или большинство требований, относящихся к следующему деливери (фазе), реализованы.

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

  • Определение готовности деливери к отправке. Критерии готовности:
  • все требования, относящиеся к данному деливери (фазе), реализованы;
  • открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

Мы рассмотрели пример процесса управления изменениями в ИТ проекте. Одна из распространенных ошибок – одноособное управление требованиями исходящее от руководителя проекта. Залог успеха – групповое обсуждение изменений, достижение компромисса со всеми учасниками.

План график работ.

План график работ по проекту.

План график работ

План-график работ по проекту подготавливается руководителем проекта. Ознакамливаются с документом команда и заказчик. Документ дает понимание о временных рамках выполнения основных работ.

План-график работ проекта (лучше всего – в MS Project). Должен показывать:

  • Объем и дату каждого деливери.
  • Объем работ на каждом этапе.
  • Основные вехи.

Примеры основных вех:

  • MILESTONE- утверждение спецификаций (в план должно быть заложено время на ревю и утверждение спецификаций заказчиком).
  • MILESTONE- утверждение плана тестирования деливери Х (QA менеджер составляет план тестирования следующего деливери, который должен быть утвержден менеджером проекта).
  • MILESTONE- завершение кодирования по деливери X (разработчики успешно закончили кодирование функционала, предназначенного для сдачи в деливери X).
  • MILESTONE- QA приемка деливери (QA тестирует деливери на территории заказчика, если требуется, и дает «добро»).
  • MILESTONE- готовность деливери Х к отправке (все фичи реализованы, а дефекты успешно исправлены – деливери можно отправлять заказчику).
  • MILESTONE- готовность пользовательской документации (финальная документация, которую необходимо передать заказчику, должна пройти ревю менеджера проекта).
  • MILESTONE- приемка деливери заказчиком (используя набор приемочных тестов, PM получает формальное одобрение продукта заказчиком).
  • MILESTONE- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

Таким образом и команда и заказчик становятся информированы о запланированном графике предстоящих работ. Тем самым повышая вероятность успешного завершения проекта в срок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План разработки сайта – SDP

План разработки сайта – SDP

План разработки сайта – SDP

План разработки сайта — Software Development Plan. Этот документ дает понимание участникам проекта (проектной группе и заказчику) о том, каким образом будет вестись работа в рамках проекта, каковы правила и т.д.

Документ дает полное представление:

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

План разработки сайта описывает:

  • Цель, содержание и функции проекта
  • Объекты, подлежащие сдаче
  • Приоритеты проекта
  • Организация проекта
  • Проектная группа
  • Артефакты проекта
  • Роли и ответственности
  • Взаимодействие участников
  • Управление разработкой
  • План-график проекта
  • Контроль качества
  • Управление требованиями и изменениями
  • Управление конфигурацией
  • Инструменты, инфраструктура
  • Контроль версий
  • Процесс сборок и релиза
  • Работа с дефектами
  • Параметр бага «Fix in»
  • Фильтры
  • Зависимость полей
  • Значения поля «Version»
  • Действия QA после сборки внутреннего билда
  • Действия QA после сборки деливери
  • Действия PM после сборки деливери
  • Предоставление отчетов
  • Почта
  • Проектный цикл
  • Разработка
  • Тестирование
  • Приемо-сдаточные испытания
  • Участие клиента в процессе
  • Ревю и утверждение проектной документации
  • Обсуждение изменений в требованиях, сроках, бюджете
  • Просмотр промежуточных версий ПО
  • Фиксирование замечаний и дефектов
  • Приемо-сдаточные испытания
  • Дополнительные планы
  • План обучения пользователей
  • План решения проблем