Spec-Driven Development: iş birimi mühendisliği beklemeyi bıraktığında ne olur

Yeni bir kurumsal özellik için ortalama geliştirme döngüsü üç ila altı ay sürer. Özellik kullanıma sunulduğunda pazar çoktan değişmiş, öncelikler kaymış ve başlangıçtaki gereksinimlerin bir kısmı gerçeği yansıtmaz hâle gelmiştir. Kimsenin suçu yok. Süreç tam da tasarlandığı gibi işliyor. Sorun da bu.

Spec-Driven Development, bu modeli yamamak değil, kırmak için bir girişimdir.

Geleneksel geliştirme gerçekte nerede kırılıyor

Klasik yazılım süreci bir kulaktan kulağa oyunudur. İş birimi bir fikir ortaya koyar. Bir analist onu yorumlar. Bir mimar onu teknik bir spesifikasyona çevirir. Bir geliştirici bu spesifikasyonu kendi zihinsel modeliyle okur. Kalite güvence ekibi, amaçlananı değil, yapılanı test eder. Her devirde sinyal zayıflar ve ürün kullanıma sunulduğunda ilk niyete yakın, ama tam olarak o olmayan bir şeyi hayata geçirir.

Bu bir yetenek sorunu değil, bir mimari sorunudur. Niyet ile sonuç arasında çok fazla yorumcu var.

İkinci zayıf nokta, değişikliğin maliyetidir. Gereksinim yönetimi araştırmaları, gereksinim aşamasında yapılan bir hatanın, çalışan koda yerleştikten sonra düzeltilmesinin 5–10 kat daha pahalıya mal olduğunu tutarlı biçimde gösteriyor. İş birimi bunu bildiği için gereksinimleri değiştirmekten kaçınır. Mühendislik bunu bildiği için kapsam değişikliklerine direnir. Sonunda iki taraf da yalnızca yeniden çalışma faturasından kaçınmak için gerçeğin güncelliğini yitirmiş bir resmiyle çalışır.

SDD gerçekte neyi değiştiriyor

Temel fikir yanıltıcı derecede basit: Spesifikasyon tüm projeyi yöneten birincil belge hâline gelir, teknik uygulamayı ise yapay zekâ ajanları üstlenir.

İş birimi sistemin ne yapması gerektiğini tanımlar — teknik jargon olmadan, sade bir dille. Yapay zekâ ajanı nasıl uygulanacağını belirler. Mühendis, çevirinin kalitesini ve doğruluğunu kontrol eder. Kod, spesifikasyonun bir türevi hâline gelir — tersi değil.

Üç şey kökten değişir.

Hız. Yeni bir özelliğin çalışan prototipi haftalar değil, günler içinde hazır. Birden fazla hipotez eş zamanlı test edilebilir. İş fikirleri tam bir sprint başlatmadan hızla doğrulanabilir. Bain & Company, yapay zekâ araçlarının geliştirme döngülerini şimdiden %20–30 kısalttığını bildiriyor. SDD daha da ileri gider: Yalnızca kod üretimini değil, tüm sürecin en yavaş ve en pahalı aşaması olan gereksinimlerin koda aktarılmasını da otomatikleştirir.

Değişiklik maliyeti. Geleneksel geliştirmede proje ortasında gereksinimleri değiştirmek neredeyse kriz demektir. SDD'de ise olağan bir işlemdir. Kod elle yazılmak yerine spesifikasyondan üretildiği için yeniden üretilmesinin maliyeti neredeyse sıfırdır. Bu, karar alma mantığını tümüyle değiştirir: Ekipler, yeniden çalışma faturasından çekinmeden deneme yapabilir, varsayımları sınayabilir ve yön değiştirebilir.

Somut bir örnek: Bir ekip mimariyi belirli bir iş modeli üzerine kurar, bir ay geçtikten sonra da modelin yanlış olduğunu fark eder. Geleneksel geliştirmede bu, üç ila dört aylık emeğin çöpe gitmesi demektir. SDD'de spesifikasyon bir günde düzeltilir. Kod birkaç saat içinde yeniden üretilir.

Şeffaflık. Spesifikasyon teknik bir belge değil, bir iş belgesidir. Teknik geçmişi olmayan paydaşlar onu okuyabilir, doğrulayabilir ve değiştirebilir. İş birimi, geliştirme başlamadan önce tam olarak neyin geliştirileceğini görür. İş mantığından her sapma, sürüm yayımlandıktan sonra değil, spesifikasyon düzeyinde ortaya çıkar. Gereksinim değişikliklerinin tüm geçmişi sürüm denetimi altında tutulur ve görünürdür.

Ekip üzerindeki etkisi

SDD mühendisleri ortadan kaldırmaz; onları değerli kılan şeyi değiştirir. Teknoloji yığınındaki derinlik daha az önem taşır. Mimari düşünce ve gereksinimleri biçimsel olarak ifade edebilme becerisi daha çok önem kazanır. Yapay zekâ ajanlarını yöneten tek bir mühendis, daha önce üç ya da dört uzmandan oluşan bir ekip gerektiren iş yükünü artık tek başına karşılıyor.

McKinsey, yapay zekâyı geliştirme iş akışlarına sistemli biçimde yerleştiren kuruluşlarda %20–45 verimlilik artışı saptıyor. SDD, gereksinimlerden koda kadar tüm döngüyü otomatikleştirerek bu etkiyi büyütür.

Adını koymaya değer, daha az göze çarpan bir etki daha var: bilginin korunması. Geleneksel modelde iş mantığı insanların zihninde yaşar. Kilit bir mühendis ayrıldığında, sistemin neden bu şekilde çalıştığına dair kritik kurumsal bilgi de onunla birlikte gider. SDD'de spesifikasyon, sistemin iş mantığının eksiksiz tanımını içeren yaşayan bir belgedir. Ekibe yeni katılan biri onu okuyarak tüm sistemi hemen kavrar.

En iyi sonuç verdiği alanlar

SDD belirli durumlarda en yüksek etkiyi sağlar. Gereksinim belirsizliği yüksek ve sık yön değiştiren girişimlerde deneme maliyeti neredeyse sıfıra iner. Sürüm döngüleri hızlı olan rekabetçi pazarlarda yeni özelliklerin teslim hızı doğrudan pazar payını etkiler. Düzenlemeye tabi alanlarda uyum gereksinimleri spesifikasyona yerleştirilir ve her değişiklikte otomatik olarak doğrulanır. Eski sistemlerin modernizasyonunda mevcut sistemin spesifikasyonu bir kez yazılır ve kontrollü geçişin temeli olur.

Dürüst bir çekince

SDD kötü tanımlanmış gereksinimleri çözmez; onları açığa çıkarır. İş birimi bir sistemin ne yapması gerektiğini açıkça tarif edemiyorsa hiçbir yapay zekâ ajanı bu boşluğu dolduramaz. Spesifikasyon kalitesi kritik darboğaz hâline gelir. Bu, hem iş tarafında hem mühendislik tarafında geliştirilmesi gereken yeni bir yetkinliktir.

Ancak değişimin amacı da tam olarak budur. SDD düşünmeyi otomatikleştirmez; düşünce ile sonuç arasında duran her şeyi ortadan kaldırır.