средние показатели по времени, затрачиваемому на техническое обслуживание

17

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

Так есть ли у кого-нибудь показатели по времени, затраченному на исправление ошибок в разработке нового кода? Или есть какой-то эмпирический анализ времени исправления ошибок для отрасли в целом? Это 50% потраченных на исправление ошибок, или это правильно? Как насчет 20% или 33%?

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

gbjbaanb
источник
9
Ваш менеджер звучит очень невежественно. Рекомендуется прочитать для таких случаев: « Факты и ошибки разработки программного обеспечения » Роберта Л. Гласса, в частности «Факт 43. Техническое обслуживание - это решение, а не проблема». Статья Википедии упоминает 80% усилий , затраченных на обслуживание программного обеспечения
комар
3
В чем реальная проблема? У вас есть проблемы с качеством? Ваш процесс действительно неэффективен? Или ваш менеджер просто хочет, чтобы программное обеспечение не стоило так дорого?
Кевин Клайн
@gnat: Ваш комментарий лучший ответ
Кевин Клайн
@kevincline спасибо - преобразовал комментарий в ответ
комнат
Техническое обслуживание заключается не только в исправлении ошибок (дефектов), и его количество сильно варьируется для отдельных проектов (= нет определенного ответа). Мне кажется, у вас есть проблемы с качеством.
2012 г.

Ответы:

13

Менеджер недавно объявил, что тратит слишком много времени на исправление ошибок.

Выше звучит очень невежественно. Рекомендуется прочитать для таких случаев: « Факты и ошибки разработки программного обеспечения » Роберта Л. Гласса, в частности «Факт 43. Техническое обслуживание - это решение, а не проблема».

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

мой менеджер делает PHB Дилберта похожим на гения :)

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

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

комар
источник
2
Исправление ошибок! = Техническое обслуживание! Исправление ошибок означает, что вы закодировали ошибки в системе, и их необходимо исправить , чтобы восстановить правильную функциональность . Под обслуживанием я подразумеваю все задачи, такие как исправление ошибок, улучшение масштабируемости, миграция оборудования, повышение производительности и т. Д. Я бы сказал, что более 25-30% времени, затрачиваемого только на исправление ошибок, требует немедленного вызова управления. В целом, до 40-50% усилий, затрачиваемых на обслуживание, звучит разумно для системы среднего размера.
Апурв Хурасия
У вас есть цифры для разных классов ошибок? Очевидно, что если вы получаете большое количество высокоприоритетных ошибок «show stopper», может быть случай, когда процессу разработки потребуется определенная работа для определения источника, но если все его мелочи, это не такая уж большая проблема. Также, как говорит гнат, многие из них могут быть запросами на улучшение.
Stevetech
Ваша цитата из статьи в Википедии неверна! В нем говорится, что «80% усилий по обслуживанию используется для не корректирующих действий» , но ничего не говорится о времени обслуживания по сравнению с проектированием, кодированием или другой работой.
Тобиас Кнаусс
9

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

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

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

jfrankcarr
источник
То, что вы описываете, это то, что у нас есть, но это ничего не меняет :(
gbjbaanb
8

Это зависит от того, сколько у вас там кода, сколько времени там и т. Д.

Время, потраченное на исправление ошибок в программном обеспечении, должно быть предварительно загружено в первые 6–12 месяцев выпуска, однако по мере приближения времени к бесконечности время, затрачиваемое на обслуживание, по сравнению с временем, затрачиваемым на первоначальную разработку, превысит 100% - это просто так Работа.

Хотя у меня нет точных статистических данных (Code Complete, но я не могу точно сказать, какая страница / раздел), по моему опыту, примерно 40% разработки (иногда до 60%) тратится на обслуживание. Очевидно, что чем больше кода вы выпускаете, тем больше времени на обслуживание у вас будет. Ошибки не всегда функциональны и являются результатом неопределенности, так же как и программными дефектами.

Джонатан Рич
источник
0

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

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

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

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

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

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

Конечно, это не должно быть так сложно, как Джира.

Если вам нужно решение с низкой доходностью, вы можете использовать электронную таблицу google-docs и API уведомлений GDocs для отслеживания задач / заявок / ошибок / запросов функций и т. Д.

Сам GDocs теперь может выпускать веб-хуки и все виды вещей.

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

В целом, однако, из 100% естественного срока службы продуктов, разделение между разработчиками новых приложений и техническим обслуживанием составляет, как правило, 20/80, большая часть затрат в цикле ALM (Application Lifetime Management) берется на расходы на обслуживание и поддержку.

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

Хорошее тестирование и политика непрерывной интеграции уменьшат дефицит, но вы никогда не будете полностью его ликвидировать.

Любой, кто верит в обратное (ИМХО), не обладает достаточными знаниями, чтобы сделать острое суждение, или слеп (в более обычном случае), насколько сложно на самом деле писать программное обеспечение.

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

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

Shawty
источник
2
«Нет такой вещи, чтобы тратить слишком много времени на исправление ошибок» - что за дерьмо. Если вы тратите достаточно времени на исправление ошибок, из-за которых ваша компания не может оставаться конкурентоспособной на рынке (потому что вы исправляете ошибки вместо того, чтобы что- то делать ), вы
тратите
А альтернатива? - Вы не тратите достаточно времени на исправление ошибок, и ваше приложение вылетает, сгорает, и ваш конкурент использует все ваши настройки, эффективно выталкивая вас с рынка. Хитрость (и самая сложная часть всего этого) заключается в том, чтобы найти приемлемый баланс.
Shawty
1
Нет, я согласен, но это мое собственное мнение, потому что я искренне верю, что в наши дни искусство правильной отладки становится утраченным искусством. Слишком многие из нас слишком сильно полагаются на такие вещи, как модульные тесты, которые, IMHO, обеспечивают слишком много ложной безопасности. Я не говорю, что модульное тестирование должно быть отменено, но я говорю, что из-за этого больше не хватает правильной практики отладки и исправления ошибок. Это, в свою очередь, приводит к тому, что менеджеры (как описано выше) считают, что исправление ошибок не требуется, и в результате мы искренне не делаем этого (опять же ИМХО).
Shawty
2
модульные тесты и отладка - это разные искусства, используемые для разных задач. Хотя решение проблемы «является ли наш код правильным» лучше предотвращает проблему «почему мой код сломался». При прочих равных, я бы предпочел, чтобы люди были хороши в создании правильного кода, а не в определении основных причин.
Теластин
1
Теперь у меня есть полное согласие. Это печальный факт, что в сегодняшней индустрии многие программисты воспринимают это как очередную работу с 9 до 5, когда они включаются, набирают код, пока не наступит время и не истечет время. Когда-то разработчики гордились написанием хорошего, надежного, хорошо протестированного кода и тратили время на размышления об этом, прежде чем приблизиться к клавиатуре, вы видите очень мало этого в наше время.
Shawty