Рождение гибкой телеметрии в OVHcloud - Часть I
В октябре 2018 года, незадолго до саммита OVHcloud, я присоединился к платформе Product Unit Platform в качестве менеджера программы. С этой новой ролью возникла новая задача… поддержать команду, работающую над новым продуктом: OVHcloud Managed Kubernetes. Крайний срок был коротким, у нас было много дел, и нам нужно было обеспечить видимость как для менеджеров, так и для команд разработчиков. Но как программный менеджер у меня в сумке были нужные инструменты: SCRUM и agility.
Моим первым действием, как новичком, было попросить команду выразить себя. Я хотел понять, как работает группа, поскольку слушание — один из первых шагов в процессе гибкого строительства.
Имея дело со значительными изменениями, необходимо управлять изменениями и сопровождать людей на протяжении всего процесса. Слишком часто слово «agile» употребляется таким образом, чтобы жертвовать здравым смыслом, становясь козлом отпущения, когда происходят непредвиденные события или задержки в доставке. Ключевой задачей было успокоить команду и объяснить им, что гибкость не сделает их жизнь тяжелее или добавит накладных расходов к повседневным задачам. Мы добились этого несколькими способами:
После того, как мы вместе проверили основы, мы перешли к методологии. На этом этапе мы могли бы начать добавлять ценность проекту, используя гибкость.
После нескольких спринтов с использованием гибкого метода наша группа обрела некоторую стабильность, то есть мы достигли хорошей «скорости», как мы называем это на сленге практиков Agile. Скорость — важная ценность и определяющий фактор в нашем постоянном движении к гибкой телеметрии.
Чтобы быстро (пере) определить это, скорость — это количество «очков усилий», которые команда может выполнить во время спринта. Этот ключевой показатель позволил нам оценить, сколько работы наша команда могла бы выполнить за определенный период времени.
Давайте посмотрим на упрощенную схему того, как этот метод работал в нашем проекте Managed Kubernetes:
Здесь у нас есть три основных шага. Для каждого из них мы собрали количественные значения, чтобы получить консолидированное представление о скорости каждого шага в дополнение к глобальному обзору всего проекта. С такими скоростями мы получили хорошее представление о продвижении проекта и некоторую видимость сроков.
Пример:
Эта гибкая модель позволила нам достичь нашей цели и вовремя доставить проект Managed Kubernetes нашим клиентам, и этот успех впоследствии побудил нас поделиться этими передовыми методами со всеми командами в подразделении продукта.
Но возникла вторая проблема, так как поддержание этого процесса требовало большой дисциплины, с многочисленными возможностями для совершения ошибок. Итак, нашим следующим шагом было создание инструмента, способного снизить риск ошибки, сохраняя при этом полную видимость проектов как на макро-, так и на микроуровне. Это то, что мы подробно представим в следующем сообщении блога: Agile-телеметрия от OVHcloud.
Моим первым действием, как новичком, было попросить команду выразить себя. Я хотел понять, как работает группа, поскольку слушание — один из первых шагов в процессе гибкого строительства.
Имея дело со значительными изменениями, необходимо управлять изменениями и сопровождать людей на протяжении всего процесса. Слишком часто слово «agile» употребляется таким образом, чтобы жертвовать здравым смыслом, становясь козлом отпущения, когда происходят непредвиденные события или задержки в доставке. Ключевой задачей было успокоить команду и объяснить им, что гибкость не сделает их жизнь тяжелее или добавит накладных расходов к повседневным задачам. Мы добились этого несколькими способами:
- Организация нескольких презентаций и методических занятий
- Проведение личных встреч с командами в Париже и Лионе
- Объяснение того, как метод будет работать во время реального спринта
- C ollectively разрабатывает руководство для нашей реализации метода SCRUM
После того, как мы вместе проверили основы, мы перешли к методологии. На этом этапе мы могли бы начать добавлять ценность проекту, используя гибкость.
Ценность нашей маневренности
После нескольких спринтов с использованием гибкого метода наша группа обрела некоторую стабильность, то есть мы достигли хорошей «скорости», как мы называем это на сленге практиков Agile. Скорость — важная ценность и определяющий фактор в нашем постоянном движении к гибкой телеметрии.
Чтобы быстро (пере) определить это, скорость — это количество «очков усилий», которые команда может выполнить во время спринта. Этот ключевой показатель позволил нам оценить, сколько работы наша команда могла бы выполнить за определенный период времени.
Скорость и усилия в нашем проекте Managed Kubernetes
Давайте посмотрим на упрощенную схему того, как этот метод работал в нашем проекте Managed Kubernetes:
Здесь у нас есть три основных шага. Для каждого из них мы собрали количественные значения, чтобы получить консолидированное представление о скорости каждого шага в дополнение к глобальному обзору всего проекта. С такими скоростями мы получили хорошее представление о продвижении проекта и некоторую видимость сроков.
Пример:
Эта гибкая модель позволила нам достичь нашей цели и вовремя доставить проект Managed Kubernetes нашим клиентам, и этот успех впоследствии побудил нас поделиться этими передовыми методами со всеми командами в подразделении продукта.
Но возникла вторая проблема, так как поддержание этого процесса требовало большой дисциплины, с многочисленными возможностями для совершения ошибок. Итак, нашим следующим шагом было создание инструмента, способного снизить риск ошибки, сохраняя при этом полную видимость проектов как на макро-, так и на микроуровне. Это то, что мы подробно представим в следующем сообщении блога: Agile-телеметрия от OVHcloud.
0 комментариев