Как настроить дашборды в Azure DevOps, чтобы они приносили пользу

    Если вы когда-нибудь использовали проектную аналитику, то наверняка в какой-то момент разочаровывались в этом инструменте. Многие PM-ы со временем забрасывают дашборды, потому что данные оказывается сложно применить для пользы дела. Мы тоже через это прошли и теперь хотим поделиться опытом – как превратить проектную аналитику в действительно удобный инструмент.

    Рассказывать будем на примере Azure DevOps (TFS), который с этого года используют все команды True Engineering. В разное время мы перебрали разные системы управления проектами, и в итоге поняли, что именно Azure DevOps объединяет в себе практически всё, что нужно разработчику: управление проектом, репозиторий кода, управление сборками, тестами и релизами.

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

    Чтобы аналитика оказалась действительно полезной, она должна выполнять следующие условия:

    1. Ещё до появления дашборда вы уже собирали эти данные вручную, а новая панель лишь автоматизирует эту работу.

    2. Дашборд описывает реальные процессы внутри команды, которые имеют прямое отношение к её эффективности.

    3. Аналитика даёт реальное понимание о ситуации, проблемах и рисках, а не просто показывает, какие все молодцы.

    4. Выводы можно масштабировать на другие команды и проекты – у всех появляется единая система координат.

    Теперь расскажем про возможности Azure DevOps в этом отношении.

    Сначала о дашбордах по умолчанию

    Мы спросили наших PM-ов, какие данные из базового набора они используют в своих панелях, и получили следующий список:

    • Lead Time. Показывает время прохождения одной задачи через весь процесс – от создания до закрытия.

    • Cycle Time. Показывает время, которое задача находится в разработке с того момента, как ей начали заниматься, до конечной поставки.

    • Качество поставок. Это количество багов, которые были заведены и прошли проработку в рамках спринта. При нажатии на график можно посмотреть, что это за баги, фильтр позволяет их сортировать (например, можно ввести «спринт 64» и получить всё, что к нему относится).

    Эти показатели дают примерное представление о том, как обстоят дела в команде. Как это часто бывает с базовыми фичами, весь потенциал аналитики они не раскрывают. Например, Lead Time – вроде бы полезный показатель, который показывает, сколько задача висит в бэклоге. Но вот если ваши разработчики, как и мы сами, заводят задачи на несколько спринтов вперёд, ценность этих цифр оказывается небольшой. Можно поставить себе цель – приблизить Lead Time к длительности спринта. Но получается, что вы подстраиваете свои процессы под дополнительный инструмент – зачем это делать, если всё и так работает? Поэтому команды в итоге и отказываются от дашбордов, которые оказываются пятым колесом в прекрасно едущей повозке.

    С другой стороны, в Azure DevOps можно настроить дополнительные панели, чтобы получать аналитику именно в том ключе, который нужен PM-у.

    Какие дополнительные дашборды используются в True Engineering

    Эти панели родились из самой жизни - раньше за такими данными приходилось лезть в разные источники, реестры Excel, рабочие трекеры. Теперь тратить на это время не нужно, достаточно один раз настроить нужную аналитику.

    Так что у каждого PM-а будет свой набор дашбордов, которые нужны именно ему. Для общего представления о том, с какими данными можно так работать, вот несколько примеров из нашего опыта:

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

    • Задачи, не прошедшие ревью. Сюда попадают работы, которые могут попасть проблемную категорию из-за того, что команда слишком поздно или некорректно оценит нужные ресурсы.

    • Незакрытые задачи на PROD. Это уже переданные заказчику задачи, которые по какой-то причине остаются висеть в списке. Для PM-а это повод связаться с клиентом и узнать, нет ли с этими тасками каких-то проблем.

    • Задачи – кандидаты на релиз. Эти данные помогают PM-ам строить планы, понимать, когда каждая задача поступит в релиз. Эта же метрика позволяет проверить полноту релиза - если сборки отличается по составу от дашборда, нужно искать сбой.

    • Высокая оценка в спринте - задачи с трудозатратами более 40 человекочасов, к которым явно требуются особое внимание.

    • Новые задачи в активном спринте - помогает бороться с появлением несогласованных работ по ходу спринта.

    Каждый пункт в этом списке – это потенциальный риск, который PM-у очень важно не пропустить. Окно с аналитикой становится рабочим местом, с которого можно начинать свой день. Пока окошки не горят красным, всё хорошо.

    Какой мы почувствовали эффект от проектной аналитики

    • PM-у не нужно совершать лишние движения, чтобы получить представление о положении дел по спринту. Менеджеры получили удобный доступ к данным, за которыми раньше приходилось идти в разные системы.

    • Если назревают трудности, специальный алёрт заранее о них предупредит. Появляется тревожный сигнал – можно его сразу отработать, пока он не вырос в реальную проблему.

    • Повысилось качество управления – стали дробить PBI на более мелкие таски, ускорили выдачу релизов. Здесь, кстати, помог дашборд Cycle Time из базового набора, так что вовсе отказываться от них не стоит.

    • Не только PM, но и другие участники команды пользуются аналитикой – все говорят на одном языке и знают, какие показатели играют важную роль для релиза. Эти технологии можно легко масштабировать дальше, чтобы вся компания работала по единым успешным практикам.

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое