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

Ответ 1

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

Из одного из Joel других статей:

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

Ответ 2

alt text http://i18.tinypic.com/34461wi.jpg

Ответ 3

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

и, возможно, другие.

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

Ответ 8

Хорошо сказал Крис.

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

Ответ 9

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

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

Если мы сами не придумаем что-то, что сделает управление счастливым, тогда они сделают то же, что делают арт-покровители. "Мне это не нравится, вас увольняют".

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

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

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

Ответ 16

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

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

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

Ответ 17

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

Если вам нужно измерить разработчиков, используйте #bugs, найденные ПОСЛЕ тестирования, то есть в коде производства/выпуска/ "на диске".

Та же метрика для QA... "одна команда одна мечта".

Майкл

Ответ 18

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

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

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

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

• Спросите себя, если кто-то оптимизирует метрику, на чем они будут сосредоточены?

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

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

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

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

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

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

Ответ 19

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

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

Я покидаю тот же день.