DevOps Metrics. Your biggest mistake might be collecting the wrong data (Рубрика Management)
Ради интереса я решил прочитать whitepaper шестилетней давности, в котором Nicole Forsgren и Mik Kersten рассказывали о devops метриках. Интересно, что статья начинается с цитат великих
“Software is eating the world.” —Marc Andreessen “You can't manage what you don't measure.” —Peter Drucker А дальше начичнается погружение в эру digital и devops трансформаций и продажа разнообразным CIO рассказов о том, что организации зачастую не достигают целей IT из-за проблем со скоростью поставки программного обеспечения. И для того, чтобы улучшить эти процессы авторы предлагают поработать над созданием метрик, которые позволят обеспечить прозрачность и управляемость в этой области. Для этого они предлагают комбинировать 2 типа данных
1) System-based metrics Это метрики, которые строятся на основе данных из реальных систем. Например, данные о сборках, автотестах, релизах, работе в IDE и так далее. При рассмотрении этих данных требуется учесть аспекты
- Completeness - достаточно ли полны данные, собранные из определенной системы для обеспечения той наглядности, метрик и отчетов, которые являются целью инициативы?
- Comprehensiveness - достаточно ли данных собрано во всех системах для учета сквозной метрики, например, time-to-market?
- Correctness - достаточно ли скоррелированы данные, чтобы быть правильными? Условно надо уметь матчить совпадающие данные из разных систем У этих метрик есть крутые преимущества
- Precision - данные в системах создаются с большой точностью
- Continuous visibility - данные из систем доступны в реальном времени, можно работать на потоке данных или анализировать их пост-фактум
- Granularity - мы можем смотреть на данные из разных подсистем или компонент или наоборот подняться на уровень системы
- Scalability - когда система сбора данных имплементирована, то ее можно растянуть на все продукты/проекты Но есть и сложности
- Gaining a holistic view - во-первых сложно собрать данные со всех систем (нужен тулинг), а также из-за того, что у нас социо-технические системы, то нужна информация из глаз разработчиков о том, как работают инженерные процессы
- Capturing drifts in the system - при изменениях в системах данные из них могут не обновляться, что дает неактуальную картину
2) Survey-based metrics Это метрики на основе проведения опросов о том, как работают процессы, системы или сами люди чувствуют себя:) У таких данных есть следующие важные аспекты - Cohesiveness - данные, полученные в ходе опросов, особенно хороши для предоставления полного и целостного представления о системах. - Correctness - разработка и измерение опросов является хорошо изученной дисциплиной, которую можно использовать для предоставления качественных данных и понимания систем и культуры.
У этих метрик есть крутые преимущества
- Accuracy при правильном сборе данных
- A holistic view of the system - ответы, которые предоставляют респонденты, отражают их общее восприятие ситуации
- Triangulation with system data - можно сочетать с системными данными
- Capturing behavior outside of the system
- Cultural or perceptual measures related to the system Но список недостатков тоже широк: precision данных не очень велик, получать данные постоянно невозможно (никто не будет заполнять опросы слишком часто), объем собранных данных (мало кто готов заполнять сложные опросы даже редко). А также если данные опросов используются для оценок, то ответы в опросах могут быть смещены в сторону ожиданий топ-менеджмента.
В общем, по итогу авторы приходят к выводу, что комбинация двух подходов дает отличный эффект. Кстати, подробнее про развитие этой темы можно почитать в моем посте "Зачем заниматься темой developer productivity в большой компании"
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes