Я изучаю некоторые способы измерения производительности команды разработчиков программного обеспечения. Полезно ли использовать инструмент построения? Мы используем Hudson как инструмент автоматической сборки. Интересно, могу ли я взять информацию из отчетов Гудзона и получить от нее прогресс каждого из программистов.Как измерить производительность разработки программного обеспечения?
НЕ измеряйте производительность каждого отдельного программиста с помощью инструмента построения. Вы можете измерить команду в целом, конечно, или вы можете, конечно, измерить прогресс каждого программиста, но вы не можете измерить их производительность с помощью такого инструмента. Некоторые модули более сложны, чем другие, некоторым программистам поручаются другие проекты и т. Д. Это не рекомендуется для этого, и это будет поощрять программистов писать неаккуратный код, чтобы он выглядел так, как будто они больше всего работали.
Это настоящая история. – Njax3SmmM2x2a0Zf7Hpd
Я бы не рекомендовал использовать информацию инструмента построения как способ измерения производительности/прогресса разработчиков программного обеспечения. Некоторые из запутанных проблем: возможно, одна задача намного сложнее другой; возможно, одна задача гораздо более вовлечена в «пространство дизайна», чем «пространство реализации»; возможно (возможно) более эффективное решение - лучшее решение, но лучшее решение вносит меньшее количество строк кода, чем ужасно неэффективное, которое обеспечивает гораздо больше строк кода; и т. д.
Проверьте, сколько строк написано в каждом коде.
Затем огонь внизу 70%. НЕТ 90%! ... КАЖДЫЙ ДЕНЬ!
(для людей, которые не уверены, YES, я шучу. Серьезный ответ here)
Я не могу сказать, шутите вы или нет, но потому, что работа людей может оказаться под угрозой, потому что какой-то менеджер ошибается из-за вашего ответа, я голосую за него. –
Возьмите этот значок равного уровня, пока у вас есть шанс! 8-) – RichieHindle
LOL, смешной человек, смешно. –
No.
Метрики как, которые обречены на провал. Различные люди работают над разными частями кода, разными классами проблем, а абсолютные измерения в лучшем случае вводят в заблуждение.
Способ оценки эффективности разработчика заключается в том, чтобы иметь отличных менеджеров, которые хорошо выполняют свою работу, имеют хорошие спецификации, которые точно отражают требования и тщательно отслеживают прогресс каждого из этих спецификаций.
Трудно сделать правильно. Программное решение не будет работать.
согласился, парень пишет, что наименьшее количество кода действительно может принести большую часть работы. –
Также согласился - одна из самых продуктивных вещей, которые я когда-либо делал, - удалить сотни строк кода – jalanb
Существует много разных способов сделать это. Целые книги написаны по этому вопросу. Вы можете использовать отчеты от Хадсона, но я думаю, что это приведет к дезинформации и даст неоплаченные результаты. На самом деле вам нужна методология отслеживания задач.
Возможно, вы бы лучше измерили, насколько хорошо ваши команды отслеживают графики. Если член команды (или вся команда) постоянно опоздал, вам необходимо будет работать с ними для повышения производительности.
Не сокращайте или не смотрите быстрые и простые способы измерения производительности/прогресса разработчиков. На выходе разработчика есть много факторов. Я видел много людей пытаются различные метрики ...
строк коды производится - поощряет разработчик в большом количество неэффективной мусора сложность мер - способствует более анализу и рефакторинг Количества ошибок, полученных - побуждают человек искать действительно простые задачи и ненавидеть тестеров ... этот список можно продолжить.
При просмотре разработчика вам действительно нужно посмотреть, насколько хороша их работа, и определить «хороший» в контексте того, что нужно обществу, и какие ситуации/позиции компания внесла в это дело. Прогресс следует оценивать с помощью равного внимания и мысли.
Как правило, прямое использование показателей для измерения производительности считается плохим идеей и одним из простых способов запуска команды в землю.
Теперь вы можете использовать показатели, такие как% от выполненных проектов вовремя,% отбойки по мере прохождения кода и т. Д. ... это широкое поле.
Вот пример:
60% критически важных ошибок были написаны Джо. Это простая, простая метрика. Огонь Джо, да?
Но подождите, есть еще!
Joe - старший разработчик. Он единственный, кому доверяют писать сверхнадежный код, каждый раз. Он написал около 80% критически важного программного обеспечения, потому что он лучший.
Метрики - это плохое измерение разработчиков.
Основная проблема, связанная с такими показателями производительности, заключается в том, что люди ОЧЕНЬ хорошо разбираются в любой системе, которая измеряет свою собственную производительность, чтобы максимизировать эту точную метрику производительности - обычно за счет чего-то еще ценного.
Допустим, мы используем сборку hudson для сбора статистики на выходе программиста. Что вы могли бы искать, и каковы были бы непреднамеренные побочные эффекты измерения того, как только программисты будут на них наведываться?
И это продолжается.
Дело в том, что независимо от того, что вы измеряете, люди (а не только программисты) очень хорошо себя чувствуют в оптимизации, чтобы удовлетворить именно эту вещь.
Итак, как вы должны смотреть на производительность своих разработчиков? Ну, это сложно. И это включает в себя людей-менеджеров, которые хорошо понимают людей (и BS они тянут), и могут смотреть на каждого человека субъективно в контексте того, кто/где/что они должны выяснить, если они делают хорошую работу или нет.
Что вы делаете, если выяснилось, кто выполняет/не выполняет, это совсем другой вопрос.
(я не могу взять кредит на эту линию мышления. Это родом из Джоэл Спольски. Here и here)
+1 для вас и +1 для Joel. 8-) – RichieHindle
+1 для отличного ответа. Хотя я видел худшие манипуляции - например, я видел, как люди * создавали * ошибки/проблемы, когда они стимулируются по числу исправленных. Aaargh !! ..... – mikera
Мы получаем 360 обратную связь от всех в команде. Если все члены вашей команды думают, что вы дерьмо, тогда вы, вероятно, так и есть.
Говоря о KPI в разработчиках программного обеспечения. www.smartKPIs.com может быть хорошим ресурсом для вас. Он содержит удобную для пользователя библиотеку хорошо документированных показателей производительности. На данный момент он перечисляет более 3300 ключевых показателей эффективности, сгруппированных в 73 функциональных областях, а также 83 отраслей и подкатегорий.
примеров KPI для разработчиков программного обеспечения доступны на этой странице www.smartKPIs.com - application development Они включают, но не ограничиваются ими:
В дополнении к примерам показателей эффективности , www.smartKPIs.com также содержит каталог отчетов об эффективности, которые иллюстрируют использование KPI на практике. Примеры таких отчетов для информационных технологий доступны на сайте: www.smartKPIs.com - KPI на практике - информационные технологии Сайт обновляется ежедневно новым контентом, поэтому время от времени проверяйте его для получения дополнительного контента.
Обратите внимание, что, хотя примеры показателей эффективности полезны для принятия решений, каждая оценка эффективности должна быть выбрана и настроена на основе целей и приоритетов каждой организации.
Я думаю, что это необходимо очень осторожно, когда вы определяете способы измерения производительности разработчиков, поскольку большинство традиционных методов, таких как строка кодов, количество проверок, количество исправленных ошибок и т. Д., Оказались субъективными для сегодняшнего программного обеспечения инженерных концепций. Мы должны оценивать подход к производительности команды, а также оценивать отдельные ключевые показатели эффективности в проекте. Тем не менее, работая в среде коммерческого развития, важно отслеживать и внимательно следить за следующими факторами отдельных разработчиков;
С гибким подходом в некоторых проектах измерения команды разработчиков и ожидаемой производительности решаются на основе выпусков. При каждом планировании выпуска существуют разные «контракты», согласованные с членами команды для ожидаемой производительности.Я считаю, что этот подход более успешный, поскольку нет никаких оснований придерживаться измерений, связанных с UI, в выпуске, где будет выпущен комплексный алгоритм.
Я бы поделился своим опытом и тем, как я узнал очень ценный процесс измерения производительности команды. Должен признаться, что я столкнулся с отслеживанием KPI просто потому, что большинство отделов будут делать то же самое, но не на самом деле, до тех пор, пока я не буду отвечать за оценку производительности разработчиков, когда после некоторого количества чтения я развился со следующим решением.
Один проект, я хотел бы развлечь команду в обсуждении требований проекта и привлечь их, чтобы все знали, что делать. В том же обсуждении посредством совместной работы мы разбивали проекты на задачи и оценивали эти задачи. Теперь мы оценили бы завершение проекта как 100%, когда каждая задача имеет процентный вклад. Хорошо, что это работало некоторое время, но не было лучшим решением. Теперь мы поставили задачу по весу или точкам точнее и использовали относительные измерения для сравнения задачи и, например, дифференцировали веса. Существует требование разработать веб-форму для сбора пользовательских данных. Задача будет идти о как
1. User Interface - 2 Points
2. Database CRUD - 5 Points
3. Validation - 4 Points
4. Design (css) - 3 Points
С помощью этой стратегии мы можем точно указать еженедельный приблизительная о том, сколько мы закончили и то, что в очереди на целевой группе. Мы также можем указать, кто лучше всего показал себя.
Должен признаться, что по-прежнему сталкиваются с некоторыми проблемами в этой стратегии, так как не каждый разработчик удобен в каждой технологии. Каким-то образом некоторые из них рады изучать технологии просто потому, что в 2015 году они найдут 2015 высокий процент очков, и некоторые из них сделают все возможное.
Помните, не следите за KPI сами по себе, отследите его, чтобы понять его.
Существует общая ошибка, которую многие предпринимают при создании своего инструмента управления выпуском. Инструментарий для управления выпуском Salesforce является одним из лучших, доступных на рынке сегодня, но если вы не выполните основные шаги по его настройке, вы наверняка получите очень плохие результаты. Вы сможете использовать его, но не в полной мере. Создание процессов управления выпуском в отрыве от бизнес-процессов - одна из худших ошибок. Инструменты управления релизами идут рука об руку с корпоративной стратегией, задачами, управлением, управлением изменениями и некоторыми другими аспектами. Процессы управления релизами должны быть сформированы таким образом, чтобы все в бизнесе находились на одной странице.
Цели управления релизами Основная цель управления релизами должна иметь согласованный набор надежных и повторяемых процессов, ресурсов независимы. Это позволяет достичь наиболее выгодной стоимости бизнеса и в то же время оптимизировать использование имеющихся ресурсов. Учитывая, что большинство организаций сосредоточено на выполнении коротких высокодоходных бизнес-проектов, важно оптимизировать цепочку создания стоимости приложения, чтобы убедиться, что нет никаких задержек при доставке бизнес-стоимости.
Возьмем, к примеру, набор средств для принудительной миграции force.com, поскольку этот инструмент оказался отличным в управлении. Инструмент управления выпуском должен обеспечивать оптимальную видимость и подотчетность в управлении.
Процессы и режимы выпуска Процессы управления выпуском должны быть согласованными для всего бизнеса. Необходимо иметь упорядоченные и стандартизированные процессы для разных пользователей инструмента. Это связано с тем, что они будут использовать ту же платформу и ресурсы, которые позволят эффективно выполнять свои задачи.Наличие разных процессов для разных подразделений вашего бизнеса может привести к тяжелым ошибкам в управлении инструментами. Различные наборы пользователей должны иметь представление о том, что делают другие. Как отмечалось выше, видимость имеет большое значение в любом бизнес-процессе.
Когда дело доходит до циклов выпуска, необходимо также иметь одну централизованную систему, которая будет отслеживать все требования различных пользователей. Также необходимо, чтобы эта система была централизована, чтобы команды разработчиков программного обеспечения познакомились с функциями и изменениями, запрошенными бизнесом. Запросы должны стать приоритетными, чтобы удостовериться, что бизнес получает максимальную пользу. Наличие управленческой команды важно, поскольку она участвует в анализе бизнес-требований, а также уделяет приоритетное внимание наиболее подходящим изменениям, которые должен предпринять бизнес.
Изменения, которые могут произойти с системой Salesforce, могут быть очень сложными, и поэтому регулярное общение между бизнесом и ИТ является хорошим. Это поможет определить наилучшие изменения в системе, которые принесут пользу бизнесу. Рассматривая стоимость и ценность реализации функции, руководящий комитет должен решить наиболее важные изменения характеристик. Здесь также хорошее исследование http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams
Это старый вопрос, но все-таки, кое-что вы можете сделать, это занять Velocity от Agile Software Development, где вы назначаете вес для каждой задачи, а затем вы вычислить, сколько «вес» можно решить в каждый спринт (или итерация или любой другой DLC, который вы используете). Разумеется, это связано с тем фактом, что, как уже упоминалось выше, вы должны активно отслеживать, работают ли ваши разработчики или общаются в Интернете.
Если вы знаете, что ваши разработчики работают оперативно, вы можете положиться на это velocity, чтобы дать вам оценку того, сколько работы может сделать команда. Если на любой итерации это число падает (значительно), то либо оно было плохо оценено, либо команда работала меньше.
В конечном счете использование KPIs вместе со скоростью может дать вам представление о разработчике (или команде) по производительности.
проявите активный интерес к тем, что делают ваши программисты, и не зависят от какого-либо случайного программного обеспечения, чтобы предоставить вам информацию, которую он не предназначен для предоставления. –
Связанный: http://programmers.stackexchange.com/questions/26596/metric-by-which-to-hold-developers-accountable –
Этот вопрос не соответствует теме, потому что речь идет о «измерении» производительности в -duh-ческих лиц. – devnull