Эта статья является третьей в серии статей, мы рекомендуем сначала прочитать часть 1 и часть 2:

• Рождение гибкой телеметрии в OVHcloud — Часть I
• Гибкая телеметрия в OVHCloud — Часть II

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

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

Для команд разработчиков микровидение имеет решающее значение. В то время как макроэкономическая перспектива важна для достижения таких целей, как сроки поставки, наблюдение за микродетализацией разработки обеспечивает хорошее качество продукта. Вот как нам удалось достичь этой важной цели:

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

Три блока данных

В этой части нашей панели инструментов отображаются три важных элемента информации, касающихся хода наших спринтов: ожидаемое, неожиданное и причина неожиданного.



BurdownChart

(1) Это прогресс текущего спринта и его процент завершения. Процент выполнения просто вычисляется:



(2) Это показывает, сколько раз команда разработчиков выходила из спринта, чтобы что-то исправить, и время завершения. На прилагаемом графике показаны пиковые дни, когда команда была мобилизована.



Чтобы сообщить об этом типе информации:

• Команды добавляют в поле «Ярлык» JIRA заголовок: препятствие.
• Они регистрируют время, проведенное в поле «Журнал работы» в JIRA.

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

NB: Важно отделить спринт от препятствий. Эти две части информации позволяют сравнить «ожидаемое» и «неожиданное». Это позволяет предложить 2 типа графиков.

(3) В последней части рассказывается, почему команды вмешались, когда они вышли из спринта. Эти ценные данные дают нам четкое представление о ситуации. Если команда тратит 90% своего времени на устранение ошибок или устранение неполадок в поддержке, это дает информацию о процессах принятия решений для будущих проектов.



Природа препятствия

Пример: мы предоставляем 30 часов на исправление ошибок во время спринтов; должны ли мы сосредоточиться на создании чего-то нового или сокращении технического долга?

Вывод: Сегодня Agile-телеметрию используют 19 команд в OVHCloud. Это облегчает и позволяет нам измерять производительность и прогресс команд удаленно и в режиме реального времени. Он также предоставляет нам актуальную информацию, необходимую для реализации наших проектов. Именно эта методология получила награду Innovations Awards для сотрудников OVHCloud.

Если вы хотите погрузиться в Agile Telemetry, вы можете сделать это прямо сейчас!!! Просто возьмите нашу панель инструментов с открытым исходным кодом и нашего бота Jerem — github.com/ovh/jerem.

В предыдущем посте мы изложили причины, которые побудили нас создать инструмент 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!

В октябре 2018 года, незадолго до саммита OVHcloud, я присоединился к платформе Product Unit Platform в качестве менеджера программы. С этой новой ролью возникла новая задача… поддержать команду, работающую над новым продуктом: OVHcloud Managed Kubernetes. Крайний срок был коротким, у нас было много дел, и нам нужно было обеспечить видимость как для менеджеров, так и для команд разработчиков. Но как программный менеджер у меня в сумке были нужные инструменты: SCRUM и agility.



Моим первым действием, как новичком, было попросить команду выразить себя. Я хотел понять, как работает группа, поскольку слушание — один из первых шагов в процессе гибкого строительства.

Имея дело со значительными изменениями, необходимо управлять изменениями и сопровождать людей на протяжении всего процесса. Слишком часто слово «agile» употребляется таким образом, чтобы жертвовать здравым смыслом, становясь козлом отпущения, когда происходят непредвиденные события или задержки в доставке. Ключевой задачей было успокоить команду и объяснить им, что гибкость не сделает их жизнь тяжелее или добавит накладных расходов к повседневным задачам. Мы добились этого несколькими способами:

• Организация нескольких презентаций и методических занятий
• Проведение личных встреч с командами в Париже и Лионе 
• Объяснение того, как метод будет работать во время реального спринта
• C ollectively разрабатывает руководство для нашей реализации метода SCRUM 

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

Ценность нашей маневренности

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

Чтобы быстро (пере) определить это, скорость — это количество «очков усилий», которые команда может выполнить во время спринта. Этот ключевой показатель позволил нам оценить, сколько работы наша команда могла бы выполнить за определенный период времени.

Скорость и усилия в нашем проекте Managed Kubernetes

Давайте посмотрим на упрощенную схему того, как этот метод работал в нашем проекте Managed Kubernetes:



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



Пример:



Эта гибкая модель позволила нам достичь нашей цели и вовремя доставить проект Managed Kubernetes нашим клиентам, и этот успех впоследствии побудил нас поделиться этими передовыми методами со всеми командами в подразделении продукта.

Но возникла вторая проблема, так как поддержание этого процесса требовало большой дисциплины, с многочисленными возможностями для совершения ошибок. Итак, нашим следующим шагом было создание инструмента, способного снизить риск ошибки, сохраняя при этом полную видимость проектов как на макро-, так и на микроуровне. Это то, что мы подробно представим в следующем сообщении блога: Agile-телеметрия от OVHcloud.