DilOS 4 Development Workflow (На Русском)

DilOS4 Development Workflow сконструирован для поддержки процессов разработки и сопровождения. Внутри процесса используются несколько типов тикетов:

Команда разработки, работающая по этому процессу, состоит из сотрудников, которым назначены следующие роли:

Developers
Development Leads
Quality Assurance engineers
Test Leads

Полный процесс выглядит так:

1. Создание тикета

Любой, у кого есть права Create Issue, может создать тикет. Конечно, более подробная и полная информация об ошибке, новой фиче или задаче весьма приветствуется, но по крайней мере поля Description и Environment ДОЛЖНЫ быть заполнены, чтобы тикет создался. После этого тикет помещается в backlog, и ему присваивается статус OPEN. И он автоматически назначается кому-то в роли Development Lead, после чего этому человеку высылается оповещение.

2. Назначение тикета разработчику

Development Lead может назначить тикет любому в роли Developer , кто может работать с этой темой (на его взгляд). Или любой Developer может взять этот тикет себе, просматривая backlog и нажав на тикете Assign to Me. После этого нужно поменять статус тикета на Assign to developer → ASSIGNED. После этого считается, что назначенный человек будет работать над этим тикетом.

3. Начало работы с тикетом

Developer может вернуть тикет назад в backlog, если тикет был назначен по ошибке. Для этого нужно поменять статус на Unassign → OPEN и при этом обязательно вписать в Comment что-то, что может помочь понять причину возврата. После этого тикет возвращается в backlog.

Для начала работы с тикетом Developer должен поменять статус на Start Working → IN ANALYSIS. Когда это будет проделано, тикет будет считаться находящимся в работе, а в поле Start Date будет занесён текущий момент.

4. Анализ тикета

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

Если в процессе анализа становится ясно, что другой человек должен работать над этим тикетом, Developer может вернуть тикет назад в backlog. Для этого ОБЯЗАТЕЛЬНО нужно заполнить, по крайней мере, поле Comment, чтобы объяснить причину возврата, и поменять статус на Not for me → OPEN. После этого тикет возвращается в backlog и назначается Development Lead-у с соответствующим уведомлением.

Если на этой стадии становится ясно, что этот тикет дублируется каким-то другим тикетом, Developer может закрыть тикет, поменяв статус на Duplicate → CLOSED с обязательным заполнением поля Linked Issue идентификатором дублирующего тикета и поля Comment с пояснением, почему это так.

Если по какой-либо другой причине тикет не будет выполнен, Developer тоже может закрыть его, сменив статус на Reject → CLOSED с обязательным внесением в поле Comment описания причины, почему тикет не будет выполняться.

Если в процессе анализа выясняется, что тикет уже выполнен в процессе выполнения другого тикета, Developer может просто перевести его в состояние Already fixed → RESOLVED с обязательным внесением информации о версии и ветке, где этот тикет выполнен, в поле Comment.

Тикет может быть временно заморожен, если нужно прояснить дополнительно какие-то вопросы, или по какой-либо другой причине. Для этого Developer или Development Lead должен поменять состояние на Suspend → SUSPENDED с заполнением поля Comment и назначением тикета человеку, который должен ответить на вопрос или выполнить какое-то действие - в этом случае этому человеку будет выслано соответствующее оповещение. Если есть необходимость дать более полную информацию, то Developer может изменить поле Resolution на соответствующее значение.

Когда всё становится ясно, и все вопросы прояснены, Developer может приступать к написанию кода. для этого статус нужно поменять на Create fix → IN PROGRESS.

5. Работа над кодом

Когда тикет находится в состоянии IN PROGRESS, считается, что Developer работает над кодом.

Если в процессе написания кода потребуется какая-то дополнительная информация, Developer или Development Lead может вернуть тикет назад в состояние IN ANALYSIS, чтобы задать кому-то дополнительные вопросы, попросить что-то сделать или просто ещё подумать . Для этого нужно поменять статус на Clarify → IN ANALYSIS и заполнить поле Comment, где указать причину такого возврата.

Когда работа над кодом закончена, Developer должен подготовить коммит, записать информацию о версии (возможно, ветке) и Environment в тикет и передать код на тестирование. При этом необходимо в поле Comment добавить информацию, которая поможет тест-инженерам провести грамотное тестирование. После этого Developer должен поменять состояние на Resolve → RESOLVED. Тогда тикет переводится в состояние RESOLVED и автоматически назначается человеку в роли Test Lead.

6. Тестирование изменений

Все тикеты в состоянии RESOLVED считаются готовыми для тестирования. Для группы тестирования это состояние сходно с состоянием OPEN для группы разработчиков: Test Lead получает уведомление, когда любой тикет переводится в это состояние, и может назначить любого в роли Quality Assurance для тестирования этого тикета. Также и любой тест-инженер может пройтись по списку таких тикетов и взять любой из них себе, нажав на Assign to Me. После этого состояние тикета нужно поменять на Verify → TESTING - и тикет будет считаться находящимся на тестировании.

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

Для закрытия тикета инженерQuality Assurance или Test Lead должен поменять статус на Done → CLOSED. И очень желательно добавить в тикет любую информацию, которая может помочь владельцу тикета воспользоваться сделанными изменениями и/или проверить его работу. После этого тикет автоматически возвращается владельцу тикета.

Для возвращения тикета Developer-у для доработки инженер Quality Assurance или Test Lead должен сменить статус на Not fixed → ASSIGNED и заполнить, по крайней мере, поле Comment описанием того, что пошло не так. И очень желательно добавить в тикет любую информацию, которая может помочь Developer-у осознать проблему: прикрепить логи, добавить картинки, привести описание шагов для воспроизведения неправильного поведения etc. После этого тикет автоматически назначается на разработчика, который переводил тикет в состояние RESOLVED.

7. Как отвечать на вопросы

Чтобы ответить на заданные вопросы и вернуть тикет из состояния SUSPENDED, тот, на кого этот тикет был переназначен, должен добавить в тикет запрашиваемую информацию (как минимум, заполниить Comment) и поменять состояние на Resume → IN ANALYSIS. После этого тикет автоматически вернётся тому, кто его заморозил.

8. Переоткрытие тикета

Любой, у кого есть права Create Issue, может переоткрыть тикет из состояния CLOSED, если проблема возникла вновь, или появилась подобная. Для этого нужно статус тикета поменять на Reopen → OPEN и добавить в поле Comment описание проблемы. После этого тикет помещается в backlog и назначается человеку в роли Development Lead , точно так же, как это происходило при создании тикета.