[Управление проектами] Как настроить дашборды в Azure DevOps, чтобы они приносили пользу
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Если вы когда-нибудь использовали проектную аналитику, то наверняка в какой-то момент разочаровывались в этом инструменте. Многие PM-ы со временем забрасывают дашборды, потому что данные оказывается сложно применить для пользы дела. Мы тоже через это прошли и теперь хотим поделиться опытом – как превратить проектную аналитику в действительно удобный инструмент.Рассказывать будем на примере Azure DevOps (TFS), который с этого года используют все наши команды. В разное время мы перебрали разные системы управления проектами, и в итоге поняли, что именно Azure DevOps объединяет в себе практически всё, что нужно разработчику: управление проектом, репозиторий кода, управление сборками, тестами и релизами.И, возвращаясь к нашей теме, здесь есть дашборды, которые позволяют отслеживать динамику команд, качество релизов, отработку багов. Одни встроены в систему по умолчанию, другие можно настроить руками.Чтобы аналитика оказалась действительно полезной, она должна выполнять следующие условия:
- Ещё до появления дашборда вы уже собирали эти данные вручную, а новая панель лишь автоматизирует эту работу.
- Дашборд описывает реальные процессы внутри команды, которые имеют прямое отношение к её эффективности.
- Аналитика даёт реальное понимание о ситуации, проблемах и рисках, а не просто показывает, какие все молодцы.
- Выводы можно масштабировать на другие команды и проекты – у всех появляется единая система координат.
Теперь расскажем про возможности 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, но и другие участники команды пользуются аналитикой – все говорят на одном языке и знают, какие показатели играют важную роль для релиза. Эти технологии можно легко масштабировать дальше, чтобы вся компания работала по единым успешным практикам.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Управление проектами, Управление медиа] Google и Ростуризм запустили проект «Раскуси Россию» о русской кухне
- [IT-инфраструктура, Управление проектами, Инженерные системы] Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 4
- [Управление проектами] Не спешите, делайте как следует: Общинное Управление (перевод)
- [Информационная безопасность, Управление проектами, Облачные сервисы] Данные досок Trello тысяч российских компаний попали в открытый доступ
- [Управление проектами, Agile, Развитие стартапа, DevOps, Удалённая работа] Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)
- [Управление проектами, Управление персоналом] 3 пути к возрождению организации
- [Анализ и проектирование систем, Управление проектами, Инженерные системы] Архитектура архитектуры. Шаг 5: один за всех и все на одного
- [Управление проектами, Законодательство в IT] Гражданам РФ начнут заводить учетную запись на госуслугах по умолчанию
- [Управление разработкой, Управление проектами, Управление персоналом] 13 типов разработчиков, с кем я работал (перевод)
- [Управление проектами, Управление продуктом, Бизнес-модели, IT-компании] «Яндекс.Лавка» откроется в Париже и Лондоне
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_proektami (управление проектами), #_proektnaja_analitika (проектная аналитика), #_azure_devops, #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 07:23
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Если вы когда-нибудь использовали проектную аналитику, то наверняка в какой-то момент разочаровывались в этом инструменте. Многие PM-ы со временем забрасывают дашборды, потому что данные оказывается сложно применить для пользы дела. Мы тоже через это прошли и теперь хотим поделиться опытом – как превратить проектную аналитику в действительно удобный инструмент.Рассказывать будем на примере Azure DevOps (TFS), который с этого года используют все наши команды. В разное время мы перебрали разные системы управления проектами, и в итоге поняли, что именно Azure DevOps объединяет в себе практически всё, что нужно разработчику: управление проектом, репозиторий кода, управление сборками, тестами и релизами.И, возвращаясь к нашей теме, здесь есть дашборды, которые позволяют отслеживать динамику команд, качество релизов, отработку багов. Одни встроены в систему по умолчанию, другие можно настроить руками.Чтобы аналитика оказалась действительно полезной, она должна выполнять следующие условия:
Эти показатели дают примерное представление о том, как обстоят дела в команде. Как это часто бывает с базовыми фичами, весь потенциал аналитики они не раскрывают. Например, Lead Time – вроде бы полезный показатель, который показывает, сколько задача висит в бэклоге. Но вот если ваши разработчики, как и мы сами, заводят задачи на несколько спринтов вперёд, ценность этих цифр оказывается небольшой. Можно поставить себе цель – приблизить Lead Time к длительности спринта. Но получается, что вы подстраиваете свои процессы под дополнительный инструмент – зачем это делать, если всё и так работает? Поэтому команды в итоге и отказываются от дашбордов, которые оказываются пятым колесом в прекрасно едущей повозке. С другой стороны, в Azure DevOps можно настроить дополнительные панели, чтобы получать аналитику именно в том ключе, который нужен PM-у.Какие дополнительные дашборды используем мыЭти панели родились из самой жизни - раньше за такими данными приходилось лезть в разные источники, реестры Excel, рабочие трекеры. Теперь тратить на это время не нужно, достаточно один раз настроить нужную аналитику.Так что у каждого PM-а будет свой набор дашбордов, которые нужны именно ему. Для общего представления о том, с какими данными можно так работать, вот несколько примеров из нашего опыта:
Каждый пункт в этом списке – это потенциальный риск, который PM-у очень важно не пропустить. Окно с аналитикой становится рабочим местом, с которого можно начинать свой день. Пока окошки не горят красным, всё хорошо. Какой мы почувствовали эффект от проектной аналитики
=========== Источник: habr.com =========== Похожие новости:
Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 07:23
Часовой пояс: UTC + 5