Geliştirici deneyimini (DX) ölçmek ve iyileştirmek: yöntem ve araçlar

Geliştirici deneyimi ölçülmeye değer mi, neyi ölçer?

Geliştirici deneyimi (developer experience, DX), yazılımcıların kod yazarken, test ederken, inceleme alırken ve yayına çıkarken karşılaştığı sürtünmenin toplamıdır. Yavaş bir derleme hattı, belirsiz belgeler, bekleyen kod incelemeleri, kararsız test ortamları ve karmaşık yetkilendirme süreçleri bunun parçalarıdır. Bu sürtünme görünmezdir: kimse zaman kaybını faturaya yazmaz, ama teslim hızına ve ekip morali üzerinde ağır etkisi vardır.

Ölçmenin amacı kişileri değerlendirmek değil, sistemi iyileştirmektir. DX ölçümü, hangi engelin en çok zaman ve enerji tükettiğini gösterir ve iyileştirme yatırımını neye yapacağınıza karar vermenizi sağlar. Bireysel verimliliği ölçmek için kullanıldığında ise güveni zedeler, veriyi manipüle ettirir ve işe yaramaz hale gelir. Ölçümün hedefi hep ekip ve süreç düzeyinde kalmalıdır.

Hangi çerçeveler kullanılır? SPACE, DORA ve DevEx

Tek bir sayı geliştirici verimliliğini anlatmaz; bu yüzden çok boyutlu çerçeveler kullanılır. SPACE çerçevesi şu boyutları önerir: memnuniyet ve iyi oluş (satisfaction), performans, etkinlik (activity), iletişim ve iş birliği, verimlilik ve akış (efficiency). Çerçevenin fikri, tek bir boyuta (örneğin yalnızca etkinlik sayımlarına) bakmanın yanıltıcı olduğu ve boyutların birlikte okunması gerektiğidir.

DORA metrikleri ise yazılım teslim performansına odaklanır: dağıtım sıklığı, değişiklik için geçen süre, değişiklik başarısızlık oranı ve hizmeti geri getirme süresi. DevEx çerçevesi ise geliştiricinin deneyimini geri bildirim döngüleri, bilişsel yük ve akış hâli üzerinden ele alır. Bu çerçeveler birbirinin alternatifi değil tamamlayıcısıdır: DORA teslim sonucunu, SPACE ve DevEx ise geliştiricinin yaşadığı deneyimi öne çıkarır. Hangi çerçeveyi seçeceğiniz, yanıt aradığınız soruya bağlıdır.

Algı verisi: DX anketi nasıl tasarlanır?

Anket, geliştiricinin yaşadığı zorlukları sistem verisinin yakalayamadığı yerden gösterir. Etkili bir DX anketinin özellikleri şunlardır:

• Kısa tutulur ve düzenli aralıklarla tekrarlanır, böylece zaman içinde trend görülür
• Sorular somut deneyime iner: "kod incelemesi beklerken ne kadar zaman kaybediyorsunuz" gibi, "memnun musunuz" yerine
• Aynı ölçek sürekli kullanılır ki sonuçlar karşılaştırılabilsin
• Yanıtlar gizlilik güvencesiyle toplanır ve ekip düzeyinde raporlanır
• Açık uçlu bir soru, sayıların açıklayamadığı nedenleri yakalar

Anket sonuçlarının ardından eylem görülmezse katılım düşer; bu nedenle sonuçları paylaşmak ve alınan aksiyonu duyurmak anketin en önemli parçasıdır. Anket tek başına yeterli değildir, çünkü algı ile gerçek her zaman örtüşmez. Bu yüzden sistem verisiyle birlikte okunur.

Sistem verisiyle üçgenleme ve sürtünme analizi

Sistem verisi, algıyı doğrular ya da sorgulatır. Kaynaklar: sürekli entegrasyon hattının süreleri ve başarısızlık oranları, kod incelemesi bekleme süreleri, derleme ve test süreleri, ortam hazırlama süresi, değişikliğin yayına çıkma süresi, yeniden çalıştırılan hatlar. Üçgenleme, aynı soruyu birden fazla kaynaktan sınamaktır: anketten "derleme çok yavaş" yanıtı geldiyse derleme sürelerine bakarsınız. Veri uyuşuyorsa sorunun gerçek ve önceliklendirilebilir olduğunu anlarsınız; uyuşmuyorsa algının nedenini araştırırsınız.

Sürtünme analizi, geliştiricinin bir işi yapmak için attığı adımları çıkarıp hangisinde bekleme ya da tekrar olduğunu bulur. Örneğin yeni bir hizmet açmak için gereken izinler, test ortamı talebi ve belge arama süreci adım adım yazıldığında hangi halkanın darboğaz olduğu görünür. Bu analiz genellikle birkaç geliştirici ile yapılan görüşmelerle desteklenir.

İyileştirme portföyü nasıl oluşturulur?

Ölçümden çıkan sorunlar bir iyileştirme listesine dönüşür. Her madde için etkilenen geliştirici sayısı, kaybedilen zaman, çözüm maliyeti ve belirsizlik değerlendirilir. Büyük etkili ve düşük maliyetli işler öne çıkar. Bir portföy anlayışı gerekir: bazı maddeler hızlı kazanım (bir bekleme süresini kısaltmak), bazıları orta vadeli (test ortamı otomasyonu), bazıları uzun vadelidir (mimari ayrışma).

Her iyileştirme için ölçülebilir bir başarı ölçütü tanımlanır: derleme süresi, bekleme süresi ya da anket puanı. Böylece yapılan işin işe yarayıp yaramadığı görülür. Bir iyileştirme sonrası ölçüm yapmak yatırımı doğrular ya da yön değiştirmenizi sağlar. Ayrıca iyileştirmeleri bir platform ya da geliştirici deneyimi ekibine ve yol haritasına bağlamak, tek seferlik kampanya olmaktan çıkarıp sürdürülebilir hale getirir.

Yatırımı yönetime nasıl gerekçelendirirsiniz?

Yönetim, DX iyileştirmesini bir maliyet olarak görebilir. Gerekçelendirme için etkiyi iş diline çevirirsiniz: iyileştirmenin geliştirici başına kazandırdığı zaman, teslim hızına etkisi, hata ve olay sayısındaki azalma, işe alım ve ekipte kalma üzerindeki etki. Kazanılan zamanı parayla çarpmak cazip ama tehlikelidir; kazanılan dakikalar otomatik olarak üretkenliğe dönüşmez. Bu yüzden zaman kazancını, teslim süresi ve kalite göstergeleriyle birlikte sunmak daha inandırıcıdır.

İyi bir gerekçe, mevcut durumu ölçülmüş veriyle gösterir, önerilen iyileştirmenin maliyetini ve beklenen etkisini yazar, ölçüm planını açıklar. Küçük bir pilotla başlayıp sonuçları paylaşmak büyük yatırım onayı almayı kolaylaştırır. Beklentiyi abartmamak ve belirsizliği açıkça söylemek güvenilirliği artırır.

Sık yapılan hatalar

En yaygın hata, satır sayısı, işleme sayısı ya da PR sayısı gibi etkinlik sayımlarını verimlilik göstergesi saymaktır. Bu sayılar kolay manipüle edilir ve kaliteyi anlatmaz. Başka bir hata, bireysel geliştirici sıralaması yapmaktır; güveni bitirir ve veriyi bozar. Diğer hatalar: yalnızca anketle ya da yalnızca sistem verisiyle yetinmek, sonuçları paylaşmayıp aksiyon almamak, tek seferlik ölçümle yetinmek ve iyileştirmenin etkisini sonradan ölçmemek.

Bir başka hata, ölçümü başlatan ekibin kendi sorunlarını görmemesidir. Platform ekibi sürtünmeyi azalttığını düşünürken geliştiriciler yeni araçları ek yük olarak görüyor olabilir. Bu yüzden iyileştirmelerin kullanıcıları olan geliştiricilerin sürece katılımı baştan sağlanmalıdır.

Bu beceri Mindset programlarında nerede çalışılır?

Mindset'in Geliştirici Deneyimi (Developer Experience) Ölçümü ve İyileştirme eğitimi, mühendislik yöneticilerine, platform ve geliştirici deneyimi ekiplerine ve teknik liderlere yöneliktir. Müfredat geliştirici deneyimi çerçeveleri ve ölçüm boyutları, anket tasarımı ve algı verisinin toplanması, sistem verisiyle üçgenleme ve sürtünme analizi ile iyileştirme portföyü ve yatırımın gerekçelendirilmesi modüllerinden oluşur.

Kurumsal mühendislik organizasyonları için bu yapı, ölçümün bir kez yapılan bir proje yerine düzenli yürüyen bir pratik olmasına ve iyileştirme önceliklerinin ortak verilerle belirlenmesine zemin hazırlar.