Yazılım yazma hızındaki büyük artış, geliştirme ekiplerinin karşı karşıya olduğu tek zorluk olmaktan çıktı. Cursor gibi araçların geliştirme ortamında kod önerileri sunmaktan, spesifikasyonlar ve görevlerden yola çıkarak tüm görevleri gerçekleştirmeye geçmesiyle sorun; kurumun neyin inşa edilmeye değer olduğunu belirleme, bunu test etme, güvenli biçimde dağıtma, ardından çalıştırma ve bakımını yapma kapasitesinde ortaya çıkabilir.
Hannah Foxwell’in «Geliştirme Ekibini Yeniden İcat Etmek» başlıklı sunumunun odağında da bu konu yer alıyor. Sunum, ajanların kendi yeteneklerinden çok vekil programlamanın insanlar ve süreçler üzerindeki etkisine odaklanıyor. Foxwell, araçlar ne kadar hızlanırsa hızlansın önemini koruyacağını düşündüğü görüşünü üç temel üzerine kuruyor.
Hız eksikliğinden kapasite fazlasına
Foxwell, yazılımı yılda iki kez yayımlayan ekiplerle başlayan ve Agile, bulut bilişim, DevOps ve sürekli teslimat aracılığıyla günde birden çok dağıtıma ulaşan bir süreci anlatıyor. Uzak bir hedef olarak sunulan yüksek hızın, kurumların henüz nasıl değerlendireceklerini bilmediği bir gerçeğe dönüşmeye başladığını düşünüyor.
Vekil programlama modelinde ajanlar spesifikasyonları parçalara ayırabilir, kod ve testler yazabilir, ardından dağıtım ve izlemeye yardımcı olabilir. Ancak bu kapasite, ürün yönetimi üzerinde ters yönlü bir baskı yaratabilir: Geliştirme ekipleri, kurumun açık ve nitelikli gereksinimler sağlama kapasitesinden daha hızlı çalışabilir. Bu nedenle Foxwell, çözümün her fikri veya talebi kabul etmek olduğunu düşünmüyor; çünkü bu, şişkin ve odağı zayıf ürünlere yol açabilir.
Birinci temel: İnşa edilmeye değer olanı yapmak
Foxwell, kodun amaç değil, kullanıcı için gerçek bir sorunu çözmeye yarayan bir araç olduğunu vurguluyor. Fikirleri test etmenin maliyeti düştükçe, bunları ürün içinde uzun vadeli bir taahhüde dönüştürmeden önce prototipler oluşturup kullanıcılarla denemek daha iyi hale geliyor.
Makalenin ortaya koyduğu modeller arasında, fikir ile test arasındaki mesafeyi kısaltmak için «prototip programlayan ürün yöneticisi» ya da fikir hızlı prototipleme kapasitesini aştığında ürün yöneticisini bir geliştiriciyle eşleştirme yer alıyor. Ayrıca müşteriye yakın çalışan ve müşterinin sorunlarını çözme yetkisine sahip olan saha mühendisinin rolüne ve ürünü kullandığı ya da kullanıcılarına yakın olduğu için ürünün şekillendirilmesine katılan «ürün mühendisi»ne değiniyor.
Foxwell, ekiplerin büyüklüğünü ve bileşimini yeniden değerlendirmeye yönelik denemeleri de ele alıyor. Altı ila sekiz geliştirici ve bir ürün yöneticisinden oluşan ekip modeli yerine bazı kurumlar daha küçük ekipleri test ederken, Andrew Ng tek bir geliştiricinin ajanlardan oluşan bir filoyu koordine edebildiği, iki ürün yöneticisinden bir geliştiriciye uzanan ters bir model önerdi. Bu modeller sabit kurallar olarak sunulmuyor; darboğaz noktasının geliştirme kapasitesinden gereksinimlerin netliğine ve kararların hızına kaymasını yansıtan deneyler olarak ele alınıyor.
Buna karşılık makale, özelliği yayımladıktan sonra kullanımını incelemeden hemen başka bir göreve geçmek, her müşteri talebini kabul etmek ya da en yüksek maaşı alan yöneticinin görüşünü öncelik ölçütü olarak benimsemek gibi uygulamalara karşı uyarıyor. Yazılım yazmanın hızlandığı bir ortamda kullanıcı araştırması, kullanıcı deneyimi ve değeri doğrulama kapasitesi, uygulama hızının kendisinden daha önemli ayırt edici unsurlar haline gelebilir.
İkinci temel: Hız güvenliğe ihtiyaç duyar
Değişiklik hacmindeki artışın buna ayak uydurabilecek bir üretim hattına ihtiyacı var. Foxwell, test kapsamındaki boşlukların ve manuel adımların dağıtım hattını darboğaz noktasına dönüştürebileceği, böylece değişikliklerin kullanıcılara ulaşmadan önce birikebileceği uyarısında bulunuyor.
Bu nedenle makale, hızı otomatik testlerle ilişkilendiriyor ve ajanların sürekli testler oluşturmak, ekiplerin teknik borçla başa çıkmasına, eski platformlardan geçiş yapmasına ve kod tabanlarını yeniden yapılandırmasına yardımcı olmak için kullanılmasına ilişkin örneklere yer veriyor. Amaç, yavaş bir sürecin üzerine yapay zekâ eklemek değil; yeni değişim hızını kaldırabilmesi için üretime giden yolu yeniden tasarlamak.
Foxwell, güvenilirlik ve güvenliğin hız karşılığında kabul edilebilir ödünler olmadığını vurguluyor. Başarı göstergeleri, hizmet seviyesi hedefleri ve hata bütçelerine dayanılmasını; kabul edilebilir başarısızlık seviyesi aşıldığında kurumun ne yapacağını belirleyen yazılı bir politika oluşturulmasını öneriyor. Bu, sürümleri yavaşlatmayı veya kaynakları güvenilirlik ve dayanıklılığa yönlendirmeyi içerebilir.
Ayrıca kademeli dağıtım, özellik bayrakları, A/B testleri ve mavi-yeşil dağıtımın, çok sayıdaki değişikliği tüm kullanıcıları aynı anda bunlara maruz bırakmadan yönetmeye yardımcı olduğunu düşünüyor. Site güvenilirliği mühendisliği ekiplerinin ve iç platformların rolünü de yeniden değerlendiriyor; bunları geliştirme ekiplerine güvenli ve hazırlanmış bir yol sağlayan danışmanlık ve yetkilendirme işlevleri olarak görüyor.
Pratikte ne değişiyor?
Sunumdan çıkarılan editoryal sonuç, ajanların tek başına geliştirme ekiplerinin küçüleceğini veya işlerin ortadan kalkacağını kanıtlamadığı yönünde. Kesin olan, darboğaz noktalarının yer değiştireceği: kod üretiminden sorunları seçmeye, değeri doğrulamaya, testleri genişletmeye, güvenilirliği kontrol etmeye ve hızlı kararlar almaya.
Açık soru ise kurumların yeni kapasiteyi daha iyi ürünler geliştirmek ve fikirlerini test etmek için mi kullanacağı, yoksa buna daha fazla özellik yığarak mı karşılık vereceği. Geliştiriciler, ürün yöneticileri, platform ekipleri ve güvenilirlik ekipleri arasındaki yeni oranlar da hâlâ deney niteliğinde; kanıtlanmış sonuçlar değil. Bu nedenle vekil programlamayı benimsemek, etkisini yalnızca satır sayısı veya sürüm hızlarıyla sınırlı kalmadan ürün kalitesi, olaylar ve kullanıcı deneyimi üzerindeki etkisiyle ölçmeyi gerektiriyor.