середні показники промисловості за час, витрачений на обслуговування

Нещодавно менеджер оголосив, що витрачає занадто багато часу на виправлення помилок. Я думаю, він думає, що ми повинні писати ідеальний код весь час (поки все-таки стикаються з цими неможливими термінами!), І це змусило мене замислитись про те, який середній показник витрат часу на виправлення помилок у написанні нового коду.

Так чи має хто-небудь показники щодо виправлення помилок, витрачених на час, проти розробки нового коду? Або є емпіричний аналіз часу на виправлення помилок для галузі в цілому? Чи занадто багато на виправлення помилок на 50%, чи приблизно так? Як щодо 20% чи 33%?

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

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

Вище звучить дуже невідомо. Пропонується прочитати такі випадки: Факти та помилки інженерії програмного забезпечення Роберта Л. Гласса, зокрема "Факт 43. Обслуговування - це рішення, а не проблема".

У статті Вікіпедії згадується 80% зусиль, витрачених на обслуговування програмного забезпечення.

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

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

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

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

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

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

Це залежить від того, скільки у вас коду, скільки часу він там і т.д.

Час, витрачений на виправлення помилок у програмному забезпеченні, повинен бути завантажений на перший план до перших 6-12 місяців випуску, однак, коли час наближається до нескінченності, час, витрачений на технічне обслуговування порівняно з витраченим на початкову розробку, перевищить 100% - це саме так робота.

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

якщо ви використовуєте хороший трекер квитків (наприклад, Джира з Атлантії), і ви витратили час на введення всіх різних категорій, історій користувачів, рівнів актуальності правильно та за згодою своїх товаришів по команді, то насправді обчислюючи ці показники (і багато іншого) напрочуд легко.

У попередньому проекті ми використовували Джиру для управління нашими списками помилок / завдань / todo, і врешті-решт це насправді показало нам, що найбільшою причиною затримок і проблем виявилися неефективні методи управління.

Як не дивно, коли ця інформація з'явилася, ми де раптом сказали, що більше не будемо використовувати Джиру, і що замінить її буде новий товар.

Тим часом усі запити про передачу даних через Джиру повинні були бути надіслані команді управління, і нам було видалено прямий доступ.

Те, що не помітили, було те, що в рамках підрахунку статистики команда розробників проводила Джиру, що наводив дані на гачок веб-сторінок, і цей веб-гачок використовувався для передачі даних до кінцевої точки на деяких внутрішніх серверах, де у нас був створений код ці звіти автоматично.

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

Звичайно, це не повинно бути чимось складним, як Джира.

Якщо ви хочете вирішити низький дохід, ви можете використовувати аркуш розширення google-docs та API сповіщення GDocs для відстеження завдань / квитків / помилок / запитів на функції тощо.

Сам GDocs тепер може випускати веб-гачки та всілякі речі.

З'єднайте це з Git та / або Github та деякими гачками, які спрацьовують, коли код введено у ваше сховище, і у вас є досить ефективна система домашнього пивоваріння, яка може записувати дивовижну кількість даних.

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

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

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

Кожен, хто вірить в інше (IMHO), не має достатньо знань для того, щоб винести акуратне судження, або сліпий (Більш звичний випадок), наскільки складно написати програмне забезпечення.

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

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