Менеджер недавно объявил, что тратит слишком много времени на исправление ошибок. Я думаю, он думает, что мы должны писать идеальный код все время (хотя, конечно, все еще не выполняя эти невозможные сроки!), И это заставило меня задуматься, каково среднее значение в отрасли времени, потраченного на исправление ошибок при написании нового кода.
Так есть ли у кого-нибудь показатели по времени, затраченному на исправление ошибок в разработке нового кода? Или есть какой-то эмпирический анализ времени исправления ошибок для отрасли в целом? Это 50% потраченных на исправление ошибок, или это правильно? Как насчет 20% или 33%?
Я рад принять неподтвержденные данные из личного опыта, поскольку это составило бы часть статистики, с которой я мог бы сравнить наши результаты.
Ответы:
Выше звучит очень невежественно. Рекомендуется прочитать для таких случаев: « Факты и ошибки разработки программного обеспечения » Роберта Л. Гласса, в частности «Факт 43. Техническое обслуживание - это решение, а не проблема».
В статье Википедии упоминается, что 80% усилий затрачивается на обслуживание программного обеспечения.
Приведенный выше, я бы также приложил некоторые усилия, чтобы проанализировать, действительно ли все ваши запросы являются ошибками .
По моему опыту, слишком часто запросы на улучшения или новые функции отправлялись как ошибки. Хорошие менеджеры вовлекают своих программистов в выяснение этого - плохие менеджеры, ну, просто продолжайте жаловаться на то, что слишком много времени исправляет ошибки .
источник
Первый вопрос, который нужно задать, заключается в том, действительно ли ваше «исправление ошибок» исправляет ошибки кодирования или что-то еще. Исправление фактических ошибок кода должно быть относительно небольшим в большинстве случаев, если у вас есть хорошая кодовая база. Если вы работаете с плохой базой кода, обширные исправления ошибок неизбежны.
Однако в процессе запуска программы вы обнаружите требования, которые не были задокументированы, непредвиденные действия пользователя, аномалии данных, несовместимость аппаратного обеспечения, проблемы установки и другие проблемы, которые не являются строго ошибками кода. Менеджеры и пользователи часто воспринимают эти проблемы с производственной поддержкой / обслуживанием как ошибки, поскольку они обычно требуют изменения кода.
Я также сталкивался с менеджерами, которые группировали то, что должно было называться незначительными запросами на улучшение, как ошибки. Часто они попадают в систему отслеживания ошибок или сообщений о проблемах, и это может сделать вашу статистику "ошибок" выше, чем она есть на самом деле.
источник
Это зависит от того, сколько у вас там кода, сколько времени там и т. Д.
Время, потраченное на исправление ошибок в программном обеспечении, должно быть предварительно загружено в первые 6–12 месяцев выпуска, однако по мере приближения времени к бесконечности время, затрачиваемое на обслуживание, по сравнению с временем, затрачиваемым на первоначальную разработку, превысит 100% - это просто так Работа.
Хотя у меня нет точных статистических данных (Code Complete, но я не могу точно сказать, какая страница / раздел), по моему опыту, примерно 40% разработки (иногда до 60%) тратится на обслуживание. Очевидно, что чем больше кода вы выпускаете, тем больше времени на обслуживание у вас будет. Ошибки не всегда функциональны и являются результатом неопределенности, так же как и программными дефектами.
источник
если вы используете хороший трекер билетов (например, Jira из Atlasian) и вы потратили время на ввод всех категорий, пользовательских историй, уровней срочности правильно и с согласия ваших товарищей по команде, то фактически рассчитываете эти метрики (и даже больше) удивительно легко
В предыдущем проекте мы использовали Jira для управления списками ошибок / задач / задач, и в итоге это фактически показало нам, что основной причиной задержек и проблем оказались неэффективные методы управления.
Как ни странно, когда эта информация появилась, мы вдруг сказали, что больше не будем использовать Jira и что для ее замены будет предложен новый продукт.
В то же время все запросы на передачу данных через Jira нужно было отправлять руководству, и у нас был удален прямой доступ.
Что не было замечено, так это то, что в рамках расчета статистики команда разработчиков Jira отправляла данные в веб-хук, и этот веб-хук использовался для передачи данных в конечную точку на некоторых внутренних серверах, где у нас был код, который создавал эти отчеты автоматически.
Мы начали мониторинг веб-хука и обнаружили, что, хотя нам было сказано, что Jira больше не используется, он оставался очень живым в течение значительного периода времени дольше (6+ месяцев, если быть точным), и массовое злоупотребление со стороны высшего руководства было просто буйный с неправильным использованием.
Конечно, это не должно быть так сложно, как Джира.
Если вам нужно решение с низкой доходностью, вы можете использовать электронную таблицу google-docs и API уведомлений GDocs для отслеживания задач / заявок / ошибок / запросов функций и т. Д.
Сам GDocs теперь может выпускать веб-хуки и все виды вещей.
Соедините это с Git и / или Github и некоторыми хуками, которые срабатывают, когда код фиксируется в вашем хранилище, и у вас есть достаточно эффективная система домашнего пивоварения, которая может записывать удивительное количество данных.
В целом, однако, из 100% естественного срока службы продуктов, разделение между разработчиками новых приложений и техническим обслуживанием составляет, как правило, 20/80, большая часть затрат в цикле ALM (Application Lifetime Management) берется на расходы на обслуживание и поддержку.
Нет такой вещи, как тратить слишком много времени на исправление ошибок, потому что просто невозможно писать код без ошибок.
Хорошее тестирование и политика непрерывной интеграции уменьшат дефицит, но вы никогда не будете полностью его ликвидировать.
Любой, кто верит в обратное (ИМХО), не обладает достаточными знаниями, чтобы сделать острое суждение, или слеп (в более обычном случае), насколько сложно на самом деле писать программное обеспечение.
Если ваш менеджер готов к этому, и некоторые из них готовы, вы можете предложить, чтобы он следил за вами в течение дня, чтобы он мог точно видеть, что вы делаете и как вы это делаете.
Iv'e работал в нескольких компаниях, где такая работа активно поощрялась: сотрудники высшего уровня следили за сотрудниками более низкого уровня, и наоборот, это может быть действительно очень хорошим опытом обучения для обеих вовлеченных сторон.
источник