[2/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика DevEx)
Продолжим рассмотрение статьи про developer productivity обсуждение проблем опросов, которые часто используются для ответов на вопросы о продуктивности.
Представим опрос про связь самооценки продуктивности инженеров и воспринимаемого уровня качества кода. Даже получив результаты опросы, у нас эффекты, что мешают вывести причинно-следственную связь между качеством кода и продуктивностью 1) Time-invariant effects - эти эффекты имеют тот же самый эффект в разные моменты времени, например, уровень образования респондентов 2) Respondent-independent time effects - это эффекты, которые влияют на респондентов одинаково, например, сезонные эффекты или крупные инициативы на всю компанию 3) Non-differentiated response effects - это эффекты, когда респонденты склонны давать одинаковый ответ на все вопросы. У одного респондента это может быть средний вариант ответа на все вопросы, а у другого самый высокий. Но в панельном исследовании есть возможность устранить эти эффекты, анализируя данные за разные промежутки времени, а также есть возможность попробовать установить не только корреляции, но и причинно-следственные связи. Дальше авторы описывают связанные научные работы и показывают как обычно использовались time-series данные и что их можно использовать для ответов на часть вопросов, изначально поставленных в исследовании. Правда, эти эти способы не использовались раньше для анализа developer productivity, а также они не подходят для того типа данных, что используют авторы этого исследования.
Дальше авторы переходят к рассказу о методах панельного исследования, где в качестве источников данных используются
- Данные из логов использования внутренних инструментов, навроде, данных о редактировании файлов, билдах, работе в системе codee review и так далее. Важно отметить, что эти данные содержат хорошо гранулированную историю о работе инженеров, что точно измерять поведение инженеров и характеризовать используемые ими рабочие практики и задачи, которые они выполняют при этом.
- Данные лонгитюдных исследований (опросов), которые проводятся посредством EngSat (engineering satisfaction survery). Это долговременные исследования в виде опросов, ответы на которые собираются каждый квартал у трети инженеров. Подробнее про них в отдельном whitepaper "Measuring Developer Experience With a Longitudinal Survey", про который я уже рассказывал.
Дальше описываются зависимые и независимые переменные, которые используются в модели исследования и объясняется как мы строим модель, чтобы ее можно было ответить на изначальные вопросы исследования. В качестве зависимых переменных используются самооценки продуктивности инженеров, которые взяты из опросов. С одной стороны именно эту переменную исследовали в других исследованиях и выявили некоторую корреляцию между субъективным и объективными исследованиями. В качестве объективных метрик были взяты следующие три категории метрик 1) The amount of output (per quater) - тут было 2 метрики: total number of changelists и total lines of code 2) The amount of time per item (changelist) - тут было 2 метрики: median active coding time, median well-clock coding 3) The amount of time for non-productive activities - тут было 2 метрики: median wall-clock review time и median wall-clock merge time
Для анализа авторы собрали данные 6 последовательных кварталов с 2018Q1 по 2019Q2. Для анализа у исследователей накопилось порядка 2к точекк и дальше они построили модельку, что на рандомно выбранных 10% данных для валидации получили 83% precision и 99% recall. Причем основным предиктивным фактором оказался Median Active Coding TIme, что кажется логичным.
На этом этот пост заканчивается, а в следующий раз я расскажу про независимые переменные и модельку целиком.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes