Как выглядит гибкий рабочий процесс в Azure DevOps?

Если вы пытаетесь понять состояния и причины рабочих элементов в Azure DevOps, вам лучше взглянуть на диаграммы, которые я создал ниже!

Контекст

На моем рабочем месте мы в настоящее время используем Azure DevOps для организации нашего проекта и размещения его исходного кода. Как и другие люди в моей команде, я новичок в этом инструменте. Несмотря на то, что я привык к параллельным продуктам, таким как GitLab, GitHub и Jira, я считаю Azure DevOps не интуитивно понятным инструментом… 🙈

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

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

Играя с этими рабочими элементами, я заметил, что некоторые причины были доступны только при изменении состояния элемента… 🤨

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

Я разместил их здесь, поэтому, если вы, как и я, застряли в Azure DevOps, по крайней мере, вы будете лучше понимать его. 😅

Гибкий процесс

Я хотел бы поблагодарить команду Lucid Software Inc. для инструмента, который я использовал для создания следующих диаграмм: Lucidchart. Было приятно попробовать их бесплатную версию.

Базовый

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

Новый: рабочие элементы, которые были созданы.
Активно: рабочие элементы выполняются в данный момент.
Решено: рабочие элементы выполнены, но не проверены.
Закрыто: рабочие элементы, которые были исправлены и проверены.

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

Итак, лучший поток может выглядеть следующим образом: