Agile UX: Sprint Ritmi ile Araştırma Ritmi Neden Tutmaz
Agile UX çoğu yerde "hızlı tasarım" diye anlatılır. Hız olsa olsa yan üründür; asıl kazanç, yanlış kararı iki hafta içinde fark edebilmek. Bu ayrımı gözden kaçıran ekipler çevik süreci, aynı hataları daha sık tekrarlayan bir üretim bandına çeviriyor.
Vaat hız değil, geri dönüş süresi
Doğrusal süreçlerin sorunu yavaş olmaları değildi. Sorun, tasarımın doğru olup olmadığının aylar sonra, ürün canlıya çıktığında öğrenilmesiydi. Kısa döngü bu mesafeyi kapatır: küçük bir parçayı erken gösterir, yanıldığın yeri ucuza öğrenirsin.
Buradan çıkan doğal sonuç şu: iterasyon sayısını artırmak tek başına bir kazanç değil. Her döngüden sonuç çıkmıyorsa, iki haftada bir tekrarlanan şey öğrenme değil, sadece teslimat.
Araştırma sprintin içine sığmaz
Sık duyulan tavsiye, kullanıcı testini sprintin içine yerleştirmek. Takvimi açıp bakınca durum değişiyor. Beş katılımcılı moderatörlü bir test için gereken kaba süre:
- Katılımcı bulma ve randevulaşma: 3-5 iş günü
- Seanslar: 1-2 gün
- Notların derlenmesi ve bulguların yazılması: 1 gün
İki haftalık bir sprintte bu, takvimin yarısından fazlası demek. Geriye kalan sürede bulguyu tasarıma çevirip geliştirmeye verip kodlatıp gözden geçirtmek gerçekçi değil. Yani araştırma bulgusu, doğduğu sprintin değil bir sonrakinin işine yarar.
Bunu bir gecikme sayıp üzülmek yerine takvime yazmak daha doğru. Araştırma hattını tasarım hattından bir sprint önde çalıştır: bu sprintte test edilen şey, gelecek sprintin backlog maddesini besler. "Sürekli keşif" dediğimiz şey zaten budur, sprint içi anlık doğrulama değil.
"Küçük başla" tavsiyesinin sınırı
Ürünün ilk sürümünü dar tutmak iyi bir varsayılan. Ama her akış bölünebilir değil. Ödeme, kimlik doğrulama, yetkilendirme gibi akışlarda en küçük kullanışlı birim zaten büyüktür; yarısı çalışan bir ödeme akışını kullanıcının önüne koyamazsın.
Böyle yerlerde bölme ekseni özellik değil kapsam olmalı. Tek ödeme yöntemiyle, tek para birimiyle, tek ülkeye açarsın. Akış baştan sona çalışır, yüzeyi dardır. Özelliği ortasından ikiye bölmekle bunu karıştıran ekipler, sprint sonunda gösterilecek çalışan bir şey bulamıyor.
Seremoniler sürecin kendisi değil
Stand-up, review, retrospektif; hepsinin bir işlevi var, ama takvimin dolu olması çevik çalışmak anlamına gelmiyor. Ölçüt basit: retrospektifte çıkan maddenin backlog'a girip bir sonraki sprintte kapanıp kapanmadığına bak. Girmiyorsa o toplantı bir durum raporudur, iyileştirme mekanizması değil.
Aynı şey kabul kriterleri için de geçerli. "Bitti" tanımı ekip içinde yazılı değilse, sprint sonunda tasarımcının bittisi ile geliştiricinin bittisi farklı çıkar ve fark her seferinde review toplantısında keşfedilir.
Tasarım sistemi kararını neyle ölçmeli
Tasarım sistemi tavsiyesi çevik ekiplere neredeyse refleks olarak veriliyor, ama maliyeti bileşen sayısıyla ölçülmez. Doğru ölçü şu: bir bileşeni değiştirdiğinde kaç ekranın davranışı değişiyor ve bunu değişiklikten önce görebiliyor musun? Görebiliyorsan sistem sana hız kazandırır. Göremiyorsan, her düzeltmenin başka bir yeri bozduğu ortak bir bağımlılık yığını kurmuşsun demektir, ve bu yığın sprint ortasında sürpriz üretir.
Bileşen kullanımını dosyalar üzerinde arayıp listeleyecek bir betik yarım gününü alır, üçüncü parti bir araca gerek yok. O listeyi elinde tutmak, tasarım sistemi tartışmasını fikir düzeyinden çıkarıp sayıya bağlar.