Bagaimana mengukur nilai potensial refactoring

Pada proyek besar dan lama dengan utang teknis, bagaimana Anda dapat memperkirakan atau mengukur manfaat kode refactoring dengan andal?

Misalnya, Anda memiliki beberapa komponen dalam solusi tumpukan perangkat lunak yang ditulis dalam bahasa yang lebih lama, dan beberapa komponen kemudian ditulis dalam bahasa yang lebih baru. Fitur baru dan perbaikan bug terus ditambahkan ke solusi ini oleh tim pengembang.

Para pengembang menyarankan bahwa mengganti komponen bahasa lama yang ada dengan versi baru akan menjadi 'hal yang baik' Namun, tidak ada fitur tambahan akan ditambahkan oleh pekerjaan ini dan itu akan memakan waktu x dev-days.

Seorang tenaga penjualan menyarankan untuk menambahkan 'fitur baru yang hebat'. perusahaan mengukur nilai sarannya dengan menggunakan formula. yaitu. Ini akan menghasilkan perusahaan F juta pound, selama t tahun dengan biaya x hari kerja

Bagaimana cara perusahaan menaikkan biaya proposal refactoring dengan cara yang bermakna? dan dalam keadaan apa itu kemungkinan menjadi opsi yang paling menguntungkan bagi perusahaan?

Ini akan menghasilkan perusahaan F juta pound, selama t tahun dengan biaya x hari kerja

Yang mengabaikan biaya pemeliharaan, biaya pendukung, biaya penjualan / pemasaran, dan membuat banyak asumsi tentang bagaimana fitur akan diambil di pasar.

Tapi apa pun; pertanyaan Anda cukup jelas tentang apa yang Anda cari:

Bagaimana saya bisa membuat kasus bisnis untuk refactoring?

Hal utama yang harus disadari adalah bahwa waktu sama dengan uang. Anda dapat langsung menuju "5 pengembang 2 minggu = 80 jam * 5 pengembang * $ 50 / jam -> $ 20.000" dan itu masuk akal bagi pebisnis. Para pebisnis yang pandai akan mencatat bahwa 5 pengembang itu dibayar dengan cara apa pun, dengan mana Anda melawan bahwa itu tidak menghabiskan / menghemat $ 20.000 - itu menggunakan $ 20.000 dengan cara yang paling menguntungkan. Bagaimanapun, terus dengan daftar.

• Efisiensi - Agaknya, Anda bisa menyelesaikan lebih banyak hal dengan C # daripada VB6. Perkakas yang lebih baik, perpustakaan yang lebih baik, apa pun. Teknologi yang lebih baru cenderung lebih baik dalam hal-hal daripada yang lebih tua. Jika Anda dapat melakukan hal-hal dalam waktu yang lebih singkat, itu berarti Anda menghemat uang perusahaan.
• Overhead - Pengkodean bukan satu-satunya biaya perangkat lunak. Pertimbangkan apa yang terjadi ketika Windows 2020 keluar. Berapa banyak waktu dan usaha yang Anda habiskan untuk menjalankan aplikasi VB6 itu? Berapa banyak waktu dan upaya daripada aplikasi C #? Itu menghemat uang perusahaan Anda.
• Kualitas - Agaknya, Anda dapat menyelesaikan pekerjaan dengan kualitas lebih tinggi dalam C # daripada VB6 (atau dengan arsitektur yang lebih bersih, atau apa pun target refactoring Anda). Kualitas yang lebih tinggi berarti lebih sedikit bug. Lebih sedikit bug berarti lebih sedikit biaya untuk memperbaiki bug itu, lebih sedikit biaya dukungan pelanggan untuk mengatasi masalah tersebut, lebih sedikit kehilangan pelanggan karena masalah kualitas, peningkatan penjualan karena reputasi kualitas ... semua dolar untuk perusahaan Anda.
• HR Savings - Mari kita hadapi fakta: tidak ada yang mau bekerja dengan aplikasi VB6 yang menyebalkan itu. Itu berarti lebih banyak orang akan meninggalkan perusahaan menuju waktu dan uang yang dihabiskan untuk menggantikan mereka. Itu berarti dibutuhkan lebih banyak waktu dan uang untuk merekrut karyawan baru. Yang terburuk, itu berarti Anda akan memiliki pengembang yang benar-benar baik-baik saja melakukan bunuh diri karier bekerja dengan aplikasi VB6 itu. Para pengembang itu pada gilirannya mempercepat spiral masalah kualitas. Memotong turnover dan waktu perekrutan menghemat uang perusahaan Anda. Menghindari pengembang yang puas dan jelek menyelamatkan perusahaan Anda.
• Semangat - Demikian pula, para programmer yang sudah ada benci bekerja di VB6. Mereka akan melakukannya, dan mereka bahkan mungkin melakukannya dengan baik. Tapi itu menyebalkan. Mungkin tidak untuk semua orang, tetapi tentu saja untuk beberapa orang. Itu berarti lebih banyak waktu dihabiskan browsing web untuk memulihkan motivasi. Itu berarti makan siang yang lebih lama. Ini berarti lebih sedikit menyelesaikan sesuatu sementara programmer Anda membutuhkan waktu lebih lama untuk pulih dari pekerjaan yang sial.
• Kemampuan - Ini kurang berlaku dengan refaktor berbasis teknologi, tetapi berlaku untuk jenis arsitektur refaktor. Masalah kode tertentu secara aktif mencegah Anda dari menyediakan fitur keren X untuk menghasilkan banyak uang. Mungkin Anda tidak bisa mengukur. Mungkin Anda tidak bisa mendapatkan data untuk melakukan informatika keren. Mungkin kodenya adalah sarang tikus sehingga sulit untuk benar-benar melakukan pekerjaannya. Masa bodo. Kadang-kadang Anda berada di titik itu, kadang-kadang Anda mengemudi langsung ke titik itu. Sulit diterjemahkan ke dalam bisnis-berbicara, tetapi jika Anda bisa "masalah ini mencegah kita dari mengambil keuntungan dari peluang X, Y dan Z" bisa menjadi kuat.

Semua dalam semua, turun ke "hal ini akan membantu kami melakukan pekerjaan kami lebih baik; jika kami melakukan pekerjaan kami lebih baik, kami dapat membuat / menghemat lebih banyak uang".

Pertanyaan yang harus Anda tanyakan pada diri Anda adalah bagaimana penjual tahu bahwa fitur tersebut akan dikenakan biaya x hari kerja pengembang. Mengingat bahwa bahkan manajer proyek yang baik dengan pengalaman profesional bertahun-tahun sering tidak dapat mengatakan hal itu, data seperti itu berasal dari tenaga penjualan yang tampaknya sangat ... spekulatif .

Menurut pengalaman saya, penjual biasanya tidak membuat perkiraan, tetapi tebak tentang berapa banyak yang terlalu banyak untuk manajemen atau pelanggan: jika manajemen siap untuk membayar 50 orang-minggu kerja, tetapi benar-benar akan menolak 75 orang-minggu, mari kita katakan bahwa fitur tersebut akan memakan waktu 70 man-minggu sementara siap untuk melakukan negosiasi ulang (sesuatu yang tidak mungkin untuk perkiraan nyata) hingga 55 man-minggu.

• Di satu sisi, Anda memiliki perkiraan yang dilakukan oleh para pakar TI yang mengatakan sesuatu seperti:

  Menurut audit khusus ini, kami menghabiskan $ 8.000 per hari menggunakan teknologi yang sudah ketinggalan zaman dibandingkan dengan proyek serupa dengan ukuran yang sama yang menggunakan teknologi yang lebih baru. Tampaknya juga perlu 50 hingga 80 man-minggu untuk memigrasi seluruh basis kode; selama ini, tidak akan ada fitur baru yang dirilis. Ada juga risiko 10% bahwa bermigrasi komponen tertentu dapat mengakibatkan 20-30 minggu kerja tambahan.

• Di sisi lain, Anda memiliki dugaan yang dilakukan oleh salesman, berdasarkan pada leverage mereka ketika bernegosiasi dengan orang yang mereka butuhkan untuk meyakinkan.

Ini semua tentang seberapa besar pengaruh Anda di perusahaan Anda. Komunikasi adalah kunci di sini, dan di sinilah salesman biasanya menang atas profesional TI ketika datang untuk menjelaskan manfaat fitur untuk manajemen (atau pelanggan).

Perhatikan bahwa jika di masa lalu, perkiraan Anda cukup tepat, Anda mendapatkan reputasi dan pengaruh. Jika perkiraan Anda selalu salah, manajemen mungkin akan mengabaikan proposal Anda.

Adapun perkiraan, sangat sulit untuk membuat yang berharga di sini, karena ada sejumlah besar parameter untuk dipertimbangkan. Diantara yang lain:

• Apakah Anda benar-benar tahu seberapa terampil tim Anda di C # dibandingkan dengan VB6? Apakah ini berdasarkan pengukuran aktual atau hanya tebakan?

• Sudahkah tim ini mengembangkan proyek besar dalam C #? Apakah mereka tahu alat yang harus mereka gunakan (IDE, debugger, profiler, dll.)? Apakah Anda memerlukan lisensi tambahan (yang, di dunia Microsoft, berarti ribuan dolar per mesin)?

• Apakah proyek saat ini benar-benar jelas dan Anda dapat menjamin bahwa tidak akan ada kejutan ketika bermigrasi? Apakah langsung menulis ulang semuanya , setiap fitur, atau akankah ada kejutan?

• Apakah Anda memiliki infrastruktur yang mendukung C #? Bagaimana dengan integrasi berkelanjutan? Bagaimana dengan server build Anda? Panduan gaya? Catur statis?

• Dalam produksi, apakah server (jika ini adalah aplikasi web) atau PC pelanggan (jika ini adalah aplikasi desktop) dapat menjalankan versi .NET Framework yang Anda harapkan untuk digunakan?

Tetapi yang paling penting adalah untuk mengetahui mengapa Anda ingin menulis ulang semuanya. Apa masalah yang Anda coba selesaikan melalui penulisan ulang? Hilangnya produktivitas? Bagaimana Anda mengukurnya? Bagaimana Anda menunjukkan hilangnya produktivitas ini bagi manajemen?

Setelah Anda menunjukkan bahwa Anda membuang-buang, katakanlah, $ 8 000 per hari karena VB6 (yang berarti Anda akan menghemat $ 8 000 per hari setelah Anda bermigrasi ke C #), bagaimana Anda menjelaskan manfaat memegang setiap pengembangan fitur baru dan fokus pada penulisan ulang yang lengkap? Apa manfaatnya dibandingkan dengan penulisan ulang progresif tempat Anda memigrasikan komponen Anda dalam potongan kecil satu per satu, sementara mengirimkan fitur baru?

Pertama, Anda perlu memperkirakan biaya pengembangan untuk anjak piutang seperti halnya permintaan fitur yang didorong oleh penjualan.

Ini mungkin sulit untuk menjadi akurat jika itu adalah pekerjaan besar tetapi, dengan asumsi Anda memiliki orang yang cukup berpengalaman dalam 2 teknologi, itu harus bisa dilakukan.

Kedua, Anda perlu perkiraan biaya tidak re-factoring. Jika Anda melakukan perkiraan untuk saya, saya akan mengharapkan beberapa tingkat metrik. Misalnya, perbedaan antara biaya dev rata-rata untuk kode VB dan untuk kode C # lebih dari seperempat. Atau semacamnya. Jelas akan tergantung pada seberapa akurat Anda melacak ini.

Dengan 2 angka ini, Anda dapat memperkirakan periode pengembalian yang akan diberikan oleh re-factoring yaitu pada titik apa re-factoring akan berubah dari biaya bersih menjadi keuntungan bersih.

Saya hanya bisa menebak seberapa persuasif hasil yang diberikan. Namun, jika kurang dari setahun mungkin akan cukup kuat, lebih dari 2 tahun maka Anda mungkin akan kesulitan.

Selain itu, mungkin perlu menambahkan dimensi lain untuk membantu membangun kasing Anda. Salah satu yang saya gunakan di masa lalu adalah melihat apakah ada wawancara keluar mengutip teknologi sebagai driver. Jika demikian, Anda dapat berargumen bahwa re-factoring akan mempertahankan staf (perekrutan dan pelatihan menjadi sangat mahal).

Jelas, Anda dapat memperdebatkan hal-hal ini tanpa bukti yang mendukung tetapi saya menemukan bahwa hal itu dapat membuat perbedaan besar pada dampak kasus ini.

Nilai refactoring muncul dalam berbagai cara.

Ini membantu Anda membuat perubahan lain nanti, sehingga X hari yang akan diambil fitur sekarang akan membutuhkan 2 / 3X hari untuk menyelesaikan. Untuk menggunakan terminologi gesit itu meningkatkan kecepatan.

Perubahan eksplisit yang tercantum akan membantu seiring waktu karena Anda tidak perlu lagi mempertahankan pengembang dengan pengalaman VB6, hanya yang dengan pengalaman C #.

Ini juga membantu dalam cara-cara lain yang kurang nyata seperti retensi dan perekrutan staf. Apakah pekerjaan yang melakukan C # dan VB6 akan lebih atau kurang menarik daripada pekerjaan yang hanya melakukan C #? Apakah Anda akan lebih atau kurang mungkin untuk mengambil pekerjaan atau tetap pada pekerjaan yang bekerja dengan basis kode yang bagus atau yang buruk?

Saya pikir inti dari jawaban lain yang terlewatkan adalah Anda perlu mengukur biaya refactoring terhadap pendapatan yang hilang dari tidak refactoring.

Refactoring demi mengubah kode adalah buang-buang waktu. Perlu membawa nilai ke meja. Dalam konteks ini saya tidak bermaksud menghabiskan satu jam refactoring kelas masalah, tetapi refactoring utama seperti mengubah ke bahasa CLR berbeda seperti yang Anda gunakan dalam contoh Anda.

• Jika kita terus melakukan apa yang kita lakukan, apakah kita kehilangan sesuatu? Apakah ada desain lama crufty di tempat yang menahan kita dari menyadari nilai? Sebagai contoh, jika kita ingin menambahkan fitur apakah itu sangat sulit sehingga mungkin diperlukan misalnya 100 jam untuk mengimplementasikan, vs 50 jam untuk refactor dan 25 jam untuk menerapkan terhadap desain baru?

• Apakah kode yang ada membawa utang teknis yang membebani kita dengan uang? Apakah kode lama jelek ini sumber bug? Apakah kita akhirnya bekerja secara gratis untuk memperbaiki masalah karena itu? Tidak ada yang suka memberikan jam ditagih yang menguntungkan secara gratis.

• Apakah biaya refactoring sama dengan atau kurang dari biaya tidak refactoring?

• Apakah mungkin untuk diamortisasi biaya dengan memiliki tim kecil rockstars refactor kode yang menyebabkan masalah paling banyak? Bisakah kita menyebarkan refactor ke seluruh rilis? Ada banyak inefisiensi kecil di mana-mana: bisakah kita "mengisi kekosongan" sehingga berbicara dengan pekerjaan ekstra ini?

Manfaat memiliki sistem refactored

Anda membuat kasus bisnis untuk refactoring dengan membandingkan keuntungan bisnis garis bawah antara melakukan dan tidak melakukannya. Ini berarti pengurangan biaya riil saat ini, atau peningkatan arus kas masuk riil di masa depan.

Item anggaran utama yang terkena dampak refactoring adalah sebagai berikut:

• Biaya pemeliharaan - jika sistem saat ini merupakan tumpukan spageti yang rapuh, dan dalam praktiknya dapat diamati bahwa memperbaiki bug kecil (baik dalam pengembangan maupun operasi) membutuhkan banyak waktu kerja, maka dapat diperkirakan bahwa biaya seperti pemeliharaan akan lebih kecil untuk sistem "yang dirancang ulang dengan benar". Lihatlah berapa biaya pemeliharaan murni tahunan Anda, dan bagaimana biaya tersebut dapat berubah secara realistis setelah penulisan ulang.

• Biaya penambahan fitur baru - sekali lagi, jika desain dan struktur sistem saat ini membuatnya menghabiskan waktu untuk menulis fitur baru secara tidak masuk akal, maka penulisan ulang mungkin memberikan penghematan. Lihatlah anggaran yang direncanakan untuk fitur baru, tetapi tetaplah realistis - jika Anda mengklaim bahwa Anda akan melihat peningkatan 50% maka diharapkan untuk benar-benar mengembangkan fitur dalam x man-bulan yang sebelumnya membutuhkan 2 * x man-bulan untuk direalisasikan; janji-janji semacam itu mungkin sulit dipenuhi.

• Kualitas perangkat lunak berdampak pada penjualan - jika sistem saat ini sering menyebabkan masalah yang terlihat oleh pelanggan, misalnya crash atau downtime meskipun ada upaya pemeliharaan yang memadai, maka penulisan ulang dapat menjadi solusi. JIKA ini adalah masalah besar, maka orang-orang penjualan yang sama dapat mengukur nilai 'fitur' yang disebut 'produk yang lebih stabil'.

Jika ketiga poin di atas tidak mencapai biaya penulisan ulang yang diharapkan (dan lebih banyak lagi, biaya peluang untuk pengeluaran x hari-ke-bukan pada fitur-fitur sama dengan nilai fitur-fitur tersebut, yang lebih besar dari biaya murni x-dev -hari) maka saya takut itu saja - penghematan yang diharapkan tidak membenarkan penulisan ulang.

Juga, jika peta jalan Anda tidak menunjukkan kebutuhan untuk 'sebanyak yang Anda bisa berikan' fitur baru, maka penghematannya harus dalam bentuk 'itu digunakan untuk mengambil 10 orang untuk melakukan semua hal yang diperlukan, tetapi setelah penulisan ulang kami akan dapat melakukan hal yang sama dengan hanya 6 orang ' . Jika Anda dapat "menjual" lebih banyak proyek pengembangan daripada Anda memiliki pengembang, maka meningkatkan efisiensi memungkinkan Anda untuk mengembangkan lebih banyak hal, tetapi jika bisnis dengan sumber daya saat ini sudah mampu mengembangkan semua hal yang membawa nilai tambahan, maka satu-satunya keuntungan finansial dapat berasal dari membayar lebih sedikit orang atau memiliki orang yang lebih murah.

Nilai refactoring dapat diukur seperti: saat ini fitur baru x akan menelan biaya 5 devs 2 minggu. Jika kami memperbaiki komponen lama, biaya fitur baru akan berkurang sekitar 20%. Jadi fitur baru x hanya akan memakan biaya 4 devs selama 2 minggu.

Refactoring adalah investasi dalam mengurangi biaya pengembangan masa depan. Jika Anda tidak dapat membuat argumen untuk refactoring Anda, mungkin tidak ada alasan bisnis untuk itu.