День 2201. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍17
День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍8
День 2203. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
👍6
День 2366. #ProjectManagement
Измеряем Продуктивность Разработчиков. Начало
В мире разработки ПО измерение продуктивности остаётся одним из самых сложных, но в то же время критически важных аспектов управления командами разработчиков. В то время как другие бизнес-функции часто можно оценить с помощью простых метрик, разработка ПО представляет собой уникальную задачу из-за своей командной, сложной и творческой природы.
Организации в любой отрасли всё больше зависят от ПО, поэтому руководителям нужны надёжные способы оценки эффективности работы их команд разработчиков. Но остаётся вопрос: какие метрики действительно важны, а какие могут принести больше вреда, чем пользы?
Проблема измерения продуктивности
Измерение производительности труда разработчиков - сложная задача по нескольким причинам:
- Разработка ПО предполагает творческое решение задач, которое сложно выразить количественными показателями;
- Связь между входными и выходными данными значительно менее очевидна, чем в других бизнес-функциях;
- Разработка в значительной степени предполагает совместную работу, что затрудняет оценку индивидуального вклада;
- Различные уровни работы (системы, команды, отдельные лица) требуют разных подходов к измерению.
Как заметил один из руководителей инженерных отделов Microsoft: «Многие специалисты в сфере технологий давно убеждены, что невозможно правильно измерить производительность труда разработчиков и что только квалифицированные инженеры обладают достаточными знаниями, чтобы оценить работу своих коллег».
Однако по мере роста команд разработки и увеличения инвестиций организаций в инженерных специалистов подход «мы не можем это измерить» становится всё более несостоятельным.
Метрики, которые не работают (и почему)
Прежде чем углубляться в практические подходы к измерению, давайте рассмотрим некоторые распространённые, но проблемные метрики.
1. Строки кода (KLOC)
Хотя их легко измерить, строки кода — самый известный пример метрики тщеславия. Больше кода не обязательно означает лучше, и эта метрика может активно поощрять неэффективные практики:
- Поощряет многословный, неэффективный код;
- Игнорирует качество и поддерживаемость кода;
- Сильно варьируется в зависимости от языка программирования;
- Легко поддаётся манипуляциям.
2. Количество коммитов
Как и количество строк кода, измерение чистого количества коммитов мало что даёт знать о фактической производительности:
- Разработчики могут чаще вносить незначительные изменения, чтобы «обмануть» систему;
- Не отражает качество или ценность изменений;
- Игнорирует разницу в сложности между коммитами.
3. Отработанные часы
Время, затраченное на кодирование, не обязательно коррелирует с полученной ценностью:
- Поощряет презентеизм (видимость присутствия на работе), а не эффективность;
- Игнорирует качество выполненной работы;
- Может привести к выгоранию и снижению долгосрочной производительности.
Продолжение следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Начало
В мире разработки ПО измерение продуктивности остаётся одним из самых сложных, но в то же время критически важных аспектов управления командами разработчиков. В то время как другие бизнес-функции часто можно оценить с помощью простых метрик, разработка ПО представляет собой уникальную задачу из-за своей командной, сложной и творческой природы.
Организации в любой отрасли всё больше зависят от ПО, поэтому руководителям нужны надёжные способы оценки эффективности работы их команд разработчиков. Но остаётся вопрос: какие метрики действительно важны, а какие могут принести больше вреда, чем пользы?
Проблема измерения продуктивности
Измерение производительности труда разработчиков - сложная задача по нескольким причинам:
- Разработка ПО предполагает творческое решение задач, которое сложно выразить количественными показателями;
- Связь между входными и выходными данными значительно менее очевидна, чем в других бизнес-функциях;
- Разработка в значительной степени предполагает совместную работу, что затрудняет оценку индивидуального вклада;
- Различные уровни работы (системы, команды, отдельные лица) требуют разных подходов к измерению.
Как заметил один из руководителей инженерных отделов Microsoft: «Многие специалисты в сфере технологий давно убеждены, что невозможно правильно измерить производительность труда разработчиков и что только квалифицированные инженеры обладают достаточными знаниями, чтобы оценить работу своих коллег».
Однако по мере роста команд разработки и увеличения инвестиций организаций в инженерных специалистов подход «мы не можем это измерить» становится всё более несостоятельным.
Метрики, которые не работают (и почему)
Прежде чем углубляться в практические подходы к измерению, давайте рассмотрим некоторые распространённые, но проблемные метрики.
1. Строки кода (KLOC)
Хотя их легко измерить, строки кода — самый известный пример метрики тщеславия. Больше кода не обязательно означает лучше, и эта метрика может активно поощрять неэффективные практики:
- Поощряет многословный, неэффективный код;
- Игнорирует качество и поддерживаемость кода;
- Сильно варьируется в зависимости от языка программирования;
- Легко поддаётся манипуляциям.
2. Количество коммитов
Как и количество строк кода, измерение чистого количества коммитов мало что даёт знать о фактической производительности:
- Разработчики могут чаще вносить незначительные изменения, чтобы «обмануть» систему;
- Не отражает качество или ценность изменений;
- Игнорирует разницу в сложности между коммитами.
3. Отработанные часы
Время, затраченное на кодирование, не обязательно коррелирует с полученной ценностью:
- Поощряет презентеизм (видимость присутствия на работе), а не эффективность;
- Игнорирует качество выполненной работы;
- Может привести к выгоранию и снижению долгосрочной производительности.
Продолжение следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👍8
День 2367. #ProjectManagement
Измеряем Продуктивность Разработчиков. Продолжение
Начало
Метрики, которые действительно имеют значение
Эффективное измерение производительности требует более тонкого подхода, учитывающего как количественные, так и качественные факторы. Вот метрики, которые дают ценную информацию.
1. Метрики DORA
Метрики DevOps Research and Assessment (DORA) стали отраслевым стандартом для измерения эффективности поставки ПО:
1) Частота развёртывания (DF): как часто код успешно развёртывается в рабочей среде
- Элитные команды: несколько в день,
- Высокопроизводительные команды: от 1 в день до 1 в неделю,
2) Время внесения изменений (LTFC): от коммита до запуска в рабочей среде
- Элитные команды: менее 1 дня
- Высокопроизводительные команды: менее 1 недели
3) Процент ошибок в изменениях (CFR): процент изменений, приводящих к снижению качества обслуживания
- Элитные команды: 0–15%
- Высокопроизводительные команды: 16–30%
4) Среднее время восстановления (MTTR): время, необходимое для восстановления обслуживания после инцидента
- Элитные команды: менее часа
- Высокопроизводительные команды: менее дня
Эти метрики дают сбалансированное представление о скорости и стабильности, помогая командам оценить своё положение по сравнению с отраслевыми эталонами.
2. Фреймворк SPACE
Фреймворк SPACE предлагает более комплексный подход к измерению производительности:
- Удовлетворенность разработчиков: мотивация и баланс между работой и личной жизнью.
- Производительность: ощутимые результаты и эффективность, включая качество кода и скорость устранения ошибок.
- Действия: виды и уровни ежедневной работы по разработке, включая кодирование, отладку и совместную работу.
- Коммуникация и сотрудничество: насколько эффективно разработчики обмениваются информацией и работают вместе.
- Эффективность: насколько эффективно разработчики используют время и ресурсы для достижения целевой производительности.
SPACE признаёт, что продуктивность разработчиков включает в себя не только результаты, но и опыт, динамику работы команды и устойчивые методы работы.
Метрики процесса
Несколько метрик процесса могут дать ценную информацию:
1) Время цикла
Время для переноса кода пул-реквеста в эксплуатацию. Измеряет весь процесс PR — часто самый сложный этап разработки ПО.
2) Размер PR и время проверки
Небольшие PR (<200 строк) тесно связаны с более быстрым временем проверки и более быстрой интеграцией, т.к. обычно проверяются быстрее и тщательнее. Время проверки показывает, насколько быстро предоставляется и учитывается обратная связь.
3) Изменение и доработка кода
Объём кода, переписанного вскоре после написания, может указывать на нечёткие требования или проблемы процесса. Высокое изменение кода (>30%) может сигнализировать о проблемах с требованиями или дизайном. Отслеживание тенденций с течением времени важнее абсолютных цифр.
Внедрение эффективных измерений
Для эффективного измерения производительности требуется не просто выбор правильных метрик, а продуманный подход к их внедрению.
1. Сосредоточьтесь на командных, а не на индивидуальных метриках
Измерение производительности лучше работает на уровне команды, а не отдельного человека, т.к. разработка ПО - совместный процесс. Индивидуальные метрики часто создают нездоровую конкуренцию. Метрики на уровне команды поощряют сотрудничество и совместное владение.
2. Сочетайте опережающие и запаздывающие показатели
- Опережающие (например, размер PR или время проверки) помогают прогнозировать будущие результаты.
- Запаздывающие (частота развёртываний или процент ошибок в изменениях) подтверждают прошлые результаты.
3. Используйте данные для улучшения, а не для наказания
Основной целью должно быть постоянное совершенствование. Используйте данные для выявления узких мест. Сосредоточьте обсуждение на системных улучшениях, а не на индивидуальных показателях эффективности. Отмечайте улучшения и извлекайте уроки из неудач.
Окончание следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Продолжение
Начало
Метрики, которые действительно имеют значение
Эффективное измерение производительности требует более тонкого подхода, учитывающего как количественные, так и качественные факторы. Вот метрики, которые дают ценную информацию.
1. Метрики DORA
Метрики DevOps Research and Assessment (DORA) стали отраслевым стандартом для измерения эффективности поставки ПО:
1) Частота развёртывания (DF): как часто код успешно развёртывается в рабочей среде
- Элитные команды: несколько в день,
- Высокопроизводительные команды: от 1 в день до 1 в неделю,
2) Время внесения изменений (LTFC): от коммита до запуска в рабочей среде
- Элитные команды: менее 1 дня
- Высокопроизводительные команды: менее 1 недели
3) Процент ошибок в изменениях (CFR): процент изменений, приводящих к снижению качества обслуживания
- Элитные команды: 0–15%
- Высокопроизводительные команды: 16–30%
4) Среднее время восстановления (MTTR): время, необходимое для восстановления обслуживания после инцидента
- Элитные команды: менее часа
- Высокопроизводительные команды: менее дня
Эти метрики дают сбалансированное представление о скорости и стабильности, помогая командам оценить своё положение по сравнению с отраслевыми эталонами.
2. Фреймворк SPACE
Фреймворк SPACE предлагает более комплексный подход к измерению производительности:
- Удовлетворенность разработчиков: мотивация и баланс между работой и личной жизнью.
- Производительность: ощутимые результаты и эффективность, включая качество кода и скорость устранения ошибок.
- Действия: виды и уровни ежедневной работы по разработке, включая кодирование, отладку и совместную работу.
- Коммуникация и сотрудничество: насколько эффективно разработчики обмениваются информацией и работают вместе.
- Эффективность: насколько эффективно разработчики используют время и ресурсы для достижения целевой производительности.
SPACE признаёт, что продуктивность разработчиков включает в себя не только результаты, но и опыт, динамику работы команды и устойчивые методы работы.
Метрики процесса
Несколько метрик процесса могут дать ценную информацию:
1) Время цикла
Время для переноса кода пул-реквеста в эксплуатацию. Измеряет весь процесс PR — часто самый сложный этап разработки ПО.
2) Размер PR и время проверки
Небольшие PR (<200 строк) тесно связаны с более быстрым временем проверки и более быстрой интеграцией, т.к. обычно проверяются быстрее и тщательнее. Время проверки показывает, насколько быстро предоставляется и учитывается обратная связь.
3) Изменение и доработка кода
Объём кода, переписанного вскоре после написания, может указывать на нечёткие требования или проблемы процесса. Высокое изменение кода (>30%) может сигнализировать о проблемах с требованиями или дизайном. Отслеживание тенденций с течением времени важнее абсолютных цифр.
Внедрение эффективных измерений
Для эффективного измерения производительности требуется не просто выбор правильных метрик, а продуманный подход к их внедрению.
1. Сосредоточьтесь на командных, а не на индивидуальных метриках
Измерение производительности лучше работает на уровне команды, а не отдельного человека, т.к. разработка ПО - совместный процесс. Индивидуальные метрики часто создают нездоровую конкуренцию. Метрики на уровне команды поощряют сотрудничество и совместное владение.
2. Сочетайте опережающие и запаздывающие показатели
- Опережающие (например, размер PR или время проверки) помогают прогнозировать будущие результаты.
- Запаздывающие (частота развёртываний или процент ошибок в изменениях) подтверждают прошлые результаты.
3. Используйте данные для улучшения, а не для наказания
Основной целью должно быть постоянное совершенствование. Используйте данные для выявления узких мест. Сосредоточьте обсуждение на системных улучшениях, а не на индивидуальных показателях эффективности. Отмечайте улучшения и извлекайте уроки из неудач.
Окончание следует…
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👎6
День 2368. #ProjectManagement
Измеряем Продуктивность Разработчиков. Окончание
Начало
Продолжение
Рекомендации по повышению продуктивности
Несколько практик, которые могут значительно повысить продуктивность разработчиков:
1. Снижение когнитивной нагрузки
Минимизация ненужной умственной нагрузки помогает сосредоточиться на самом важном:
- Ограничьте количество встреч, чтобы обеспечить непрерывное время для концентрации;
- По возможности поощряйте асинхронное общение;
- Создайте понятную документацию, чтобы снизить умственные затраты на переключение контекста.
2. Внедрите руководства
Структурированные рекомендации помогают снизить усталость от принятия решений:
- Создайте стандартизированные процедуры для повседневных задач;
- Разработайте стандарты и шаблоны кодирования;
- Документируйте рекомендации для обеспечения согласованности.
3. Автоматизируйте повторяющиеся задачи
Автоматизация позволяет разработчикам сосредоточиться на творческом решении проблем:
- Автоматизируйте процессы сборки, тестирования и развёртывания;
- Используйте инструменты, оптимизирующие проверку кода и управление PR;
- Внедряйте конвейеры CI/CD для снижения ручного труда.
4. Сопоставляйте сильные стороны разработчиков с проектами
Согласование работы с экспертными знаниями повышает как производительность, так и удовлетворённость:
- Создайте профили навыков для понимания потребностей разработчиков;
- Назначайте задачи на основе знаний и интересов;
- Предоставляйте возможности для роста в областях, представляющих интерес.
Реальные примеры повышения производительности
Модель «Squad» от Spotify
Spotify организовал команды в небольшие кросс-функциональные «отряды», каждый из которых отвечает за определённые функции или сервисы на всех этапах. Такой подход снизил зависимость между командами и сократил время цикла на 35%.
Опрос удовлетворённости разработчиков от Google
Google регулярно опрашивает разработчиков об их производительности и удовлетворённости. Обнаружив, что время сборки является основной проблемой, компания инвестировала в усовершенствования системы сборки, что позволило сэкономить примерно 3–5 часов на разработчика в неделю.
Индекс скорости разработки от Microsoft
В Microsoft разработали комплексную систему для измерения продуктивности разработчиков, учитывающую технические, процессные и культурные факторы. Компании, находящиеся в верхнем квартиле этого индекса, быстрее внедряют инновации и демонстрируют в 4–5 раз более высокую эффективность бизнеса.
Итого
Для эффективного измерения продуктивности разработчиков необходимо выйти за рамки простых показателей, таких как количество строк кода или отработанных часов. Вместо этого сосредоточьтесь на сбалансированных фреймворках, таких как DORA и SPACE, которые учитывают как количественные, так и качественные аспекты разработки.
Помните, что целью измерения должно быть постоянное совершенствование, а не наказание или нездоровая конкуренция. Используйте метрики для выявления узких мест на системном уровне и возможностей для улучшения, а не для оценки индивидуальной работы в отрыве от других.
Наиболее продуктивные команды разработки сочетают продуманное измерение с практиками, которые снижают трения и облегчают работу. Сосредоточившись на том, что действительно важно — эффективном создании ценности при сохранении удовлетворённости разработчиков, — организации могут создать устойчивую, высокопроизводительную инженерную культуру.
Совершенствуя свой подход к измерению и повышению продуктивности разработчиков, помните, что важнейшей метрикой является ценность, предоставляемая пользователям. Когда разработчики могут эффективно работать над значимыми задачами, производительность и удовлетворённость естественным образом растут.
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
Измеряем Продуктивность Разработчиков. Окончание
Начало
Продолжение
Рекомендации по повышению продуктивности
Несколько практик, которые могут значительно повысить продуктивность разработчиков:
1. Снижение когнитивной нагрузки
Минимизация ненужной умственной нагрузки помогает сосредоточиться на самом важном:
- Ограничьте количество встреч, чтобы обеспечить непрерывное время для концентрации;
- По возможности поощряйте асинхронное общение;
- Создайте понятную документацию, чтобы снизить умственные затраты на переключение контекста.
2. Внедрите руководства
Структурированные рекомендации помогают снизить усталость от принятия решений:
- Создайте стандартизированные процедуры для повседневных задач;
- Разработайте стандарты и шаблоны кодирования;
- Документируйте рекомендации для обеспечения согласованности.
3. Автоматизируйте повторяющиеся задачи
Автоматизация позволяет разработчикам сосредоточиться на творческом решении проблем:
- Автоматизируйте процессы сборки, тестирования и развёртывания;
- Используйте инструменты, оптимизирующие проверку кода и управление PR;
- Внедряйте конвейеры CI/CD для снижения ручного труда.
4. Сопоставляйте сильные стороны разработчиков с проектами
Согласование работы с экспертными знаниями повышает как производительность, так и удовлетворённость:
- Создайте профили навыков для понимания потребностей разработчиков;
- Назначайте задачи на основе знаний и интересов;
- Предоставляйте возможности для роста в областях, представляющих интерес.
Реальные примеры повышения производительности
Модель «Squad» от Spotify
Spotify организовал команды в небольшие кросс-функциональные «отряды», каждый из которых отвечает за определённые функции или сервисы на всех этапах. Такой подход снизил зависимость между командами и сократил время цикла на 35%.
Опрос удовлетворённости разработчиков от Google
Google регулярно опрашивает разработчиков об их производительности и удовлетворённости. Обнаружив, что время сборки является основной проблемой, компания инвестировала в усовершенствования системы сборки, что позволило сэкономить примерно 3–5 часов на разработчика в неделю.
Индекс скорости разработки от Microsoft
В Microsoft разработали комплексную систему для измерения продуктивности разработчиков, учитывающую технические, процессные и культурные факторы. Компании, находящиеся в верхнем квартиле этого индекса, быстрее внедряют инновации и демонстрируют в 4–5 раз более высокую эффективность бизнеса.
Итого
Для эффективного измерения продуктивности разработчиков необходимо выйти за рамки простых показателей, таких как количество строк кода или отработанных часов. Вместо этого сосредоточьтесь на сбалансированных фреймворках, таких как DORA и SPACE, которые учитывают как количественные, так и качественные аспекты разработки.
Помните, что целью измерения должно быть постоянное совершенствование, а не наказание или нездоровая конкуренция. Используйте метрики для выявления узких мест на системном уровне и возможностей для улучшения, а не для оценки индивидуальной работы в отрыве от других.
Наиболее продуктивные команды разработки сочетают продуманное измерение с практиками, которые снижают трения и облегчают работу. Сосредоточившись на том, что действительно важно — эффективном создании ценности при сохранении удовлетворённости разработчиков, — организации могут создать устойчивую, высокопроизводительную инженерную культуру.
Совершенствуя свой подход к измерению и повышению продуктивности разработчиков, помните, что важнейшей метрикой является ценность, предоставляемая пользователям. Когда разработчики могут эффективно работать над значимыми задачами, производительность и удовлетворённость естественным образом растут.
Источник: https://dev.to/teamcamp/measuring-developer-productivity-metrics-that-matter-and-those-that-dont-58n4
👍1