Agile’da UX: Bir Sprint Önde Çalışmanın Gizli Maliyeti
Agile ekiplerde UX’in yerini tarif eden en yaygın reçete tek cümle: bir sprint önde çalış. Reçete işe yarıyor, çünkü araştırma ve tasarım iki haftalık kutuya kolay kolay sığmıyor. Az konuşulan tarafı ise şu: önde çalışan her hat, arkasındaki hattın öğrenme hızını kendi uzunluğu kadar geciktiriyor.
Önde çalışmak neyi çözüyor
Sprintin ilk günü tasarımı sıfırdan açmak, sprintin sonunda hem tasarımın hem geliştirmenin yarım kalması demek. Keşfi bir sprint öne almak bunu düzeltiyor: geliştirme sprinte girdiğinde akış, uç durumlar ve boş ekranlar çoktan konuşulmuş oluyor. Buraya kadar itiraz edecek bir yer yok.
Peki ya ölçüm? Tasarım N sprintinde yapılıyor, geliştirme N+1’de, gerçek kullanımdan gelen sayı N+2’de görünüyor. Karar ile kanıt arasında iki sprint var; iki haftalık ritimde bu bir ay eder. Ekip bir ay boyunca doğru olduğunu varsaydığı bir kararın üstüne üç karar daha koyuyor.
Kuyruk keşif tarafında birikiyor
İki hatlı çalışmanın klasik hastalığı, keşif hattının geliştirme hattından hızlı üretmesi. Tasarım deposu şişiyor, sprinte giren iş ise onaylandığı andan haftalar sonra kodlanıyor. O aralıkta ürün değişiyor, ekran değişiyor, bazen kullanıcı bile değişiyor. Rafta bekleyen tasarım tazeliğini kaybediyor ve kimse bunu bir maliyet olarak yazmıyor.
Basit bir kural işi düzeltiyor: keşif hattında bekleyen hazır tasarım miktarını bir sprintlik kapasiteyle sınırlayın. Kuyruk dolduğunda yeni keşif başlatmak yerine, geliştirmede olan işin yanında durun.
Hangi araştırma sprintin içinde kalmalı
Hepsini dışarı taşımak gereksiz. Prototip üstünde beş kişiyle yapılan doğrulama testi bir öğleden sonraya sığıyor ve sonucu aynı sprintte kullanılabiliyor; bunu sprintin içinde tutun. Alan çalışması, günlük tutma, uzun görüşme serileri ise sprint ritmine hiç oturmuyor, bunları ayrı bir takvimde yürütmek gerekiyor.
Aradaki fark şu: doğrulama araştırması elinizdeki karara bakar, keşif araştırması sonraki kararların ne olacağını belirler. Birincisini sprint dışına taşırsanız gecikme büyür, ikincisini sprint içine sıkıştırırsanız araştırma kırpılır.
Kararın uygulama maliyeti karar anında bilinmeli
Tasarımın koddaki karşılığı tahmin edilmeden backlog’a giren madde, tahmin değil temenni. “Kullanıcı bu listeyi sürükleyip sıralasın” cümlesi bir ekranda üç saatlik iş, başka bir ekranda sıralama alanının veritabanına eklenmesi ve mevcut kayıtların taşınması demek. Karar verilirken bir geliştiriciyi o yarım saate çağırmak, sonradan yapılacak üç toplantıyı siliyor (ucuzluk oranına bakınca en iyi takas bence bu).
Bu aynı zamanda rol tartışmasını da bitiriyor. Kimin hangi kararı verdiğini yazan bir belge çoğu ekipte duvarda kalıyor; kararı verenle bedelini ödeyeni aynı odada toplamak ise kendiliğinden işliyor.
Retroda sorulacak tek soru
Ekipler retroda hız konuşuyor, gecikmeyi konuşmuyor. Oysa takip edilmesi gereken sayı sprint hızı değil, bir kararın verildiği tarih ile o kararla ilgili ilk gerçek verinin geldiği tarih arasındaki mesafe. Bu mesafe uzadıkça ekip daha çok üretip daha az öğreniyor.
Ölçmesi de zor değil. Son sprintte alınmış üç tasarım kararını seçin, her biri için kanıtın ne zaman geldiğine bakın. Cevap “henüz gelmedi” ise bir sprint önde çalışmanın bedelini görmüşsünüz demektir.