Гибкие метрики для измерения производительности вашей команды разработчиков программного обеспечения

Следующая статья поможет вам: Гибкие метрики для измерения производительности вашей команды разработчиков программного обеспечения

Agile-манифест состояния, «Рабочее программное обеспечение является основным мерилом прогресса». Однако «сделано» говорит только о половине истории. Другая половина обычно скрыта под кипами документации, многочасовыми звонками, сообщениями в Slack, досками Trello — данными, которые хранят волшебство и идеи для руководителей групп разработки программного обеспечения и менеджеров проектов.

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

Зачем применять измерения и метрики программного обеспечения?

При правильном установлении показатели производительности в разработке программного обеспечения приносят ряд преимуществ всем, кто работает над проектом:

Точное планирование
Руководитель группы и руководитель проекта могут лучше обнаруживать возникающие проблемы, расставлять приоритеты и вести учет возникающих проблем. Это повышает общий уровень производительности команды и позволяет более точно прогнозировать результаты.

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

Прочные отношения с клиентами
Эффективные измерения способствуют более прозрачным отношениям с клиентами. Таким образом, клиенты гарантируют, что все требования будут выполнены в установленные сроки и в рамках бюджета.

Открытие
Помимо того факта, что вы можете контролировать ход работы, неотъемлемая ценность метрик заключается в открытии. Эти маленькие золотые самородки могут изменить направление, фокус и успех вашего продукта.

Совет: гуру Scrum-Agile Майк Кон однажды сказал: «Не переусердствуйте и не стремитесь собрать 50 различных точек данных для своей команды. Собери один. Используй это. Тогда выбери другой. Другими словами, сначала определите, какие области команда должна улучшить, а затем подумайте, какие ключевые показатели эффективности могли бы выделить эти области.

Гибкие показатели производительности, на которые можно положиться

1. Фактические завершенные истории против совершенных историй

Что: метрика, показывающая способность команды понимать и прогнозировать свои возможности.
Как: сравните количество историй, выделенных при планировании спринта, с историями, отмеченными как завершенные в обзоре спринта.

В Semrush модель программного приложения «Сборка на заказ» обычно подразумевает команды, использующие Канбан в качестве основного метода. Таким образом, ключевой показатель, который мы здесь измеряем, — это количество задач, выполненных за определенный период времени.

И мы обнаружили, что это гораздо более эффективно, чем любые другие показатели разработки программного обеспечения. Например, разработчик говорит: «Я буду называть эту мелодию в течение 5 дней». Если нет, мы пытаемся выяснить, почему они потерпели неудачу, и какие шаги мы должны предпринять, чтобы избежать этого в будущем. На самом деле, самое главное для нас – сделать оценку задачи заказчику максимально достоверной.

Польза для команды
В Semrush ключевым показателем является фактическое и обязательное, и, безусловно, каждая компания, занимающаяся разработкой программного обеспечения, должна учитывать его. Сбор и анализ данных может помочь вам понять, что пошло не так и кто виноват: произошло ли это из-за того, что инженеру, назначенному на задачу, не хватило опыта, задачи были поставлены неправильно, или причина была в чем-то другом.

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

Быть строгим в оценке проекта очень полезно. Мы стремимся к соотношению выделенного и потраченного времени один к одному — никаких оправданий, никаких козлов отпущения. А этого можно добиться только путем корректировки процессов управления проектами — расхождение в оценках часто является признаком плохого управления в компании в целом, а не проблемой конкретного члена команды.

Ценность для клиента
Проще говоря, главная выгода, которую получает клиент, — это доверие. Наши клиенты, как правило, заботятся о предсказуемости. Они хотят положиться на команду и ожидают, что дата, указанная разработчиком, будет обоснованной и точной. И нет ничего странного в том, чтобы требовать от партнера, чтобы он умел давать и выполнять обещания, постоянно поставляя работающее, протестированное и исправленное программное обеспечение в конце каждого спринта. Без стабильных предсказуемых команд невозможно иметь стабильные предсказуемые продукты.

Чтобы гарантировать удовлетворенность клиентов, мы предпочитаем, чтобы количество поставленных историй было больше, чем обещано, а не наоборот. Тем самым мы решаем вопрос с производительностью, а клиенты получают даже больше, чем ожидали.

2. Отклонение от оценки

Что: разрыв между оценкой проекта и фактически затраченным временем.
Как: сравните время, выделенное на задачу, с затраченным временем.

В «Свитле» качество и своевременная доставка определяют успех проекта. А измерение отклонения от оценки и его уменьшение помогает нам постоянно добиваться наилучших результатов. Здесь одна из ключевых задач менеджера проекта — свести отклонение к минимуму.

Как этого добиться? Дайте разработчикам возможность нести ответственность за свои собственные оценки. Тот, кто оценивает, и тот, кто работает над задачей, должен быть одним и тем же человеком. Так просто, как, что.

Некоторые думают, что в Agile нормально провалить какую-то итерацию ради обучения. Но мы по умолчанию считаем, что наши команды уже «хорошо обучены», по крайней мере, с типовыми — их надо правильно переоценивать. Скажем, если задача занимает неделю, она не может занять 2 недели — неделю и день в крайнем случае.

Компания «Свитла Системс» уже много лет работает поставщиком услуг по разработке ИТ-аутсорсинга и из первых рук узнала о страхах и мифах различных клиентов, и игнорирование сроков, безусловно, находится на первом месте в списке. Таким образом, процветают те компании, которые предоставляют именно то, что и когда клиенты ожидают от них.

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

Ценность для клиента
В Semrush есть несколько проектов, использующих идеальные процессы Scrum, где заказчики выделили Project Owners и готовы купить все недостатки Scrum (например, то, что не все итерации будут завершены). Но лучше всего это работает только тогда, когда клиент готов к Agile-процессам. Компания Waterfall ожидает поэтапной доставки. Так что при сотрудничестве с такими нужно быть очень осторожным в своих оценках. В противном случае легко столкнуться с неудовлетворенностью клиента в конце.

3. Удовлетворенность клиентов

Что: метрика, показывающая, соответствует ли команда ожиданиям клиента.
Как: использовать систему обратной связи.

Если кто-то хочет поставлять качественный продукт, на что следует обращать внимание? Есть много примеров показателей разработки программного обеспечения, которые следует учитывать: доля рынка, рентабельность инвестиций, процент дефектов. Но они мало что говорят — в конце концов, главное — это удовлетворенность клиентов.

Ценность для команды + клиента
Есть два типа негативных отзывов, которые вы можете получить от заинтересованных сторон: прямые и косвенные. Когда клиент жалуется: «Майк-разработчик плохой, он не делает то, что я хочу», — это прямая обратная связь. Может случиться так, что вы услышите «крик о помощи»: что-то идет не так, но никто не знает, что именно — это косвенное. И его ценность заключается в том, что он помогает менеджеру проекта находить пробелы и заполнять их на ходу.

Agile-метрики, которые вряд ли сработают

Завершенные пользовательские истории (на одного разработчика)
Это показатель, которым можно легко манипулировать. Проблема в том, что пользовательские истории, завершенные в бэклоге, не одинаково сложны. А что потом? Некоторые разработчики берут более простые. При распределении этот факт разделяет, а не объединяет. Все, что попало в итерацию, нужно сделать вовремя — это главное правило.

Что еще хуже, вы не можете сравнивать показатели между командами, поскольку все они оценивают по-разному.

Строки кода или потраченные часы
На самом деле это эквивалент Story Points Completed. Метрика совершенно бесполезна, так как не дает никакого контекста для интерпретации или сравнения.

Бенчмаркинг
Когда дело доходит до командной работы в разработке программного обеспечения, процессы варьируются от команды к команде, от проекта к проекту, от клиента к клиенту. Поэтому часто бывает проблематично (и некорректно) сравнивать команды.

Стремление к прогрессу, а не к контролю
Менеджмент – это своего рода мастерство. Команды разработчиков программного обеспечения должны иметь право самостоятельно принимать решения, придерживаясь требований. Таким образом, необходимо иметь набор всеобъемлющих метрик и индикаторов в программной инженерии. Главное — анализировать метрические данные, чтобы добиться дальнейшего прогресса. Это не обязательно приведет вас к окончательному успеху, тем не менее, вы будете знать, когда начинать обсуждение, разрабатывать план действий, проводить оценку и делиться отзывами.