Гибкая телеметрия в OVHCloud - Часть II

В предыдущем посте мы изложили причины, которые побудили нас создать инструмент Agile-мониторинга. Чтобы извлечь выгоду из этого коллективного успеха, нам нужно было:

  • Установите эффективную, простую и общепринятую методологию поддержки команд разработчиков.
  • Изложите различные видения, необходимые для правильного выполнения проекта.
  • Определите микровидение для команд разработчиков.
  • Определите макро-видение для спонсоров.
  • Индустриализируйте эту инновационную концепцию для других команд в OVHcloud.



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

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

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

Первый каркас гибкой телеметрии

Этот первый набросок выдвинул на первый план то, что я хотел показать своим командам. Мы могли отслеживать наши успехи по каждой теме, над которой работали (эпосы, о которых мы говорили в части I). Мы смогли увидеть, достижима ли дорожная карта, исходя из ритма работы команды, и измерить производительность команды. Наконец, у нас появился инструмент, который согласовывал микро- и макро-видение.

Но как заставить эту доску ожить?

В OVHcloud мы используем инструмент для продажи билетов: JIRA. Этот инструмент помогает нам в повседневной организации проектов. Однако он не показывает нужную нам информацию. Тем не менее, мы можем заставить его говорить…



Основываясь на этой концепции, мы и наши команды создали таблицу показателей с помощью инструмента GRAFANA.

Это наша гибкая телеметрия



В этом втором посте блога мы сосредоточимся на макро видении. В следующем посте мы рассмотрим микровидение.

Макровидение



1- й блок данных: Квартальные КПЭ



  • (А) Предсказуемость. Сможете ли вы выполнить все проекты / запросы? С помощью этого индикатора высшее руководство и команды разработчиков могут отслеживать свои возможности в отношении сроков. Мы можем отслеживать эти данные по следующей формуле:



  • (B) Прогресс на четверть . Показывает завершенные части квартала.
  • © Скорость команды. Количество сюжетных пунктов, завершенных за день. Обладая этой информацией, мы можем строить наши будущие спринты и поддерживать ритм команды.
  • (D) Среднее препятствие . Эта информация важна для построения следующего спринта и оценки коэффициента безопасности.

Пример

Предположим, у нас есть команда из семи человек с производительностью 350 часов на спринт (7 человек x 5 часов в день x 10 дней). Если наша команда зафиксировала 58 часов в качестве препятствий во время спринта, мы могли бы использовать эту информацию, чтобы настроить коэффициент безопасности для следующего спринта.



В среднем команда тратит 17% своего времени на устранение препятствий во время спринта. Имея эту информацию, мы можем рассчитать коэффициент безопасности.

2-й блок данных: «Sum of Roadmap Epics»



В этой таблице собраны ожидаемые эпопеи. Он показывает количество очков истории, оцененных командами, количество очков, которые они уже выполнили, количество задач, «не оцененных», и скорость прогресса. С помощью этой таблицы мы можем дать цифры, относящиеся к прогрессу.

3-й блок данных: Завершение



  1. Эпическое завершение ( 1 ): в течение каждой недели мы можем наблюдать за развитием дорожной карты. Иногда мы видим, что дорожная карта завершения сокращается. Это нормально, потому что мы добавили в план сюжетную линию. ( 4 )
  2. Количество препятствий (2): это количество раз, когда команды выходили из спринта из-за препятствий.
  3. Длительность препятствий (3): общее время, потраченное на препятствия.
  4. Запланированная дельта-точка истории (4): количество точек, входящих или выходящих из дорожной карты, что позволяет нам видеть любые вариации на графиках.

4- й блок данных: Нарисуйте график!



  • А. Этот рисунок представляет собой график выполнения дорожной карты. Он создан по сумме завершенных эпосов.
  • Б. Наша дорожная карта выгорания.

На этом графике представлены две кривые:

  • a  — Кривая элементов, количественно определенная и оцененная командами.
  • b  — это предел, рассчитанный с использованием скорости команды по количеству дней в квартале. Затем мы добавляем коэффициент безопасности команды.





  • c — Кривая задач, выполненных командами.

Вывод

Эта панель инструментов объединяет всю информацию, которую нам удалось собрать воедино благодаря потрясающему вкладу команд. Веруя в ценности и доверяя методу, группа уже достигла зрелости, которой они достигли сами.

Для нашего высшего руководства эта доска показывает всю необходимую им ключевую информацию. Когда прогнозируемость обозначена зеленым цветом, все в порядке. Когда что-то не так, они могут принять правильное решение, будь то изменение приоритетов в дорожной карте или найм новых людей, чтобы помочь командам успешно ее завершить (например).

В следующем посте я подробно расскажу о микровидении. А пока сохраняйте Agile!

0 комментариев

Оставить комментарий