Как измерить производительность разработки программного обеспечения? [закрытый]

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

допустим, мы используем сборку hudson для сбора статистики на выходе программиста. Что вы могли бы искать, и каковы были бы непреднамеренные побочные эффекты измерения, которые когда-то программисты это?

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

и так далее.

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

Итак, как вы должны смотреть на производительность ваших разработчиков? Что ж, это тяжело. И в нем участвуют человеческие менеджеры, которые хорошо понимают людей (и БС они тянут), и могут смотреть на каждого человека субъективно в контексте того, кто/где/что они должны выяснить, если они делают хорошую работу или нет.

то, что вы делаете, как только вы выяснили, кто / не выполняет, - это совсем другой вопрос.

(Я не могу взять на себя ответственность за эту линию мышления. Это от Джоэла Спольски. здесь и здесь)

нет.

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

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

Это трудно сделать правильно. Программное решение не получится.

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

1. комментарии к обзору кода-каждый проект, мы можем решить, сколько обзоров кода необходимо провести за данный период. На основе обзоров кода люди получают замечания об их стандартных улучшениях кодирования. Необходимо обратить внимание на повторяющиеся проблемы обзоров кода одного и того же человека. Вы можете использовать автоматические средства проверки кода или ручные проверки кода.
2. охват теста и завершенность тестов. – В % покрыты необходимо решить заранее, и если определенный разработчик не сможет часто пытаться это сделать, об этом нужно позаботиться.
3. готовность войти в сложные задачи и поставить их без особой борьбы
4. достижение того, что определено как "Сделано" в истории пользователя
5. уровень мастерства каждой технической области.

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

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

говоря о KPI в разработчиках программного обеспечения. www.smartKPIs.com может быть хорошим ресурсом для вас. Он содержит удобную для пользователя библиотеку хорошо документированных показателей производительности. На данный момент в нем перечислено более 3300 примеров KPI, сгруппированных по 73 функциональным областям, а также 83 отраслям и подкатегориям.

примеры KPI для разработчиков программного обеспечения доступны на этой страницеwww.smartKPIs.com -разработка приложений они включают, но не ограничены кому:

• эффективность удаления дефектов
• резервное копирование данных

в дополнение к примерам показателей эффективности, www.smartKPIs.com также содержит каталог отчетов об исполнении, иллюстрирующих использование КПЭ на практике. Примеры таких докладов по информационной технологии можно найти на: www.smartKPIs.com -КПЭ на практике-информационные технологии Веб-сайт обновляется ежедневно с новым контентом, поэтому время от времени проверяйте его дополнительный контент.

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

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

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

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

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

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

проверьте, сколько строк кодов каждый написал.

затем огонь нижней 70%.. Нет 90%!... КАЖДЫЙ ДЕНЬ!

(для людей, которые не уверены, да, я шучу. Серьезный ответ здесь)

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

существует распространенная ошибка, которую многие предприятия делают при настройке своего инструмента управления выпуском. Salesforce release management toolkit-один из лучших инструментов, доступных на рынке сегодня, но если вы не выполните жизненно важные шаги по его настройке, у вас определенно будут очень плохие результаты. Вы сможете использовать его, но не в полной мере. Создание процессов управления релизами в изоляции от бизнес-процессов является одной из худших ошибок. Освобождать инструменты управления идут рука об руку со стратегией предприятия, целями, управлением, управлением изменениями и некоторыми другими аспектами. Процессы управления релизами нужно формировать таким образом, чтобы все в бизнесе были на одной странице.

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

возьмите, например, force.com Migration toolkit, поскольку этот инструмент доказал свою эффективность в управлении. Инструмент управления релизами должен позволять для обеспечения оптимальной видимости и подотчетности в управлении.

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

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

изменения, которые должны произойти с системой Salesforce, могут быть очень сложными и, следовательно, иметь регулярную встречу между бизнесом и им хорошо. Эта воля помогите определить наилучшие изменения для системы, которые принесут пользу бизнесу. Рассматривая стоимость и ценность внедрения того или иного компонента, руководящий комитет должен принять решение о наиболее важных изменениях, которые необходимо внести. Здесь также хорошие исследования http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams

Это старый вопрос, но все-таки, что вы можете сделать, это взять скорость из Agile Software Development, где вы назначаете вес каждой задаче, а затем вычисляете, сколько "веса" вы решаете в каждом спринте (или итерации или любого DLC, который вы используете). Конечно, это связано с тем, что, как и комментатор, упомянутый ранее, вам нужно активно отслеживать, работают ли ваши разработчики или общаются в интернете.

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

в конечном счете, использование КПЭ вместе с velocity может дать вам за разработчика (или за команду) понимание производительности.

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

теперь вы можете использовать такие показатели, как % проектов, завершенных вовремя, % оттока по мере завершения кода и т. д. Это широкое поле.

вот пример:

60% критически важных ошибок были написаны Джо. Это простая, простая метрика. Уволить Джо, да?

Но подождите, есть еще!

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

метрики-плохое измерение разработчиков.

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

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

 1. User Interface - 2 Points
 2. Database CRUD  - 5 Points
 3. Validation     - 4 Points
 4. Design (css)   - 3 Points

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

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

помните, Не отслеживать KPI для их собственного блага, отслеживать его для его понимания.