Управління DevOps задачами (Azure DevOps)

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Є досить велика кількість різних (внутрішніх, відносно компанії, а не відносно відділу) проектів. Є відділ DevOps (і, частково, Ops) до якого останнім часом задачі ставили через внутрішню систему тікетів (ніяк з Azure DevOps не пов’язану). Внутрішні завдання відділу робились через Azure DevOps таски.

Але зараз є необхідність зробити повністю прозорий трекінг роботи відділу через якусь одну систему. Але проблема в тому, що у Azure DevOps можна визначити тільки «Очікуваний час на задачу», трекінгу як такого я не бачу, ставити стороннє ПЗ — треба узгодити і зрозуміти, що саме воно і треба. Крім того, в самому Azure DevOps це виглядає як купа різних проектів, тож таски теж розкидані по проектах, кожен внутрішній замовник бачить тільки свій проект і свої таски — відділ Ops/DevOps бачить всі проекти. Дашборди і вся статистика вона по-проектна, а збирати це в статистику по відділу доволі важко.

Частина тасок — одноразова (Ops — міграції даних, бекапи і все те, що так чи інакше робиться «руками», або DevOps — зміни в проекті, але не величкі — наприклад змінили конфігурацію, розмір стораджа, наприклад, комміт, деплой) Тут підходить трекінг просто за кількістю тасок, бо трекати 10, 20, 30 хвилин чи кожну годину якось зайве. Частина — повноцінна розробка — від розробки модулів terraform/python до написання коду інфраструктури великого проекту — тут більше підходить підхід звичайної розробки з трекінгом часу на таски. І ще частина — щось по середині, чи проста таска може перейти в зміни в модулі, зміни в проекті і розтягнутися на місяць, наприклад.

Плюс частина внутрішніх замовників не мають проектів в Azure DevOps, працюють через внутрішню систему тікетів. Поки не зовсім зрозуміло, як їх туди переносити. Один проект чи кілька і взагалі — чи варто.

Питання, як з цим всім жити? Якщо у вас є подібний досвід — то як це робите? Як надати статистику по завантаженню співробітників відділу? Зрозуміти (і показати «наверх», що важливіше, бо всередині, якраз, все зрозуміло), що треба ще люди, наприклад.

Яким ПЗ користуєтесь? Хоча, звісно, спочатку треба прийти до якоїсь системи, а вже під неї шукати ПЗ.