Issues labels system
В нашем проекте принята методология, основанная на выделении относительно небольших задач и отслеживании прогресса путем манипулирования этими задачами. Каждой задаче соответствует issue. Для issues выделено 5 основных меток (labels) по типу детализированности. Это idea, feature, code maintenance, task, bug. Иерархию взаимодействия можно представить вот так:
Idea отмечает абстрактное описание какой-то идеи — такие issues предназначены для аналитиков.
Bug — описание ошибки в работе уже созданного функционала. Может содержать рекомендации по исправлению, описание причины ошибки. В зависимости от характера ошибки, может предназначаться как для аналитиков, так и для разработчиков.
Feature и code maintenance отмечают описание изменений на относительно высоком уровне абстракций — для таких задач требуется аналитика по переработке их в tasks.
Task — отмечает конкретную, формализованную задачу, это основной "кирпичик" построения нашего проекта. Такая задача также дополнительно может отмечаться label-ами feature или code maintenance, в качестве дополнительной классификации изменений, описанных в задаче. Task — метка, отмечающая задачу непосредственно для разработчика.
Задача, отмеченная меткой task, должна также помечаться областью необходимых работ.
Front-end — задачи, касающиеся клиентской стороны пользовательского интерфейса к программно-аппаратной части сервиса.
Back-end — задачи по программно-аппаратной части сервиса.
Deploy — задача развертывания приложения на новой платформе или на той же самой, но новой версии приложения.
Testing — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.
Каждая из вышеперечисленных меток должна сопровождаться одной меткой из категории приоритета. С помощью них мы указываем важность задач и багов.
-
Top — Наивысший приоритет. Присваивается issues, которые должны быть выполнены безотлагательно. Предназначен для экстренных ситуаций, требующих немедленного выполнения. В случае ошибок их исправление и публикация выполняются в первую очередь, до реализации любых новых задач. Все текущие задачи временно откладываются и либо один член команды, либо вся команда целиком переходит к решению этой задачи.
-
High — Высокий приоритет. Присваивается issues, которые должны быть выполнены в первую очередь. В случае, если появляется более приоритетная задача, менеджер проекта может присвоить ей приоритет “High” только после того, как понизит приоритет других задач. В данном случае прекращение своей текущей деятельности не требуется, однако стоит перестроить ближайшие планы, для скорого выполнения этой задачи.
-
Normal — Обычный приоритет. Присваивается issues, которые следует выполнить во вторую очередь, в рабочем порядке. Этот приоритет выбран по умолчанию. Большинство ошибок и задач должны получать именно такой приоритет.
-
Low — Низкий приоритет. Присваивается issues, выполнение которых не обязательно и производится в последнюю очередь при наличии времени.
Если для реализации issue требуется помощь других участников, то можно поставить метку help wanted. Обычно, она ставится, если участник считает, что не сможет справиться с возложенной на него задачей.
В случае возникновения вопросов по issue как в момент составления, так и в процессе реализации, то такие issue помечаются меткой question. Отличие от предыдущего в том, что данную метку стоит использовать не для запроса помощи, а для запроса ответа на конкретный вопрос. В таком случае автору issue может быть стоит уточнить некоторые требования к задаче или предоставить дополнительные данные.
Меткой invalid обычно пользуются руководители команд и аналитики. Она нужна, чтобы указывать участникам команды на некорректно составленные issues. Такие issues в обязательном порядке необходимо переработать прежде, чем их брать на исполнение.
И последняя метка wontfix. Issues, помеченные этим label'ом "замораживаются", т.е. приостанавливается дальнейшая работа над задачей. В дальнейшем такие issues может быть пересмотрены и заново отправлены на разработку.