Вопрос:

Качество кода

process development-environment

2644 просмотра

19 ответа

30384 Репутация автора

Я работаю в компании по разработке программного обеспечения, и у нас около 100 человек работают над продуктом, 1/3 из них - QA. В последнее время руководство хочет иметь лучший способ оценивать производительность отдельных программистов, поэтому было предложено использовать отчеты об ошибках в качестве измерения. Чем больше сообщений об ошибках у разработчика, тем он хуже. Это кажется неуместным по многим причинам, чем я могу сказать, например, это субъективный способ измерения, разработчики работают над различными проектами различной сложности. Кроме того, если QA измеряется по количеству генерируемых ими отчетов об ошибках, будет много дискуссий о достоверности отчетов об ошибках.

Что может быть лучшим способом измерения производительности разработчиков в таких условиях?

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

РЕДАКТИРОВАТЬ: # 1 После прочтения некоторых ваших превосходных ответов я подумал, что общая проблема с вышеописанной метрикой заключается в том, что это отрицательные сообщения об ошибках - это не поощряет к созданию кода хорошего качества.

РЕДАКТИРОВАТЬ: # 2 Я думаю, что проблема в том, что это два мира. С одной стороны, есть непрограммисты, которые в основном относятся к программистам как к работникам, и они хотят, чтобы метрики определялись в минуту. Тогда у нас есть Программисты, которые хотят видеть себя художниками или мастерами: «Пожалуйста, не беспокойте меня, я кодирую» :) Я не думаю, что измерение качества может быть выполнено с помощью метрик, не будучи контрпродуктивным. Вместо этого важны вещи, как человек реагирует на ошибки, готовность к изменениям, креативность и, прежде всего, качество работы, но не всегда поддающиеся измерению.

Автор: Anders Источник Размещён: 16.04.2009 02:35

Ответы (19)


23 плюса

11979 Репутация автора

Решение

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

Из одной из других статей Джоэла :

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

Автор: Chris Upchurch Размещён: 16.04.2009 02:42

33 плюса

676237 Репутация автора

альтернативный текст       

Автор: Greg Hewgill Размещён: 16.04.2009 02:43

3 плюса

110731 Репутация автора

Это ужасный показатель по причинам, которые вы упомянули.

Кроме того, «внешние» сообщения об ошибках также являются несправедливым и ненадежным способом судить разработчиков - что, если некоторые разработчики работают над областью кода, которая используется чаще других? Если моя функция используется моими 80% пользователей, а ваша - 1%, кто, по вашему мнению, увидит больше отчетов об ошибках?

Любая метрика, которая может быть легко отыграна - или которая дает другим людям стимулы для игры на них - также ужасна.

Автор: matt b Размещён: 16.04.2009 02:43

1 плюс

6326 Репутация автора

Единственный реальный способ проверки качества - это проверить работу ... и измерить то, что проверено, и количество переделок. По факту ошибки - это способы измерения этого показателя - и только одна метрика, но обзоры в процессе разработки лучше. Посмотрите на некоторые метрики, которые использует TopCoder .

Автор: Peter K. Размещён: 16.04.2009 02:43

1 плюс

50220 Репутация автора

Отчеты об ошибках не только наводят на мысль, но и не очень сопоставимы. Насколько «большой» баг? Одна большая ошибка может быть хуже, чем 5 маленьких ... с другой стороны, это может быть не так. Таким образом, вам нужно будет вдаваться в специфику каждой отдельной ошибки (что будет кошмаром).

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

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

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

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

Автор: TofuBeer Размещён: 16.04.2009 02:44

5 плюса

3807 Репутация автора

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

Позвольте привести пример: вы разрабатываете и тестируете приложение на 32-битной Windows Vista, а затем оно терпит неудачу на сайте-клиенте, где они работают под управлением 64-битной Windows XP. Было ли это ошибкой программистов (особенно если вы никогда не давали ему машину под управлением XP 64 bit для тестирования)?

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

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

Автор: JonnyBoats Размещён: 16.04.2009 02:47

1 плюс

10808 Репутация автора

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

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

Автор: Dan Breslau Размещён: 16.04.2009 02:47

1 плюс

12696 Репутация автора

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

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

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

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

Но ваша обязанность - подгруппировать категории ошибок и назначить им необходимые веса. Я думаю, вы не можете сделать это сразу. Это «Определение» также должно со временем стать более зрелым с поправками. :)

Автор: Chathuranga Chandrasekara Размещён: 16.04.2009 02:50

2 плюса

440 Репутация автора

Хорошо сказано Крисом.

У нас была похожая проблема в нашем офисе. Генеральный директор и другие крупные парики не знали, как измерить качество разработки, и они реализовали свои собственные смешные измерения. Суммарное количество ошибок разработчиков определенно не является измерением, которое нужно пройти. Я не знаю, есть ли идеальный ответ, но я надеюсь, что моя работа измеряется тем, соблюдаю ли я свои сроки и обратную связь с потребителем (довольны ли они продуктом).

Автор: dkpatt Размещён: 16.04.2009 02:51

1 плюс

11976 Репутация автора

Эта метрика воняет и будет поощрять действительно плохие практики и распри о том, кто вызвал какую ошибку. Любая метрика ошибки должна быть уравновешена успешным измерением метрики. Люди, которые пишут больше кода, по определению будут иметь больше возможностей для ошибок. В зависимости от доступных данных вы можете нормализовать свою рейтинговую систему. Если бы один разработчик реализовал одну функцию без дефектов, я бы не оценил его лучше, чем разработчик, который реализовал 243 функции с 3 дефектами. Разработчики рейтинга требуют от руководства отложить цифры и наблюдать за каждым членом команды. Активно вовлеченный менеджер поймет, у каких разработчиков есть недостатки, и будет работать с ними, чтобы улучшить их производительность. Это на самом деле требует работы менеджеров, чтобы помочь каждому человеку установить и достичь целей.

Автор: ojblass Размещён: 16.04.2009 02:51

22 плюса

8724 Репутация автора

альтернативный текст

Автор: zalew Размещён: 16.04.2009 02:53

3 плюса

550 Репутация автора

Сообщения об ошибках от разработчика - ужасная метрика. Как лидер QA я снова и снова выступал против этого. Ошибки будут . То, как с ними поступают, когда они делают, является более значимым.

Лучшим показателем является показатель повторного открытия ошибок разработчика. Другими словами, когда QA регистрирует ошибку, которая затем исправляется, исправлена ​​ли ошибка правильно, или что-то было пропущено, что заставило QA повторно открыть ошибку?

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

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

  • Соответствует ли разработчик обещанным срокам?
  • Отзывчивость к проблемам клиента.
  • Точность любой необходимой документации.

и, вероятно, другие.

Редактировать: я занимался как разработкой, так и тестированием, и мне повезло, что во время разработки я не использовал подсчеты ошибок в своих обзорах. Я выступаю против этого в моей нынешней компании в моей нынешней роли, потому что это ненадежный показатель ИМО. Мы использовали показатель «открыть заново» как компромисс, чтобы высшее руководство (читай «заостренный» директор отдела разработки) было довольно тем, что у них есть что сообщить. Я не менеджер и на самом деле не создаю никаких отчетов самостоятельно (в случае, если это является причиной некоторых отрицательных голосов).

Автор: ssakl Размещён: 16.04.2009 02:56

11 плюса

429025 Репутация автора

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

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

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

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

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

Автор: tvanfosson Размещён: 16.04.2009 02:56

1 плюс

10634 Репутация автора

У меня есть три вещи, чтобы сказать об этом:

1) менеджер, который полагает, что «большее количество ошибок == худший разработчик» или «... == лучший тестер» может быть более серьезной проблемой для вашей компании, чем любой отдельный разработчик. Как этот человек стал частью дискуссии об оценке производительности разработчика? Если они управляют разработчиками, они должны знать лучше.

2) Самый простой способ для разработчика воспроизвести любую метрику, связанную с ошибками (счетчик ошибок, частоту повторных открытий, нормализованный или не для каждой функции / LOC / что угодно), состоит в том, чтобы сделать их реализацию настолько сложной, насколько это возможно, для тестирования. Невозможно протестировать означает, что QA обнаруживает ноль ошибок. Также, вероятно, невозможно использовать, что означает ноль сообщений об ошибках с поля (ну, может быть, один). Любой показатель количества ошибок является стимулом против тестируемости. Спросите руководство, действительно ли это то, что они хотят.

3) Если они действительно реализуют эту политику, бегите как в аду.

Автор: Zac Thompson Размещён: 16.04.2009 04:50

0 плюса

5341 Репутация автора

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

-Программист производительности ты не слушаешь ?? Дух

-Да конечно .. но почему это важно?

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

  • Тогда спросите себя, если кто-то оптимизирует метрику, на чем он будет концентрироваться?

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

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

  • Спросите себя, какую среду вы хотите создать? Как отреагирует команда, менеджеры, директора на публикацию метрики?

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

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

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

Автор: Newtopian Размещён: 16.04.2009 05:19

2 плюса

2487 Репутация автора

Мы профессионалы, как и многие люди. Мы также считаем, что мы художники, и, по моему мнению, мы. К сожалению (большинство) программисты художники с покровителем.

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

Если мы сами не придумаем что-то, что делает менеджмент счастливым, они будут делать то же самое, что и меценаты. «Мне не нравится, ты уволен».

Мир> Компания> Продукт> Разработчик

Что касается конкретной метрики, я потерян так же, как и все остальные. Лучшее, что я увидел, - это вновь открытая метрика ошибок.

Автор: Darren Clark Размещён: 16.04.2009 05:20

1 плюс

91 Репутация автора

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

Это правда. И у вас будут те же проблемы с любым другим применяемым вами показателем. Ключевой вопрос заключается в том, что качество - это не то, что мы знаем, как измерить численно. Кроме того, вам не следует беспокоиться о качестве кода, прежде всего, если вы делаете свою работу правильно. Ваш настоящий вопрос должен звучать так: «Как этот человек помогает нам зарабатывать деньги?»

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

Автор: James Aguilar Размещён: 16.04.2009 05:34

1 плюс

2160 Репутация автора

Ошибки, найденные QA = хорошо. Найденные клиентами ошибки = плохие.

Если вам нужно измерить разработчиков, используйте #bugs found ПОСЛЕ тестирования, т.е. в коде Production / Release / 'on the disc'.

Тот же показатель для QA ... «одна команда - одна мечта».

Майкл

Автор: Michael Dausmann Размещён: 24.04.2009 04:16

0 плюса

149 Репутация автора

Эта идея просто заставляет меня хотеть / facepalm.

Ну, 10 лет назад у меня был начальник, который предложил мне заплатить за SLOC.

Я ухожу в тот же день.

Автор: stormianrootsolver Размещён: 10.06.2010 03:37
Вопросы из категории :
32x32