Метрики в разработке

         За те 15-20 лет что я программирую, я не раз наблюдал попытки измерить этот процесс. Как правило это было сделано максимально некомпетентно, людьми которые ничего не понимали в разработке.  Приходили какие-то "эффективные менеджеры", желающие выслужится и начинали заставлять трэкать время,  считать твои коммиты, строчки кода, или закрытые тикеты.  Я всегда пытался объяснить этим людям, что все не так просто как они думают. Но они упорно не понимали меня, потому что никогда не программировали или делали это так давно что у же забыли.  Это все равно что объяснить человеку который никогда не плавал, какого это - плавать. 

       Наконец-то я нашел адекватное исследование на эту тему - https://queue.acm.org/detail.cfm?id=3454124 Я крайне рекомендую прочитать его прежде чем внедрять эти метрики. Они предлагают метод называемый SPACE. В рамках этого метода они предлагают использовать 5 измерений: удовлетворенность, производительность, активность, коммуникативность и эффективность. В каждом измерении они предлагают ряд метрик которые можно измерить, либо измерений которые могут быть использованы как прокси-метрики для целевых метрик. К примеру удовлетворенность саму по себе измерить трудно, но можно легко замерить уровень текучки в коллективе (turnover), которая  может служить в каком-то приближении прокси-метрикой для удовлетворенности (не удовлетворен =>уходишь). Мне лень переводить все, поэтому дальше просто короткое обобщение на английском:

• Satisfaction and well-being dimension
• Best captured with surveys. To assess the satisfaction dimension, you might measure the following:
• Employee satisfaction. The degree of satisfaction among employees, and whether they would recommend their team to others.
• Developer efficiency. Whether developers have the tools and resources they need to get their work done.
• Burnout. Exhaustion caused by excessive and prolonged workplace stress.
• Productivity and satisfaction are correlated, and it is possible that satisfaction could serve as a leading indicator for productivity; a decline in satisfaction and engagement could signal upcoming burnout and reduced productivity
• Performance dimension - is the outcome of a system or process.
• Can be measured with following metrics
• Quality. Reliability, absence of bugs, ongoing service health.
• Impact. Customer satisfaction, customer adoption and retention, feature usage, cost reduction.
• Activity dimension - is a count of actions or outputs completed in the course of performing work. Metrics can be:
• Design and coding. Volume or count of design documents and specs, work items, pull requests, commits, and code reviews.
• Continuous integration and deployment. Count of build, test, deployment/release, and infrastructure utilization.
• Operational activity. Count or volume of incidents/issues and distribution based on their severities, on-call participation, and incident mitigation.
• Communication and collaboration dimension - capture how people and teams communicate and work together. Following are examples of metrics that may be used as proxies to measure communication, collaboration, and coordination
• Discoverability of documentation and expertise.
• How quickly work is integrated.
• Quality of reviews of work contributed by team members.
• Network metrics that show who is connected to whom and how.
• Onboarding time for and experience of new members
• Efficiency and flow dimension - capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system Some example metrics to capture the efficiency and flow dimension are:
• Number of handoffs in a process; number of handoffs across different teams in a process.
• Perceived ability to stay in flow and complete work.
• Interruptions: quantity, timing, how spaced, impact on development work and flow.
• Time measures through a system: total time, value-added time, wait time.

Также авторы исследования разъясняют как этот метод можно применять для SRE команд и управления инцидентами.

Есть хорошее исследование предложенное DevOps Research and Assessment (DORA) - https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance 

Они предложили простой фреймворк из метрик (изначально 4-х метрик, reliability добавили потом), которые довольно легко измерять:

• Deployment Frequency—How often an organization successfully releases to production
• Lead Time for Changes—The amount of time it takes a commit to get into production
• Change Failure Rate—The percentage of deployments causing a failure in production
• Time to Restore Service—How long it takes an organization to recover from a failure in production
• Reliability - represent availability, latency, performance, and scalability

Это сильно проще чем SPACE фреймворк, но они сознательно убрали из рассмотрения все не техническое - мотивацию, удовлетворенность и тд. 

Ну и в завершении обзора подходов к оценки производительности команд - набор метрик для платформенных команд:

• Platform adoption rate - Measures how many product teams or services actively use the platform against those that don't.
• Mean time to onboard (MTTO) - mean time to unboard
• Platform service uptime
• Feedback loop duration - Tracks the average time from when users provide feedback to when the platform team addresses it.

Метрики довольно простые и логичные, но не все из них легко реализуемы на практике (я имею ввиду автоматизированное измерение)

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

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