Change Requests. How is it done and why is it important?

Содержание

Все когда-либо сталкивались с ситуацией, "Всё пропало..., клиент уезжает..., гипс снимают...".
Любое изменение системы, это и есть запрос на изменения, либо Change Request CR), возможно еще услышать Problem or Change Request (PCR).

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

Первые два похожи и иногда объединяются в "requirement", но чаще всего существуют отдельно, так как это разные вещи.
Варианты определяются от источника запроса, новую функциональность может требовать бизнес или пользователь сервиса, в свою очередь рефакторинг и переписывание ядра, это требование технического руководителя либо архитектора.

Третий вид "defect" - в большинстве случаев находит тестер, иногда пользователь системы.

Необходимо помнить самое важное, что система в итоге изменяется и все изменения необходимо чётко фиксировать и контролировать.

📃 Как документально фиксировать Change Requests?

В содержании CR можно выделить обязательные блоки:
📍 Автор (submitter)
📍 Имя / Название (subject)
📍 В какой версии
📍 Подробное описание
Можно добавлять блоки в зависимости от процесса и команды разработки:
📍 Ожидаемое поведение
📍 Конфигурация системы
📍 Лог-файлы

👉🏻 Типовой жизненный цикл CR:
New -> Assigned -> Opened -> Resolved -> Closed

✔️ Итого: CR - Формальное обращение, необходимое для получения официального разрешения на изменения в предметной области проекта, проектных решениях, методах, плановых сроках и затратах или других показателях проекта.

❗️ ВАЖНО: СR должен быть задокументирован, зарегистрирован и оценен, выполняется, только после одобрения со стороны бизнеса.