Обчислити витрати неправильного коду

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

Ми реєструємо роботу за допомогою Jira та пов'язуємо кожен svn-фіксатор до дзвінка jira.

Моя ідея полягає в наступному:

• вручну знайдіть область коду, яка надзвичайно погано реалізована, але часто використовується: як від User-POV, так і від Developer-POV (виправлення)
• отримати svn-коміти, які містять JIRA-Issues
• фільтруйте проблеми за деякими критеріями (тип випуску, версія, пріорі тощо ...)
• обчисліть час / зусилля, витрачені на ці помилки
• оцінити зусилля та ризики рефакторингу
• представити номери та попросити зусиль, щоб виправити це.

Що ти думаєш про це? Чи може таке вимірювання бути корисним та / або переконливим? Які плюси і мінуси?

Я виявив, що якщо ви можете вказати дійсні номери, більше шансів діяти менеджери. (Якщо вони можуть зрозуміти логіку та вартість / вигода.)

ІМХО, щоб зробити переконливий випадок, вам знадобиться таке, щоб показати, наскільки це погано:

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

А щоб зробити випадок рефакторингу, вам знадобиться:

• Оцінка часу для рефакторації та впровадження кожного з найкращих 3 цих поганих речей
• кошторис витрат на реалізацію (ті ж погодинні тарифи, що й вище)

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

• бути менше, ніж n більше випадків підтримки
• з цими речами більше не буде інцидентів (НАЙКРАЩЕ!)

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

Скільки часу мені доведеться чекати, коли завершиться поточний проект Y, поки ви витрачаєте час на роботу над цими питаннями з X ????? (незважаючи на поточні часові повідомлення про підтримку, яких неможливо передбачити і запланувати в діаграмах Ганта)

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

Я ВИЗНАЧЕНО думаю, що це варто зробити, тому ви отримуєте практику побудови справи з показниками та заощаджуєте час, навіть якщо вони цього не роблять. На жаль, переконати не всіх легко, незважаючи на дані. ЩАСТИ!

Майте на увазі, що рефакторинг також вводить помилки (які ви знайдете під час тестування, але, тим не менш, це помилки та їх потрібно виправити). Не тягніть Netscape випадково. Це залежить від вашого особистого визначення поняття "рефакторинг". Для одних це означає "переписати весь код", для інших це означає "змінити деякі внутрішні". Як ти скажеш, який ти вид? Задайте собі таке питання:

Чи я взагалі змінюю публічний інтерфейс?

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

Це складно зробити, бо ніхто ніколи не знає, скільки коштуватиме X з рефактором чи без нього, що було зроблено рік тому. На мій досвід, прагматичні менеджери завжди знімають такі речі, оскільки:

1. Немає прямих потоків доходу від зусиль (фінансові витрати, не підлягають оплаті)
2. Некрасивий робочий код все ще працює кодом, ви ризикуєте створити проблеми замість того, щоб їх виправити (потенційна вартість якості)
3. Інші проекти будуть відкладені, поки ви рефактор (вартість часу)

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

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

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

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