Yeniden yapılanmanın potansiyel değeri nasıl ölçülür?

Teknik borcu olan eski, büyük bir projede, yeniden düzenleme kodunun yararını nasıl güvenilir bir şekilde tahmin edebilir veya ölçebilirsiniz?

Örneğin, daha eski bir dilde yazılmış bir yazılım yığını çözümü içinde bazı bileşenlere ve daha sonra da yeni bir dilde yazılmış bazı bileşenlere sahip olduğunuzu varsayalım. Bir geliştirme ekibi tarafından sürekli olarak yeni özellikler ve hata düzeltmeleri bu çözüme eklenmektedir.

Geliştiriciler, mevcut eski dil bileşenlerini yeni sürümle değiştirmenin 'iyi bir şey' olacağını öne sürüyorlar. Ancak, bu çalışmanın ek bir özelliği eklenmeyecek ve x dev-day'a mal olacak.

Bir satış elemanı 'harika bir özellik' eklemeyi önerir. Şirket önerisinin değerini bir formül kullanarak ölçmektedir. yani. X dev-günlük iş bedeli karşılığında t yılı aşkın bir süredir F milyon lirayı kazanacak

Şirket, yeniden yapılanma teklifini anlamlı bir şekilde nasıl karşılayabilir? ve hangi şartlar altında şirket için en karlı seçenek olabilir?

X dev-günlük iş bedeli karşılığında t yılı aşkın bir süredir F milyon lirayı kazanacak

Bakım maliyetlerini göz ardı eden, destek maliyetlerini, satış / pazarlama maliyetini göz ardı eden ve özelliğin piyasada nasıl alınacağı konusunda pek çok varsayımda bulunuyor.

Fakat herneyse; Sorunuz, aradığınız şey hakkında yeterince açık:

Yeniden yapılanmaya yönelik bir iş vakasını nasıl yapabilirim?

Gerçekleşmesi gereken en önemli şey zamanın paraya eşit olmasıdır. Doğruca "5 geliştirici 2 hafta = 80 saat * 5 geliştirici * 50 ABD Doları / saat -> 20.000 ABD Doları" seçeneğine gidebilirsiniz ve bu iş adamlarına anlamlı gelir. Akıllı iş adamları, bu 5 geliştiriciye her iki şekilde de ödeme yapıldığını ve bunun 20.000 doları harcama / tasarruf etmediğine karşı koyduğunuza dikkat edecek - 20.000 doları en karlı şekilde kullanıyor. Her neyse, listede.

• Verimlilik - Büyük olasılıkla, C # ile VB6'dan daha fazla iş yapılabilir. Daha iyi takım, daha iyi kütüphaneler, her neyse. Yeni teknolojiler, eski teknolojilerden daha iyi olma eğilimindedir. Daha az zamanda iş yapabiliyorsanız, bu şirketten tasarruf edeceğiniz anlamına gelir.
• Genel gider - Kodlama, yazılımın tek maliyeti değildir. Windows 2020 çıktığında ne olacağını düşünün. Bu VB6 uygulamasını çalıştırmak için ne kadar zaman ve emek harcayacaksınız? Bu bir C # uygulamasından daha ne kadar zaman ve çaba harcıyor? Bu, şirketinize para kazandırıyor.
• Kalite - Muhtemelen, C # 'da VB6'dan daha yüksek kalitede (veya daha temiz bir mimaride veya refactoring hedefiniz ne olursa olsun) işleri halledebilirsiniz. Daha yüksek kalite daha az hata demektir. Daha az hata, bu hataları düzeltmek için daha az maliyet, daha az müşteri desteği maliyeti, bu sorunları çözmek için daha az müşteri kalitesi, kalite sorunları nedeniyle daha az müşteri kaybı, kaliteye olan saygınlık nedeniyle artan satışlar ... şirketiniz için tüm dolarları ifade eder.
• İK Tasarrufu - Gerçeklerle yüzleşelim: kimse bu boktan VB6 uygulamasıyla çalışmak istemiyor. Bu, daha fazla insanın şirketi bırakmak için zamana ve paraya harcayacağı anlamına gelir. Bu, yeni çalışanlar işe almak için daha fazla zaman ve para gerektirir. Hepsinden kötüsü, bu VB6 uygulamasıyla çalışan kariyer intiharı için tamamen iyi olan geliştiricilere sahip olacağınız anlamına gelir. Bu geliştiriciler sırayla kalite sorunlarının ölüm sarmalını hızlandırıyor. Ciro ve işe alım sürelerinin kısaltılması şirketinize para kazandırır. Şikayet etmek, berbat geliştiricileri uzak tutmak şirketinizi kurtarır.
• Moral - Benzer şekilde, zaten var olan programcılar VB6'da çalışmaktan nefret ediyor. Onlar yapacaklar ve hatta iyi yapabilirler. Ama berbat. Belki herkes için değil, kesinlikle bazıları için. Bu, motivasyonu telafi etmek için internette gezinmek için harcanan daha fazla zaman demektir. Daha uzun öğle yemekleri demektir. Programcıların berbat işten kurtarmak için daha uzun sürdüğü sırada daha az iş yapılması anlamına gelir.
• Yetenek - Bu, teknoloji odaklı refraktörlerde daha az uygulanabilir ancak mimari refactor tipleri için de geçerlidir. Bazı kod sorunları aktif olarak tonlarca para kazanmak için X özelliğini serinletmenizi önler. Belki ölçeklenemezsiniz. Belki harika bilişim yapmak için verilere ulaşamazsınız. Belki de kod öyle bir sıçan yuvasıdır ki işi gerçekten engellemenin zor olduğunu. Her neyse. Bazen o noktadasın, bazen doğrudan o noktaya gidiyorsun. İş konuşmaya çevirmek zor, ama eğer "bu sorun X, Y ve Z fırsatlarından faydalanmamızı önlüyorsa" güçlü olabilir.

Sonuç olarak, bu "işlerimizi daha iyi yapmamıza yardımcı olacak; işlerimizi daha iyi yaparsak, size daha fazla para kazandırabilir / kurtarabiliriz" anlamına geliyor.

Kendinize sormanız gereken soru satış elemanı nasıl biliyorum özelliği mal olacağı x işin geliştirici günleri. Yıllarca süren mesleki deneyime sahip iyi proje yöneticileri bile bunu söyleyemez, çünkü bir satıcıdan gelen bu tür veriler son derece spekülatif görünüyor .

Tecrübelerime göre, satış görevlileri genellikle tahmin yapmazlar, ancak yönetim veya müşteri için ne kadar fazla olduğu hakkında tahminler yaparlar : yönetim 50 haftalık iş gününü ödemeye hazırsa, ancak 75 haftalık çalışmayı kesinlikle reddedecek bu özelliğin 70 adam-hafta alacağı ve 55 - haftaya kadar yeniden müzakere edilmeye hazır (gerçek bir tahmin için söz konusu olmayan bir şey) olması.

• Bir yandan, BT uzmanları tarafından yapılan tahminlerde şöyle yazıyor:

  Bu özel denetime göre, daha yeni teknolojiler kullanan benzer büyüklükteki benzer projelere kıyasla eski bir teknoloji kullanarak günlük 8000 dolar harcıyoruz. Ayrıca tüm kod tabanını taşımanın 50 ila 80 adam hafta alacağı da anlaşılıyor; Bu süre zarfında, piyasaya sunulan yeni özellikler olmayacaktı. Ayrıca, belirli bir bileşenin taşınmasının 20-30 ek iş haftası çalışmasıyla sonuçlanabileceği% 10 riski vardır.

• Öte yandan, ikna etmek için ihtiyaç duydukları kişi ile pazarlık yaparken kaldıraçlarına dayanarak, satıcılar tarafından yapılan tahminlere sahipsiniz .

Her şey şirketinizde ne kadar etkili olduğunuzla ilgili. İletişim burada anahtardır ve bu, bir özelliğin yönetime (veya bir müşteriye) yararlarını açıklamak söz konusu olduğunda satıcıların genellikle BT uzmanlarını kazandığı yerdir.

Geçmişte, tahminleriniz oldukça kesinse, itibar ve nüfuz kazandığınızı unutmayın. Tahminleriniz daima yanlış olsaydı, yönetim muhtemelen tekliflerinizi görmezden gelirdi.

Tahminlere gelince, burada dikkate alınması gereken çok sayıda parametre olduğundan, burada değerli bir tane yapmak oldukça zordur. Diğerleri arasında:

• Takımın C # ile VB6'ya göre ne kadar yetenekli olduğunu biliyor musun? Gerçek ölçümlere mi yoksa sadece tahminlere mi dayanıyor?

• Bu ekip C # da büyük projeler geliştirdi mi? Kullanmaları gereken araçları (IDE, hata ayıklayıcılar, profil oluşturucular vb.) Biliyorlar mı? Ek lisanslara ihtiyacınız var mı (bu, Microsoft'un dünyasında, makine başına binlerce dolar anlamına gelir)?

• Mevcut proje tamamen açık mı ve göç ederken sürpriz olmayacağının garantisi var mı? Her şeyi , her özelliği yeniden yazmak kolay mı yoksa sürprizler mi olacak?

• C # destekleyen altyapıya sahip misiniz? Sürekli entegrasyona ne dersiniz? Peki ya derleme sunucunuz? Stil rehberleri? Statik dama?

• Üretimde, kullanacağınız .NET Framework sürümünü çalıştırabilen sunucular (bu bir web uygulaması ise) veya müşteri bilgisayarları (bu bir masaüstü uygulaması ise)?

Fakat en önemli şey neden her şeyi yeniden yazmak istediğinizi bilmek . Yeniden yazma yoluyla çözmeye çalıştığınız sorun nedir ? Verimlilik kaybı? Bunu nasıl ölçüyorsunuz? Bu verimlilik kaybını yönetime nasıl gösteriyorsunuz?

VB6 nedeniyle günde 8000 dolar boşa harcadığınızı gösterdikten sonra (yani, C # 'a geçtiğinizde günde 8000 dolar tasarruf edeceğiniz anlamına gelir), her yeni özellik geliştirmeyi korumanın faydasını nasıl açıklarsınız ve tam bir yeniden yazmaya odaklanmak? Yeni özellikler gönderirken, bileşenlerinizi tek tek küçük parçalar halinde birer birer geçirdiğinizde ilerleyen yeniden yazma ile karşılaştırmanın yararı nedir ?

Öncelikle, satış odaklı özellik talebinde olduğu gibi yeniden faktoring için dev maliyetini tahmin etmeniz gerekir.

Bu, eğer büyük bir iştirse, doğru olması zor olabilir, ancak, 2 teknolojide yeterince tecrübeli insan bulunduğunuzu varsayarsak, yapılabilir olmalıdır.

İkincisi, yeniden faktoring yapmamanın maliyetinin bir tahminine ihtiyacınız var. Benim için tahminleri yapıyor olsaydın, bazı seviyelerde ölçümler beklerdim. Örneğin, VB kodu ve çeyrek boyunca C # kodu için ortalama dev maliyeti arasındaki fark. Ya da böyle. Açıkçası bunu ne kadar doğru izleyeceğinize bağlı olacak.

Bu 2 sayıyla, yeniden faktoringin size sağlayacağı geri ödeme süresini, yani yeniden faktoringin hangi noktada net bir maliyetten net bir kazanca döneceğini tahmin edebilirsiniz.

Sadece herhangi bir sonucun ne kadar ikna edici olacağını tahmin edebilirim. Ancak, bir yıldan az olması durumunda, muhtemelen oldukça güçlü olacak, 2 yıldan daha fazla bir süre sonra iyi mücadele edebileceksiniz.

Ek olarak, muhtemelen davanızın oluşturulmasına yardımcı olacak başka boyutlar eklemeye değer. Geçmişte kullandığım biri, herhangi bir çıkış görüşmesinin teknolojiyi sürücü olarak gösterip göstermediğini görmek. Öyleyse, yeniden faktoringin personeli koruyacağını (işe alma ve eğitimin pahalı olması) iddia edebilirsiniz.

Açıkçası, bunları kanıt desteklemeden tartışabilirsiniz ama bunun davanın etkisinde çok büyük bir fark yaratabileceğini düşünüyorum.

Yeniden yapılanmanın değeri farklı şekillerde ortaya çıkıyor.

Daha sonra başka değişiklikler yapmanıza yardımcı olur, bu nedenle bu özelliğin alacağı X günlerinin tamamlanması 2 / 3X gün sürer. Çevik terminolojiyi kullanmak, hızı arttırır.

Listelenen açık değişiklik zaman içinde yardımcı olacaktır çünkü VB6 deneyimine sahip geliştiricilere, sadece C # deneyimine sahip olan kişilere bakmanıza gerek kalmayacak.

Ayrıca, personel tutma ve işe alma gibi diğer daha az somut yollardan da yardım eder. C # ve VB6 yapan bir iş sadece C # yapan bir işten daha fazla mı yoksa daha az çekici mi olur? Bir işe girme ihtimaliniz veya az ya da kötü bir kod üzerinde çalışan bir işte kalma ihtimaliniz çok mu düşük?

Bence diğer cevapların kaçırdığı nokta, yeniden yapılanmanın yeniden yapılanma değil, gelir kaybına karşı yeniden yapılanma maliyetini ölçmeniz gerektiğidir.

Kod değiştirmek uğruna yeniden düzenleme, zaman kaybıdır. Masaya değer katması gerekiyor. Bu bağlamda, bir problem sınıfını yeniden değerlendirmek için bir saat harcamak istemiyorum, örneğin örneğinizde kullandığınız gibi farklı bir CLR diline geçmek gibi ana yeniden düzenleme yapmak.

• Yaptığımız şeyi yapmaya devam edersek, bir şey mi kaçırıyoruz? Bizi değer yaratmaktan alıkoyacak eski bir tasarım var mı? Örneğin, bir özellik eklemek istiyorsak, uygulamanın 100 saat, yeniden yapılandırıcıya 50 saat ve yeni tasarıma karşı uygulama 25 saat sürmesi o kadar zor olabilir?

• Mevcut yasa bize para kazandıran teknik borç taşıyor mu? Bu berbat eski kod böceklerin kaynağı mı? Bu yüzden sorunları çözmek için ücretsiz olarak çalışabilir miyiz? Kimse kazançlı faturalandırılabilir saatleri ücretsiz vermekten hoşlanmaz.

• Yeniden yönlendirme maliyeti, yeniden yönlendirme yapmama maliyetine eşit mi, yoksa daha mı düşük?

• En fazla soruna neden olan kodu küçük düşüren küçük bir rock yıldızı ekibiyle maliyetin düşürülmesi mümkün müdür? Refactor'ü bültenlere yayabilir miyiz? Her yerde küçük verimsizlikler var: bu ekstra çalışma ile konuşmak için "boşlukları doldurabilir miyiz"?

Yeniden yapılandırılmış bir sisteme sahip olmanın faydaları

Yeniden yapılanma için, yapmanın ve yapmamanın arasındaki iş avantajlarını karşılaştırarak bir iş vakası yaratırsınız. Bu, mevcut gerçek maliyetlerin azaltılması veya gelecekteki gerçek nakit girişindeki artış anlamına gelir.

Yeniden yapılanmadan etkilenen kilit bütçe kalemleri aşağıdaki gibidir:

• Bakım maliyetleri - mevcut sistem kırılgan bir spagetti yığınıysa ve pratikte küçük hataların (hem geliştirme hem de operasyonlarda) düzeltilmesinin çok fazla çalışma saati sürdüğü gözlemlenebilirse, bu masrafların bakım "uygun şekilde yeniden tasarlanmış" bir sistem için daha küçük olacaktır. Yıllık saf bakım maliyetlerinizin ne olduğuna ve yeniden yazma işleminden sonra gerçekçi olarak nasıl değişebileceklerine bir göz atın.

• Yeni özellikler eklemenin maliyeti - yine, eğer mevcut sistem tasarımı ve yapısı yeni özellikler yazmayı makul bir şekilde zaman alıcı hale getiriyorsa, yeniden yazma tasarruf sağlayabilir. Yeni özellikler için planlanan bütçenize bir göz atın, ancak gerçekçi olun -% 50 iyileşme göreceğinizi iddia ederseniz, aslında daha önce gerçekleştirmesi gereken 2 ay x 2 ay olan x adam-ay içinde özellikler geliştirmesini bekleyin; bu tür sözleri tutmak zor olabilir.

• Yazılımın satışlar üzerindeki kalite etkisi - mevcut sistem sık sık müşterinin görebileceği sorunlara neden oluyorsa, örneğin yeterli bakım çabasına rağmen kazalar veya duruş süreleri söz konusu ise, yeniden yazma bir çözüm olabilir. EĞER bu önemli bir konudur, daha sonra aynı satış insanların daha istikrarlı ürün 'adı verilen bir' özelliğinin değerini ölçmek.

Yukarıdaki üç puan beklenen yeniden yazma maliyetine ulaşmazsa (ve daha fazla; özellik dışı x harcama günlerini özellik dışı harcamalara fırsat maliyeti, bu x değerinin saf maliyetinden daha büyük olan bu özelliklerin değerine eşittir. -days) o zaman korkarım ki bu - beklenen tasarruf yeniden yazmayı haklı çıkarmaz.

Ayrıca, yol haritanızda 'yeni özellikler sunabildiğiniz kadar' bir ihtiyaç göstermiyorsa, tasarruflar bir biçimde olmalı , gerekli tüm işleri yapması için 10 kişiyi almalıydı; 'Sadece 6 kişiyle aynı şeyi yapabilecek' . Geliştiricilere sahip olduğunuzdan daha fazla geliştirme projesi "satabiliyorsanız", verimliliği artırmak daha fazla şey geliştirmenize olanak sağlar, ancak mevcut kaynaklara sahip bir işletme zaten ekstra değer getiren her şeyi geliştirebiliyorsa, o zaman tek finansal fayda daha az kişiye ödeme yapmaktan veya daha ucuz kişilere sahip olmaktan gelebilir.

Yeniden yapılanmanın değeri şu şekilde ölçülebilir: şu anda yeni özellik x 5 devs 2 haftaya mal olacak. Eski bir bileşeni yeniden değerlendirirsek, yeni özelliklerin maliyeti yaklaşık% 20 oranında azaltılacaktır. Bu nedenle, yeni özellik x 2 hafta boyunca yalnızca 4 devire mal olacak.

Refactoring, gelecekteki gelişmelerin maliyetini azaltmaya yönelik bir yatırımdır. Yeniden yapılanmanız için bu tartışmayı yapamazsanız, muhtemelen bunun için bir iş vakası yoktur.