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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какие дополнительные дашборды используем мы

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

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

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

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

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

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

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

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

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

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

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

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

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

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