Agile Ekiplerde UX Entegrasyonu Gerçekte Nasıl Yürür?
Agile ekiplerde UX'in yerine dair standart bir cevap var: tasarım bir sprint önden gitsin, geliştirme hazır tasarımı alsın. Toplantıda kulağa düzenli geliyor. Pratikte kurduğu şey, iki haftalık dilimlere bölünmüş küçük bir şelale.
Bir sprint önden gitmek neyi kırıyor
Önden giden tasarım, geliştirme başlamadan kararları dondurur. Sprint 12'de yazılan kod, sprint 11'de verilmiş bir kararı uygular. O kararın dayandığı varsayım yanlış çıkarsa geri dönüş maliyeti bir sprint değil iki olur, üstelik tasarımcı o sırada sprint 13'ün işine geçmiştir ve geri gelmek ikinci bir kesinti demektir.
Araştırmayı genelde sprint'e paralel yürütürüm, tasarımı bir sprint önden göndermeyi değil. Geliştirme devam ederken görüşmeler yapılır, bulgu aynı sprint içinde ekranı yapan kişiye döner. Önden gitmesi gereken tek şey, tasarım kararı değil, o kararın dayanacağı bilgi.
Kullanıcı testi sprint takvimine sığmıyor
"Her sprint kullanıcı testi yapın" tavsiyesi aritmetiğe takılıyor. Doğru profilde katılımcı bulmak, seansları yapmak, bulguyu yazıp ekibe anlatmak iki haftalık bir dilime rahatça sığmaz. Sığdırmaya çalışınca test, koridorda üç meslektaşa ekran göstermeye dönüşür ve elinizde araştırma değil, onay kalır.
İşe yarayan düzen şu: katılımcı havuzunu ve randevuları sprint'ten bağımsız, sürekli akan bir hat olarak kurun. Haftada iki sabit görüşme saati ayrılmışsa, o hafta neyi soracağınıza sprint'in içeriğine göre karar verirsiniz. Araştırmayı sprint'e sığdırmak yerine sprint'i akan araştırmanın üstünden geçirmiş olursunuz.
Tasarımcı planlama toplantısında olmalı
"İşbirliği kültürü kurun" cümlesi tek başına hiçbir şeyi değiştirmiyor. Değiştiren somut şey, tahminlerin verildiği odada tasarımcının bulunması. Bir ekranın "üç puan" mı "sekiz puan" mı olduğu, çoğu zaman tasarımın atladığı bir durumdan kaynaklanır: boş liste hali, hata mesajı, yarım kalan form. Tasarımcı odadaysa bu durumlar tahminden önce konuşulur, değilse sprint ortasında geliştirici kendi kararını verir ve arayüz oradan bozulur.
Prototipin kodda karşılığı var mı
Prototipte iki tıkla gelen ekran, veriyi tek bir istekte alabiliyorsa ucuzdur. Aynı ekran üç ayrı servisten veri topluyorsa, kullanıcı için görünen tasarım kararı arkada bekleme süresi olarak geri gelir. Tasarım tarafında sorulacak soru basit: bu ekranın gösterdiği her alan şu anda bir yerden geliyor mu, gelmiyorsa kim üretecek?
Bu soruyu sprint planlamasında sormak bir dakika sürer. Sormadan geçilirse cevabı, ekran yavaş açıldığı için kullanıcı testinde ortaya çıkar ve o noktada düzeltmesi çok daha pahalıdır.
Neyi ölçtüğünüzü söyleyebiliyor musunuz
Çevik ekipler için sıralanan faydalar genelde şeffaflık, erken hata yakalama, sürekli iyileştirme diye geçer. Bunların hiçbiri kendiliğinden oluşmuyor. Sürekli iyileştirmenin ölçülebilir hali, sprint sonunda "şu adımda yarıda bırakma oranı şuydu, şu oldu" diyebilmek. Bunu söyleyemeyen ekip iyileştirme yapmıyor, sadece değişiklik yapıyor.
Ölçüyü sprint başında seçin, sonunda değil. Hangi ekranda hangi olayın sayılacağı tasarım kararıyla birlikte konuşulursa geliştirici olayı ilk yazışta yerleştirir. Sonradan eklenen ölçüm, ayrı bir iş kalemi olarak birikir ve genelde hiç yapılmaz.