Teknik borcu ödenecek kadar görünür kılmak
Kimsenin göremediği borca bütçe ayrılmaz. Her kaleme maliyet ve faiz yazın, özellik listesinin içine koyun ve borcu özellik işinin içinde ödeyin.
Her çeyrekte ekipten biri bir modülü toparlamak için iki hafta ister ve her çeyrekte cevap "bu sefer yer yok" olur. Bu cevapta mantıksız bir taraf yok. Masanın bir yanında müşterisi ve tarihi olan bir özellik duruyor, diğer yanında ise "sonrasında çok daha iyi olacak" cümlesine dayanan bir talep. Kimsenin göremediği borca bütçe ayrılmaz ve görünürlük sorunu bizim çözeceğimiz bir sorun.
Görünmeyen borç neden hep kaybeder
İşler karşılaştırılarak önceliklendirilir ve karşılaştırma aynı birimi ister. Özelliğin yanında tahmin, müşteri ve gelir hikâyesi vardır. Temizlik talebinin yanında bir sıfat vardır. Size en sempatik bakan yönetici bile bu ikisini tek listeye koyup dürüstçe seçemez.
Çözüm, her borç kalemine bir özelliğin sahip olduğu üç alanı vermek: maliyeti ne, değeri ne, hiçbir şey yapmazsak ne olur. Borcu özellikten ayıran yer sonuncusu, çünkü hiçbir şey yapmamanın işleyen bir maliyeti var. Faiz budur ve konuşmayı değiştiren sayı odur.
Bilerek alınan borç ile dağınıklık ayrı konuşmalardır
Kelimenin asıl anlamındaki borç bilerek alınır: ekip daha iyi tasarımı biliyordu, bir tarihe yetişmek için hızlı olanı seçti ve bunun sonradan daha pahalıya geleceğini anlamıştı. Bu meşru bir takastır ve bazen doğru karardır.
Dağınıklık ise kimse hiçbir şey seçmediğinde ortaya çıkar. İki kişi farklı zamanlarda geldiği için aynı işi yapan iki ayrı yol. Yazan kişi ayrıldığı için kimsenin anlamadığı bir modül. Kimsenin silmeye cesaret edemediği ölü kod.
İkisi farklı çerçeve ister. Bilerek alınan borç takvim sorusudur: borçlandık, bakiye şu, ödemeyi şuraya planlamıştık. Dağınıklık kalite sorusudur ve ona borç demek hak etmediği bir saygınlık verir. Bilerek alınan borcun bir avantajı daha var: alındığı anda yazılabilir, ki tek paragraflık karar kaydı tam olarak bunun için. "Sürüm baskısıyla seçildi, ikinci entegrasyon gelince yeniden bakılacak" diyen bir kayıt, gelecekteki bir tartışmayı planlanmış bir işe çevirir.
Her kaleme maliyet ve faiz yazın
Kalem başına kısa bir blok, herkesin baktığı aynı sistemde:
Kalem: sipariş import'u üç tabloya transaction olmadan yazıyor
Yakıyor: sipariş alanlarındaki her değişiklikte üç yolun da elle test edilmesi
Kanıt: son 20 sürümün 9'unda dokunuldu, 6 ayda 2 arıza
Maliyet: transaction'a almak ve iki test yazmak için yaklaşık 3 gün
Faiz: sürüm başına kabaca yarım gün fazladan iş, artı arıza riski
Köken: bilerek, üçüncü tablo bir tarihe yetişmek için eklenirken alındıAsıl işi kanıt satırı yapıyor ve o satır zaten elinizdeki veriden çıkıyor. Son yirmi sürümün kaçı o modüle dokundu. O bölgedeki tahminlerin ne kadarı aynı kırılganlık için pay olarak kondu. Kaç arıza oraya kadar izlendi. Hiçbiri tam olmak zorunda değil. Herkesin kontrol edebileceği kaba bir sayı, kimsenin inanmadığı kesin bir sayıdan iyidir; bu da optimize etmeden önce ölçmekle aynı disiplin: var olan bir sayı, sıfatların canlı tuttuğu tartışmaları bitirir.
Faiz, insanların unuttuğu alan ve beklemeyi pahalı kılan tek alan o. Gerçek bir faizi olan kalem ödenir. Düzeltme maliyeti olan ama faizi olmayan kalem isteğe bağlı bir alışverişe benzer, isteğe bağlı alışverişler ise sonsuza kadar ertelenir.
Bundan iki sonuç çıkıyor ve ikisi de para kazandırıyor. Kimsenin dokunmadığı kod ne kadar çirkin olursa olsun faiz üretmez, o yüzden çirkin kalabilir. Her işin içinden geçtiği kod ise ölçülü bir dağınıklıkla bile sahip olduğunuz en pahalı şey olabilir.
Özelliklerle aynı listeye koyun
Ayrı bir teknik borç panosu, borç kalemlerinin sessizce öldüğü yerdir. Oradaki hiçbir madde ana listedeki bir maddeye karşı kazanamaz, çünkü iki liste hiçbir zaman aynı toplantıda karşılaştırılmaz.
Listeyi takvime göre değil yol haritası değiştiğinde yeniden okuyun. Faiz sabit değildir: aylardır kimsenin uğramadığı bir modül, sonraki çeyreğin işlerinin üçü birden oraya düştüğü anda pahalı hale gelir. Yeni işler planlanırken beş dakika ayırıp "bu işler hangi borç kalemlerinin üstünden geçiyor" diye sormak, o çeyrekte hangi kalemin ödeneceğini kendiliğinden söyler. Ödeme kararını verdiren şey genelde kalemin kötülüğü değil, yolun oradan geçecek olması.
Tek liste, aynı birim, aynı değerlendirme. Bir borç kalemi ile bir özellik, maliyetleri ve sonuçları yazılı olarak yan yana durduğunda makul bir insan seçim yapabilir ve bazen özelliği seçer. Bu iyi bir sonuçtur. Amaç, takasın varsayılan olarak değil bilerek yapılması ve faizin herkesin gözü önünde işlemeye devam etmesi.
Özellik işinin içinde ödeyin
Bir çeyreği harcamanın en güvenilir yolu büyük refactor'dur. Aylarca hiçbir şey döndürmeden harcar, bu süre boyunca özelliklerle karşılaştırılır ve yarıda durdurulduğunda kod tabanında iki tasarım birden kalır, ki bu ikisinden de kötüdür.
İşe yarayan yöntem gösterişsiz. Bir özellik, borç kalemiyle aynı bölgeye düştüğünde düzeltme o iş kaleminin içine girer ve tahmin bunu açıkça söyler: beş gün değil sekiz gün, gerekçesi yanında yazılı. Temizlik özellikle birlikte yayına çıkar, aynı trafikle sınanır ve aynı testlerin kapsamına girer. Sürümü geri almak gerekirse iki aylık iş değil tek bir değişiklik geri döner; küçük ve geri alınabilir adımların bütün argümanı da budur.
Birkaç ekipte ayakta kalmış bir kural: tek bir değişikliğin beşte birinden fazlası temizlik olmasın ve hiçbir temizlik tek başına modül sınırını aşmasın. Bundan büyüğü, insanların gerçekten inceleyebileceği bir pull request olmaktan çıkar ve risk tam orada birikmeye başlar.
Müşteriye kendi diliyle anlatın
Müşteriler refactor satın almaz ve almaları için bir sebep de yok. Teslim tarihi, maliyet ve kötü sürpriz olmaması satın alırlar. Bir kere çevirin, konuşma değişir:
A seçeneği: yeni raporu mevcut import'un üstüne ekleriz.
Şimdi 5 gün. Bu bölgedeki her sonraki iş aynı 2 günlük ek
maliyeti taşır ve çift sipariş sorunu mümkün olmaya devam eder.
B seçeneği: raporu ekleriz, önce import'u transaction'a alırız.
Şimdi 8 gün. Sonraki işler normal maliyetine döner ve
çift siparişler biter.Kimsenin borç kelimesini kullanması gerekmiyor. Faiz, gelecekteki bütün işlerin üstündeki ek maliyet olarak görünüyor, düzeltmenin bir fiyatı var ve karar parası kimin cebinden çıkıyorsa onun. Benim gördüğüm kadarıyla B'yi reddeden müşteri bile o ek maliyeti aklında tutuyor ve üçüncü tahminde aynı satırı görünce konuyu kendisi açıyor.
Bunu oturtan iki şey var. Sektör iddialarını değil, birlikte yaptığınız işlerden çıkan kendi sayılarını kullanın. Ve hakkınız olsa bile bunu önceki ekip hakkında bir uyarı gibi sunmayın; suçlamaya benzemeye başladığı anda konu karar olmaktan çıkıp savunmaya döner.
Nelere dikkat etmeli
- Borç tiyatrosu. Faizi yazılmamış kalemlerle dolu bir liste, şikâyet listesidir. Bir kalemi olduğu gibi bırakmanın maliyetini söyleyemiyorsanız o kalem önceliklendirilmeye hazır değildir.
- Borcu baştan yazmaya giden yol olarak kullanmak. Baştan yazmak, eski gereksinimlerin unutulduğu yeni bir projedir; kendi bütçesi ve kendi riskiyle savunulmalıdır.
- Kimsenin çalışmadığı yeri toparlamak. Tatmin edici temizlik genelde sizin sinirinize dokunan dosyadadır, ekibin her hafta düzenlediği dosyada değil. Sinirinizi değil kanıt satırını takip edin.
- Faiz tahminini kesin göstermek. Sahte kesin sayı, kararın yerine sayının tartışılmasına davetiyedir. Yuvarlayın, nasıl bulduğunuzu gösterin ve devam edin.
Borç, bir his olmaktan çıkıp fiyatı ve işleyen maliyeti olan bir satıra dönüştüğünde ödenebilir hale gelir. Bunun için yeni bir süreç değil, bir öğleden sonralık yazı işi yeter. Ekibinizin her hafta etrafından dolaştığı üç yeri seçin, her biri için altı satırı yazın ve hepsini herkesle aynı listeye koyun. Ödenmeyi hak edenler kendiliğinden kazanmaya başlar; hiç kazanamayanların ise düzeltmektense yanında yaşamanın daha ucuz olduğu ortaya çıkar, bunu bilmek de değerlidir.
Sorular ve cevaplar
- Müşteriyi teknik borç için ödemeye nasıl ikna ederim?
- Refactor süresi istemeyi bırakın, aynı özelliği iki türlü fiyatlayın: mevcut kodun üstüne ve düzeltmeyi içerecek şekilde. Birinci tahminin yanına, o bölgedeki her sonraki işin aynı ek maliyeti taşıyacağı notunu düşün. Müşteriler zamanla ve parayla karar verir, yan yana duran iki sayı da gerçekten verilebilir bir karardır.
- Teknik borcun faizi nedir?
- Kalem ödenmediği sürece her sürümün ne kadar yavaşladığı ve riskinin ne kadar arttığıdır. Elinizdeki veriyle ölçün: son yirmi sürümün kaçı o modüle dokundu, o bölgedeki tahminlerin ne kadarı bu kırılganlık için pay olarak kondu, kaç arıza buradan çıktı. Herkesin kontrol edebileceği kaba bir sayı, kimsenin inanmadığı kesin bir sayıdan iyidir.
- Bilerek alınan borç ile dağınıklık arasındaki fark ne?
- Bilerek alınan borç bir gerekçeyle, genelde bir tarih yüzünden seçilmiştir; yazılabilir ve sonradan yeniden ele alınabilir. Dağınıklık ise kimse hiçbir şey seçmediği için birikir: ölü kod, aynı işi yapan üç ayrı yol, kimsenin anlamadığı bir modül. Birincisi takvim konuşmasıdır, ikincisi kalite konuşması; ikincisine borç demek ona hak etmediği bir saygınlık verir.
- Büyük bir refactor doğru cevap olabilir mi?
- Nadiren, ve neredeyse hiçbir zaman kendi takvimi olan ayrı bir proje olarak değil. Uzun refactor aylarca hiçbir şey döndürmeden harcar, bu süre boyunca özelliklerle yarışır ve yarıda kesilince kod tabanında iki tasarım birden kalır. İşi aynı koda dokunan özelliklere bağlamak her hafta değer üretir ve değişikliği geri alınabilir tutar.