Данные по навыкам и вкладу кодеров

Продуктивность труда кодеров

Отслеживать количество строк кода, количество методов, классов, сервлетов, таблиц и т.п. Однако лучший подход - количество и сложность тасков. Сложность оценивать по единой шкале, скажем от 1 до 5, независимо от уровня выполняющего задачу кодера. Баги, найденные и закрытые по ходу реализации таска, включаются в таск, не увеличивая его сложность и общую сложность проекта. Дизайн и архитектура, так же как и тестирование должны учитываться отдельно, только если это очень сложные задачи.

Общие рекомендации:

• Отслеживать дизайн, кодирование и тестирование как отдельные таски только в том случае, если эти действия совершались отдельно от основной разработки
• Установить шкалу сложности и оценивать по ней каждый таск
• Если сложность тасков выходит за пределы шкалы, то комбинировать или разделять таски соответствующим образом
• Менять сложность тасков после реализации, для точности и согласованности оценок
• Если над неделимым таском работают два программиста, делить сложность пополам
• Не отслеживать в виде тасков баги, найденные и пофиксенные в ходе разработки
• Отслеживать баги, найденные в продактиве, так же, как и любые другие таски
• Учитывать количество невыполненных тасков, снижая оценку сложности, если таск был выполнен частично

Скорость кодирования

Предлагается оценивать еженедельно или раз в две недели простым делением продуктивности на время

Точность (качество)

Общие рекомендации:

• Отслеживать количество багов, обнаруженных на продактиве, ранжированных по шкале критичности
• Регрессивные баги - +1 к критичности
• Масштаб бага по количеству затронутых пользователей (если возможна такая оценка)
• Определить отдельные области продукта и назначить ответственных кодеров
• Не оценивать сложность исправления до тех пор, пока не принято решение об исправлении

Диапазон областей (функциональных? прикладных?)

• Определить отдельные области продукта, скорее всего, такие же, как для учета багов.
• Удостовериться, что каждый таск привязан к одной или нескольким областям
• Подсчитывать, над сколькими областями работает кодер.

Помощь команде

• Запрашивать у программистов количество запросов от коллег, на которые они отреагировали помощью
• Просить у программистов сообщать о том, что кто-то кому-то помогает. Это можно организовать в виде wiki, например, элемент публичности здорово мотивирует.

Инновации и инициатива

• Просить программистов сообщать о случаях, когда кодер демонстрирует значительные инновации и инициативу
• Просить тимлидов вести подсчет таких случаев для каждого кодера.

Данные по отношению к ПО, багам и конкуренции

Интерес и использование

Метрики Мастерства

Используемые данные:

• Задачи (Tasks) - Назначенные и выполненные задачи для каждого кодера
• Сложность (Complexity) - Уровень сложности для каждой назначенной задачи
• Незавершенка (Incompletes) - Назначенные и невыполненные задания
• Баги в продактиве (Product Issues) - Обнаруженные в продактиве баги в разрезе областей продукта
• Критичность (Severity) - Уровень критичности для каждого бага (+1 для регрессионных)
• Масштаб (Population Affected) - Процент пользователей (оценка или точная цифра), затронутых каждым багом
• Области продукта (Areas Worked) - Количество областей продукта, над которыми работал каждый кодер
• Исправленные баги (Issues Fixed) - Баги в продактиве, исправленные каждым кодером
• Прерывания (Interrupts) - Количество значительных прерываний в работе кодера
• Помощь другим (Helps) - Количество ситуаций, в которых кодер проактивно значительно помогает коллегам / команде
• Плюсы (Pluses) - Количество ситуаций, в которых кодер проявил значительную инициативу или использовал инновационные методы / технологии / фишки.

Игра в нападении

Подобно командным видам спорта, программирование можно разделить на игру в защите и нападении. Игра в нападении - это помощь в продвижении к целям команды / организации.

• Очки (Points) Назначение: Измерить общую продуктивность кодера по назначенным задачам. Отражает относительный объем выполненной работы. Формула: Сумма ( Сложность всех завершенных тасков )
• Полезность (Utility) - Назначение: Измерить общее количество выполненных задач. Формула: Кол-во ( Выполненные задачи)
• Сила (Power) - Назначение: Измерить среднюю сложность тасков кодера. Формула: Очки / Полезность
• Передачи (Assists) - Назначение: Измерить помощь кодера другим членам команды. Формула: Кол-во ( Прерывания ) + Кол-во (Помощь другим)
• Температура (Temperature) - Назначение: Измерить динамику продуктивности кодеров. Формула:
  • Стартовая температура = 72F (но можно взять и 36,6C, например)
  • Текущие очки = очки за последнюю итерацию
  • Предыдущие очки = очки за предпоследнюю итерацию
  • Коэффициент тепла = Текущие Очки / Предыдущие очки
  • Температура = Предыдущая температура х Коэффициент тепла
• Вклад в нападение (Offensive Impact) - Назначение: интегральный показатель игры в нападении. Формула: Очки + Полезность + Передачи.

Игра в защите

Это показатели применения навыков кодера для предотвращения будущих проблем или отклонения от заданного курса проекта.

• Спасброски (Saves) - Назначение: Измерить, как часто кодер помогает исправить критичные баги на продактиве. Формула: Кол-во ( Баги в продактиве с наивысшей Критичностью )
• Отборы (Tackles) - Назначение: Измерить количество ситуаций, в которых кодер действовал проактивно и инновационно. Формула: Кол-во ( Плюсы )
• Диапазон (Range) - Назначение: Измерить количество областей продукта, над которыми работает кодер. Формула: Кол-во ( Области продукта )
• Вклад в защиту (Defensive Impact) - Назначение: Интегральный показатель игры в защите. Формула: ( Спасброски + Подборы) х Диапазон

Метрики точности

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

• Потери мяча (Turnovers) - Назначение: Измерить сложность невыполненных задач. Формула: Сумма ( Сложность назначенных, но не выполненных задач) или Сумма( Сложность всех задач ) - Очки. Примечание: имеется в виду передача Задачи другому программисту. Случаются редко, поэтому лучше оценивать по-проектно.
• Ошибки (Errors) - Назначение: Измерить размах влияния Багов в продактиве по тем областям, за которые отвечал кодер. Формула: Сумма ( Критичность каждого Бага в продактиве х Масштаб ). Примечание: Лучше оценивать чаще, на еженедельной основе, или раз в две недели.
• Плюс-Минус (Plus-Minus) - Назначение: Измерить абсолютный вклад каждого кодера. Формула: Очки - Потери мяча - Ошибки. Примечание: лучше, если Сложность задач и Критичность багов оцениваются по одной шкале (например, от 1 до 4), чтобы избежать “перекосов”. Лучше считать на долгих периодах времени, потому что Баги в продактиве могут обнаруживаться довольно долго.

Типы кодеров

• Архитекторы. Обычно это самые опытные члены команды, поэтому их задачи обычно более сложны и часто связаны с высокоуровневым проектированием. Вероятно они проводят много времени, обучая и помогая другим кодерам. Для них особенно важны следующие метрики:
  • Сила. Скорее всего, у Архитекторов эта метрика будет выше, потому что они берут более сложные Задачи. Обычно Полезность Архитекторов несколько ниже средней, потому что общее количество Задач обычно меньше.
  • Передачи. Обычно выше среднего, потому что они часто помогают другим
  • Диапазон. Обычно задействованы в большем числе областей продукта, чем остальные кодеры
  • Отборы. Хорошие Архитекторы обычно предотвращают возникновение багов и заблаговременно решают ключевые проблемы.
• Старшие кодеры. Технически более опытные, поэтому показывают более высокую продуктивность, качество и в отдельных случаях - лидерство. Метрики, отражающие их вклад:
  • Очки. Эти кодеры выполняют либо более сложные таски, либо большое количество обычных задач. Обычно их Очки выше среднего.
  • Вклад в нападение. Обычно выше среднего.
  • Вклад в защиту. Обычно выше среднего.
  • Температура. Стабильность работы обычно очень высока, температура как правило сильно не меняется.
• Младшие кодеры. Широкий разброс возможных характеристик, темные лошадки. Полезно мониторить все метрики, хотя небольшой набор особенно важен:
  • Полезность. В большинстве случаев этим кодерам не дают сложные таски.
  • Отборы. Обычно младшие кодеры не очень инициативны, поэтому каждый Отбор очень важен.
  • Потери мяча. Важно, чтобы понимать, когда Младшему кодеру нужна помощь. Низкое число Потерь мяча - хороший знак.
  • Плюс-Минус. У Архитекторов и Старших кодеров эта метрика более стабильна, у Младших кодеров в идеале хотелось бы увидеть постоянный рост.

Метрики отклика

Внедрение КодерМетрик

Набор простых шагов, которые нужно предпринять при внедрении.

1. Найдите спонсора - человека, который обладает авторитетом, достаточным для того, чтобы принять решение о внедрении / невнедрении.
2. Создайте фокус-группу. Придайте эксперименту публичность. Члены фокус-группы должны будут выбрать первоначальный набор метрик и проекты, для которых будет осуществляться сбор данных.
3. Выберите метрики. Лучше остановиться на тех, что интересны / применимы ко всей команде (Метрики Отклика: Выигрыши, Проигрыши, Доля Выигрышей / Проигрышей, Штрафные, Штрафные на Выигрыш). Небольшой набор Метрик Мастерства, например, Очки, Полезность, Спасброски, Ошибки.
4. Установите временные рамки. Три-четыре месяца - это адекватный срок.
5. Проведите тест-драйв. По ходу периодически собирайте фокус-группу и обсуждайте следующее:
   • Открывают ли Метрики новую информацию, о которой ничего не знали или сомневались насчет нее?
   • Поддерживают ли Метрики существующие предположения или опровергают их?
   • Могут ли менеджеры команд использовать метрики для улучшения работы команд? Если да, то каким образом?
   • Могут ли конкретные кодеры использовать метрики для улучшения своей работы? Если да, что чему они могут научиться?
6. Представьте метрики команде
7. Создайте хранилище метрик
8. Расширьте набор метрик
9. Инициируйте обсуждение