Як виміряти потенційну величину рефакторингу

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

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

Розробники припускають, що заміна існуючих компонентів старої мови на нову версію буде «хорошою справою». Однак додаткові функції не будуть додані в цю роботу, і це коштуватиме x дев-днів.

Торгова особа пропонує додати "чудову нову функцію". компанія вимірює цінність своєї пропозиції, використовуючи формулу. тобто. Вона заробить компанію F мільйонів фунтів за три роки ціною роботи x x дев-днів

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

Вона заробить компанію F мільйонів фунтів за три роки ціною роботи x x дев-днів

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

Але що б там не було; ваше запитання досить чітко про те, що ви шукаєте:

Як я можу зробити бізнес-справу для рефакторингу?

Головне усвідомити, що час дорівнює грошам. Ви можете перейти безпосередньо до "5 розробників 2 тижні = 80 годин * 5 розробників * $ 50 / год -> 20 000 доларів", і це має сенс для ділових людей. Розумні ділові люди зауважать, що цим 5 розробникам платять будь-яким способом, і ви протидієтесь тому, що це не витрачати / економити 20 000 доларів - це використання 20 000 доларів найбільш вигідним чином. У будь-якому разі, зі списком.

• Ефективність - Імовірно, ви можете отримати більше речей, ніж CB, ніж VB6. Краще інструментарій, кращі бібліотеки, що завгодно. Новіші технології, як правило, кращі в порівнянні зі старими. Якщо ви можете робити речі за менший час, це означає, що ви економите гроші компанії.
• Накладні витрати - Кодування - це не єдина вартість програмного забезпечення. Поміркуйте, що станеться, коли вийде Windows 2020. Скільки часу та сил ви збираєтеся витратити, щоб додаток VB6 працював над ним? На скільки більше часу і зусиль на це, ніж на додаток C #? Це економія грошей вашої компанії.
• Якість. Імовірно, ви можете робити речі більш високої якості на C #, ніж у VB6 (або з більш чистою архітектурою, або будь-яким іншим, що має на меті рефакторинг). Вища якість означає менше помилок. Менше помилок означає менші витрати на виправлення цих помилок, менші витрати на підтримку клієнтів для вирішення цих питань, менші втрати клієнтів через проблеми з якістю, збільшення продажів через репутацію якості ... всі долари для вашої компанії.
• Економія на персоналі - Давайте зіткнемося з фактами: ніхто не хоче працювати з цим чудернацьким додатком VB6. Це означає, що більше людей покинуть компанію, що призведе до часу і грошей, витрачених на їх заміну. Це означає, що потрібно більше часу та коштів, щоб найняти нових співробітників. Найгірше, що це означає, що ви будете мати розробників, які цілком добре вчиняють кар'єрне самогубство, працюючи з цим додатком VB6. Ці розробники, у свою чергу, прискорюють спіраль проблем якості. Скорочення обороту та наймання разів економить гроші вашої компанії. Захоплюючись поступливістю, шалені розробники рятують вашу компанію.
• Мораль - Аналогічно, програмісти, які вже там ненавидять, працюють у VB6. Вони зроблять це, і вони можуть навіть зробити це добре. Але це смокче. Можливо, не для всіх, але, звичайно, для деяких. Це означає більше часу, витраченого на перегляд Інтернету, щоб відновити мотивацію. Це означає довші обіди. Це означає менше робити речі, поки вашим програмістам потрібно більше часу, щоб відновитись після успішної роботи.
• Можливість - Це менш застосовно до рефакторів, керованих технологією, але стосується архітектури типу рефакторів. Деякі проблеми з кодом активно заважають надавати класну функцію X, щоб заробити багато грошей. Можливо, ти не можеш масштабувати. Можливо, ви не можете отримати дані, щоб зробити цікаву інформатику. Можливо, код - це таке гніздо щура, що насправді важко виконати роботу. Що б там не було. Іноді ти в цій точці, іноді їдеш прямо до цієї точки. Важко перекласти на бізнес-розмову, але якщо ви можете, "ця проблема заважає нам скористатися можливостями X, Y і Z" може бути потужною.

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

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

Згідно з моїм досвідом, продавці зазвичай не складають оцінок, але здогадуються про те, скільки це занадто багато для менеджменту чи замовника: якщо керівництво готове заплатити 50 чоловіків-тижнів роботи, але абсолютно відкине 75 людино-тижнів, розповімо що ця функція займе 70 чоловічих тижнів, тоді як вона готова до переговорів (щось не викликає сумніву для реальної оцінки) аж до 55 чоловічих тижнів.

• З одного боку, у вас є оцінки, зроблені IT-експертами, які говорять про щось на кшталт:

  Відповідно до цього аудиту, ми витрачаємо 8 000 доларів на день, використовуючи застарілу технологію порівняно з аналогічними проектами подібного розміру, які використовують новіші технології. Здається, також буде потрібно від 50 до 80 людино-тижнів для міграції всієї кодової бази; за цей час нових функцій не буде випущено. Також існує 10% ризик, що міграція певного компонента може спричинити за собою 20-30 додаткових трудових тижнів.

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

Це все про те, наскільки ти впливаєш у своїй компанії. Комунікація тут є ключовою, і саме тут продавці зазвичай перемагають ІТ-фахівців, коли мова йде про пояснення переваг функції для менеджменту (або замовника).

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

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

• Ви насправді знаєте, наскільки вміла ваша команда в C # порівняно з VB6? Це засновано на фактичних вимірах чи просто здогадах?

• Чи розробили цей колектив великі проекти в C #? Чи знають вони інструменти, якими вони повинні користуватися (IDE, налагоджувачі, профілі тощо)? Вам потрібні додаткові ліцензії (які в світі Microsoft означають тисячі доларів на машину)?

• Чи є поточний проект повністю зрозумілим, і ви можете гарантувати, що сюрпризів під час міграції не буде? Чи просто переписати все , кожну функцію, чи були б сюрпризи?

• Чи є у вас інфраструктура, яка підтримує C #? А як щодо постійної інтеграції? Що з вашим сервером збірки? Стильові путівники? Статичні шашки?

• Чи можуть сервери (якщо це веб-додаток) або персональні ПК (якщо це додаток для настільних ПК) можуть запускати версію .NET Framework, яку ви плануєте використовувати?

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

Після того, як ви показали, що витрачаєте, скажімо, 8 000 доларів на день через VB6 (а це означає, що ви заощадите 8 000 доларів на день, перейшовши на C #), як ви поясніть перевагу використання кожного нового розвитку функцій та зосередившись на повному переписуванні? Яка вигода порівняно з прогресивним перезаписом, коли ви мігруєте свої компоненти невеликими шматками один за одним, одночасно постачаючи нові функції?

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

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

По-друге, вам потрібна оцінка вартості не повторного факторингу. Якби ви робили для мене оцінки, я очікував би певного рівня показників. Наприклад, різниця між середньою вартістю розробника для коду VB та коду C # за чверть. Або якийсь такий. Очевидно, буде залежати від того, наскільки точно ви відстежите це.

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

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

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

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

Значення рефакторингу з'являється різними способами.

Це допомагає вам вносити інші зміни пізніше, тож на тривалість X днів, які ця функція зайняла, зараз знадобиться 2 / 3X дні. Для використання спритної термінології вона збільшує швидкість.

Перерахована чітка зміна з часом допоможе, оскільки вам більше не потрібно буде підтримувати розробників з досвідом VB6, лише тих, хто має досвід C #.

Це також допомагає іншими менш відчутними способами, такими як утримання та підбір персоналу. Чи буде робота з C # і VB6 більш-менш привабливою, ніж робота, яка виконує лише C #? Чи будете ви з більшою чи меншою ймовірністю взяти на роботу або залишитися на роботі, працюючи на приємній кодовій базі або на паршивій?

Думаю, що помилка інших відповідей полягає в тому, що вам потрібно виміряти витрати на рефакторинг проти втрачених доходів від не рефакторингу.

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

• Якщо ми продовжуємо робити те, що робимо, чи щось ми пропускаємо? Чи існує настільки жорстка конструкція, яка стримує нас від усвідомлення цінності? Наприклад, якщо ми хочемо додати функцію, чи настільки складно, що на реалізацію може знадобитися, наприклад, 100 годин, проти 50 годин рефактора та 25 годин для впровадження нового дизайну?

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

• Чи вартість рефакторингу дорівнює або менша, ніж вартість не рефакторингу?

• Чи можливо амортизувати витрати, якщо невелика команда реставраторів rockstars код, що викликає найбільше проблем? Чи можемо ми розповсюджувати рефактор по релізах? Скрізь є невеликі неефективи: чи можемо ми «заповнити прогалини» так би мовити з цією додатковою роботою?

Переваги мати реконструйовану систему

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

Основними статтями бюджету, на які впливає рефакторинг, є:

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

• Витрати на додавання нових функцій - знову ж таки, якщо теперішня конструкція та структура системи робить необґрунтовано багато часу для написання нових функцій, то перезапис може забезпечити економію. Погляньте на ваш запланований бюджет щодо нових функцій, але будьте реалістичні - якщо ви заявляєте, що побачите 50% покращення, то очікуйте, що насправді розвиватиметесь через x man-months, що раніше знадобилося 2 * x man-months; таких обіцянок може бути важко виконати.

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

Якщо три вищевказаних пункту не досягають очікуваної вартості переписування (і більше; альтернативна вартість витрат x dev-днів на не-функції, дорівнює значенню цих функцій, що перевищує чисту вартість x dev -день), то я боюся, що це все - очікувана економія не виправдає перезапис.

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

Значення рефакторингу можна виміряти так: наразі нова функція x коштуватиме 5 дев 2 тижні. Якщо ми рефакторуємо старий компонент, вартість нових функцій зменшиться приблизно на 20%. Тож нова функція x обійдеться лише у 4 деві за 2 тижні.

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