Еще один об измерении производительности разработчика

Question

Я знаю, что вопрос об измерении производительности разработчика был задан до смерти, но, пожалуйста, потерпите меня. Я знаю давние споры о том, как вы не можете измерить производительность разработчиков, но реальность такова, что в нашей компании есть «необходимость» делать это так или иначе.

Я работаю в относительно небольшой компании (небольшой с точки зрения разработчиков), и руководство чувствовало необходимость измерять производительность разработчика на основе «функциональности, которая проходит тестирование (QA) на первой итерации».

Нам каким-то образом удалось убедить их в том, что это плохая идея по разным причинам, и вместо этого мы решили измерить разработчиков, поместив код в тест, где проходят все модульные тесты. Поскольку в нашей команде по сути не было «требования» по разработке модульных тестов раньше, мы чувствовали, что это была возможность формализовать необходимость разработки модульных тестов - то есть, у разработчиков был стимул для написания модульных тестов.

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

1. Функциональность, которая не работает, несмотря на прохождение модульного теста?
2. Не пишется модульный тест для заданной функциональности вообще или не написаны адекватные модульные тесты?
3. Качество написанного модульного теста?
4. Количество написанных модульных тестов?

Любые предложения будут высоко оценены. Или я полностью не в курсе этого вида измерения производительности?

Answer 1

Может быть, я совершенно не в курсе этого вида измерения производительности?

Вопрос не в том, «что мы измеряем?»

Вопрос: «Что сломано?»

Далее следует «как мы измеряем поломку?»

Затем следует «как мы можем измерить улучшение?»

Пока у вас нет чего-то, что вы пытаетесь исправить, вот что происходит.

1. Вы выбираете что-то для измерения.

2. Люди реагируют, делая то, что «выглядит» лучше всего в соответствии с этим показателем.

3. Вы понимаете, что измеряете не ту вещь.

В частности.

• "функциональные возможности, которые проходят тестирование (QA) на первой итерации" Что означает что? Сохраняйте код, пока он НЕ ДОЛЖЕН работать. Позже выглядит лучше. Итак, откладывайте, пока вы не пройдете QA на первой итерации.

• "Функциональность, которая не работает, хотя модульный тест проходит?" Похоже, это «неполные юнит-тесты». Таким образом, вы все переоцените. Потратьте много времени, чтобы написать все возможные тесты. Замедлите доставку, чтобы вы не были оштрафованы этим измерением.

• "Не пишется ли модульный тест для заданной функциональности вообще или не написаны адекватные модульные тесты?" Не знаю, как вы это измеряете, но звучит так же, как и предыдущий. ,

• "Качество написанного модульного теста?" Субъективное измерение. Всегда хороший план. Определите, как вы будете измерять качество, и вы получите материал, который максимизирует это конкретное измерение. Хотите больше комментариев? Считай это. Какие еще пробелы? Считай это.

• "Количество написанных модульных тестов?" Ничто не побуждает меня писать избыточные тесты, такие как подсчет количества тестов. Я могу легко скопировать и вставить практически идентичный код, если он хорошо выглядит в соответствии с этим показателем.

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

---

Редактировать

Я не говорю "Не мери". Я говорю "вы получаете то, что вы измеряете". Выберите показатель, который вы хотите максимизировать за счет других. Нетрудно выбрать метрику. Просто знайте последствия того, что говорите руководству, что измерять.

Answer 2

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

Answer 3

Я думаю, что у Джоэла было замечено , когда он сказал, что такие измерения будут разработаны вашими разработчиками. Он не достигнет того, к чему он стремился, и вы, скорее всего, в конечном итоге получите качественные страдания (от восприятия каждого, кто пользуется системой), в то время как ваши измерения качества все предполагают, что вещи никогда не были лучше!

редактировать . Вы говорите, что руководство требует этого. Вы небольшая компания; Ваше руководство не может позволить себе каждый , чтобы встать и уйти. Скажите им, что это мусор, и вы не будете в этом участвовать.

Если вся идея заключается в том, чтобы они могли ранжировать людей, чтобы сделать их лишними (кажется, что это может быть в настоящее время), просто спросите их, сколько человек должно пойти, а затем выберите тех разработчиков, которые вы считаете худшими , используя ваш интеллект и суждение , а не какое-то глупое эмпирическое правило

Answer 4

Цитировать Стива Йегге:

не должно ли быть правило, что компаниям не разрешается делать вещи, которые были формально высмеяны в комиксе Дилберта?

Answer 5

Почему-то на ум приходит черный рынок с дефектом ... хотя это несколько наоборот.

Любая система, основанная на показателях, когда дело доходит до разработчиков, просто не будет работать, потому что вы не можете измерить ее обычными методами. Все, что вы пытаетесь внедрить в отношении чего-либо подобного, будет игровым (потому что решение проблем - это то, чем мы занимаемся весь день, и это просто еще одна проблема, которую нужно решить), и это будет вредно для вашего кода (например, я написал простой корректор орфографии на днях с примерно 5 юнит-тестами, которых было достаточно, чтобы проверить его работоспособность, но если бы меня измерили на юнит-тестах, я мог бы потратить еще один день на написание еще 100, которые все прошли бы, но не добавили бы значения) *

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

Answer 6

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

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

В офисе не всегда ясно, что другой человек сделал лучшую работу. И поэтому многие люди будут демотивированы. Они протестировали с оплатой труда учителей и обнаружили, что это дало отрицательные результаты. Люди, которые получали более высокую зарплату, часто не понимали, почему они добились большего успеха, чем другие, а те, кто становился ниже, обычно не могли понять, почему они стали ниже.

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

Прочитайте iCon о том, как Стиву Джобсу удалось заставить людей выступать. По сути, он заставил людей поверить, что они были частью чего-то большого и собирались изменить мир. Это то, что заставляет людей прикладывать усилия и действовать. Я не думаю, что разработчики приложат много усилий ради денег. Это должно быть то, во что они действительно верят и / или думают, что это весело или приятно.

Answer 7

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

… Автоматические тесты сами по себе не повышают качество нашего кода, но требуют вывода кода

- от Измерение воздействия разработчика

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

Используя систему контроля версий, как git, мы можем разбить минимальную единицу ценной работы на коммиты / PR. Визуализация (как в приведенной выше цитате ) - это лучшая и более благородная цель, которую руководство должно воспринимать, а не наличие плоской лестницы или метрики для сравнения своих разработчиков.

Не пытайтесь измерить сырой выход. Попробуй понять работу разработчика, иди визуализируй ее.

Answer 8

Ищите у Деминга и Total Quality Management его мысли о том, почему оценки производительности вообще нельзя проводить для какой-либо работы.

Как насчет этого, предположим, что все сотрудники являются приемлемыми сотрудниками, если не доказано иное.

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

Если кто-то делает что-то хорошо, напиши им, что делаешь что-то хорошее. Если вы хотите предложить бонус, дайте его во время хорошей производительности. Еще лучше убедиться, что вы объявляете, когда люди получают нападавшего. Люди будут работать, чтобы получить их. Конечно, у вас будут типичные люди, которые попытаются сыграть в систему и написать на основе других достижений, но вы все равно получите это в любой системе. Объявляя, кто получил их во время хорошей работы, вы удалили секрет, который позволяет игрокам офисной политики функционировать лучше всего. Если все знают, что Джо сделал что-то великое, и вместо этого вы наградите Мэри, люди начнут об этом говорить. По крайней мере, Джо и Мэри могли бы получить нападавшего.

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

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

Answer 9

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

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

2) Часто ли проверяются граничные условия, например, нули для параметров или букв вместо цифр и других базовых проверочных тестов? Это также то, что можно легко определить количественно, посмотрев на параметры для различных методов, а также имея стандарты кодирования для предотвращения обхода здесь вещей, например, все методы объекта, кроме конструктора, принимают 0 параметров и поэтому не имеют граничных тестов.

3) Гранулярность юнит-теста. Проверяет ли тест для одного конкретного случая и не пытается ли сделать много разных случаев в одном тесте? Тестовые классы содержат тысячи строк кода?

4) Оценка кода и тестов с точки зрения удобочитаемости и удобства обслуживания. Должен ли кто-то новый потратить дни, чтобы выяснить, что происходит, или код самодокументируется? Примеры могут включать имена методов и имена классов, которые имеют смысл, и документацию, находящуюся там?

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

Answer 10

Бедный пепел ...

Благодарность за использование управленческого невежества, чтобы подтолкнуть что-то совершенно не связанное, но теперь вы должны придумать реальную меру.

Я не могу придумать какое-либо измерение производительности, которое не является нелепым или легко поддающимся измерению. Модульные тесты не могут изменить его. Поскольку копейки и черный рынок были связаны в течение нескольких минут, я бы предпочел дать вам боеприпасы, чтобы не требовать индивидуального измерения производительности:

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

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

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

Почему бы не сделать так, чтобы каждый разработчик "голосовал" за своих коллег: кто помог нам достичь наших целей больше всего за последний год? Почему бы не доверять вам (как, очевидно, их руководителю или руководителю) в оценке их эффективности?