Работа в АИС SCRUM
Общее описание системы
АИС SCRUM
Это информационная система, направленная на повышение эффективности процесса разработки и прозрачности работ над IT продуктами Компании.
1 | Структура объектов в системе

Постулаты
Обращение
Обратная связь от пользователей, которая может инициировать подзадачу, задачу, ошибку, цель.
Задача
Описание доработки в одном продукте. Состоит из подзадач, размещается в плане доработок и реализуется в спринтах.
Подзадача
Самая маленькая единица в системе. Каждая подзадача - это какое-то значимое изменение в проекте с примерным временем на его реализацию.
План работ
Задачи разложенные по месяцам, на усмотрение бизнеса.
Спринт
Список задач, которые будут выполнены за некий срок в календарных неделях (обычно 3-4). Формируется на основе плана работ.
Цель
Список задач по разным продуктам, объединённые для реализации большой доработки.
Ошибка / Баг-репорт
Проблема, имеющая четкое описание воспроизведения и приоретизацию.
Тест-кейс
Порядок действий, успешное выполнение, которых говорит о готовности задачи к принятию и публикации.
Чек-лист
Список механизмов, которые обязательно надо проверить перед сдачей заказчику.
Важно: отправной точкой в АИС Scrum является обращение, на основе которого происходит создание задач, ошибок и оказание поддержки пользователям.
Если вы не уверены, что у вас есть возможность создать корректную задачу или ошибку, то следует создать обращение через <<Обратную связь>>.
2 | Структура элементов
Задача


Задача может появится в системе двумя путями:
  • из обращения;
  • путём прямого создания.

Зачастую для полноценного выполнения одной задачи, её разбивают на несколько подзадач.

Выполнение всех подзадач означает окончание работы по задаче и переход на этап тестирования.

Спринт

Ограничен по продолжительности и содержит в себе только те задачи, которые точно будут выполнены в указанный срок. Наполняется в порядке приоритетности.

Формирование спринта - зона ответственности руководителя разработки.

Цель



Цель состоит из нескольких спринтов, реализация которых необходима для какой-то одной глобальной доработки (в других системах это называется Epic).

Цель формируется путём обращения, либо прямым созданием.

В цели размещается вся необходимая информация для реализации доработки (ТЗ, схемы, БТ и т.д.).




3 | Работа с обращениями
Работа с задачей в АИС Scrum начинается с создания обращения пользователем в любой из рабочих систем в упрощённом формате (через раздел <<Обратная связь>>).

После получения обращения от пользователя создается обращение в АИС Scrum.

Тип обращений определяется в процессе его обработки:
  • Заказ доработки - сформулированная задача в обращении;
  • Изменение данных - внесение изменений через БД, обработки и т.п.;
  • Изменение настроек - изменение поведения приложения без серьезного изменения кода;
  • Консультация - помощь коллегам и разъяснение по работе системы;
  • Настройка тестовой среды - обновление БД и настройка тестовых серверов;
  • Подготовка выгрузки - формирование файла с данными из БД;
  • Предложение/Идея - не сформулированная идея по улучшению системы;
  • Работа с РПД - выдача и изменение прав пользователей;
  • Работа с учетными записями - создание, удаление, изменение УЗ пользователей;
  • Сообщение о проблеме - сообщения о некорректно работающем функционале.
Результаты обработки обращений:

  • Если обращение является сообщением об ошибке, то тестировщик анализирует, проверяет ошибку и создает связанный багрепорт и далее обращение остается в работе до его исправления;
  • Если обращение является идеей, предложением или заказом доработки, то оно передается руководителям отдела. Далее по результату создается цель/задача и обращение закрывается;
  • Во всех остальных случаях (консультация, подготовка инструкций и т.д.) решается вопрос между всеми участниками (QA, руководители, программист), и обращение закрывается.
Что важно знать?
  • Обращение рассматривается и принимается в работу максимально оперативно (не более 8 рабочих часов);
  • Оперативность решения зависит от критичности выполняемой работы сотрудником;
  • Обращения закрываются при готовности, при необходимости проверить или запросить дополнительную информацию у инициатора - отправляется на уточненение;
  • Вся необходимая информация по обращению должна быть зафиксирована в комментариях.
4 | Создание задач и ошибок (багов)
При создании задачи обязательно заполняются поля:
  • Описание должно быть максимально подробным и ёмким, позволяющим однозначно понять что и в каком объеме надо сделать;
  • Как продемонстрировать – Порядок действий, позволяющий воспользоваться описанным функционалом, отправная точка для тестировщика;
  • Критерий приемки – Конечный результат, который говорит о готовности задачи.

Также при создании задачи необходимо определить требуется ли участие тестировщика (QA) в принятии результата или нет.



От этого зависит дальнейший жизненный цикл задачи в системе.

Жизненный цикл задачи с участием QA
1
Попадание в спринт
Задача находится в статусе <<Новая>>.
2
Реализация доработки
Статус <<В работе>>.
3
Проверка ошибок
Статус <<Тестирование>>.
4
Исправление ошибок
Если в ходе проверки были выявлены ошибки, то задача снова переходит в статус <<В работе>>. После исправления снова возвращается тестировщику для повторной проверки.
5
Проверка заказчиком
Статус <<Принятие>>.
6
Доработка по замечаниям
Если в ходе принятия пользователем были выявлены ошибки, то задача снова переходит в статус <<В работе>>. После доработки снова возвращается пользователю на принятие.
7
Релиз
Статус <<Закрыто>>.
Жизненный цикл задачи без QA
1
Попадание в спринт
Задача находится в статусе <<Новая>>.
2
Реализация доработки
Статус <<В работе>>.
3
Проверка заказчиком
Статус <<Тестирование>>.
4
Исправление ошибок/доработка по замечаниям
Если в ходе проверки были выявлены ошибки, то задача снова переходит в статус <<В работе>>. После исправления снова возвращается заказчику для повторной проверки.
5
Проверка заказчиком
Статус <<Принятие>>.
6
Релиз
Статус <<Закрыто>>.
При создании багов должны быть корректно заполнены основные поля:

  • Текущий результат – Описание текущего результата;
  • Как воспроизвести – Подробный список шагов, приводящий к ошибке, выполнение которого 100% повторит текущий результат у других;
  • Ожидаемый результат – То, как должен работать продукт после исправления.




После того, как ошибка была исправлена, инициатор получает задачу на принятие результата и завершает его или возвращает снова на доработку.

5 | Принятие задач и ошибок


После того, как работа с задачей завершена (тестировщик завершил тестирование), заказчик получает задачу в АИС Portal на проверку доработки.

В описании содержится ссылка на задачу в АИС Scrum, описание задачи и выбор результата проверки с возможностью добавить комментарий.


Карточка принятия доработки в АИС Scrum.

<<Публикация на боевом сервере>> - результат принят и готов к запуску.
<<Требуется небольшая доработка или есть замечание>> - результат не принят и необходимо внести небольшие корректировки.
<<Есть ошибка>> - результат не принят и требуется более серьёзное исправление по задаче (открывается форма создания ошибки).
Made on
Tilda