Agile ve UCD Entegrasyonu: Sorun Zaman Değil, Sıra
Agile ile kullanıcı odaklı tasarımı aynı takvimde yürütmeye çalışan ekiplerin şikâyet listesi neredeyse hep aynı: teste vakit kalmıyor, geri bildirim geç geliyor, kararlar varsayımla alınıyor. Bu maddeler ayrı ayrı sorunmuş gibi sıralanır, her birine de ayrı bir çözüm yazılır. Oysa çoğu tek bir yapısal tercihten çıkıyor: araştırmayı, kodun yazıldığı sprint'in içine sıkıştırmak.
Şikâyet listesi tek bir yere işaret ediyor
Aritmetiği basit. İki haftalık bir sprint'te tasarım ilk günlerde çıkar, geliştirme ortalarda başlar, test ise ancak elde çalışan bir şey olduktan sonra, yani son günlerde yapılabilir. O noktada bulunan her problem zaten yazılmış koda aittir. Ekibin iki seçeneği kalır: sprint'i uzatmak ya da bulguyu backlog'a atmak.
Backlog'a atılan kullanıcı bulgusu bir dahaki önceliklendirmede yeni özelliklerle yarışır ve genelde kaybeder, çünkü yeni özelliğin bir sahibi vardır, bulgunun yoktur. "Sprint planlamasında test için zaman ayırın" tavsiyesi bu yüzden çoğu ekipte tutmuyor. Ayrılan sürenin uzunluğu değil, sıra yanlış.
Tasarım bir döngü önde yürür
Çalışan kurulum şu: tasarım ve araştırma, geliştirmenin bir sprint önünden gider. Sprint N'de ekip, sprint N-1'de test edilip düzeltilmiş bir akışı kodlar; tasarımcı aynı hafta sprint N+1'in işini kullanıcıyla dener. Desiree Sy'nin 2007'de Autodesk ekiplerinden aktardığı "cycle 0" düzeni tam olarak budur ve Agile-UCD yazınında hâlâ en sağlam reçete o.
Bedeli de var, saklamaya gerek yok. Tasarımcı sürekli iki sprint'i birden taşır: biri kodlanırken sorularını cevaplar, diğerini hazırlar. Bu, tasarım tarafının geliştirme tarafından daha az kişiyle daha çok bağlam yönetmesi demek. Kabul edilebilir tek koşulu, hazırlanan işin gerçekten test edilmiş olması. Test yoksa bu düzen sadece ekstra bir bekleme katmanı ekler, hiçbir şey iyileştirmez.
Beş kullanıcı, on günlük araştırma değil
Sprint hızında araştırma yapmanın yolu, çalışmayı küçültmekten geçiyor. Jakob Nielsen'in bilinen tespiti, bir kullanılabilirlik testinde beş kullanıcının sorunların büyük bölümünü ortaya çıkardığı yönünde. Pratikte bu, tıklanabilir bir prototip ve ekran paylaşımlı beş görüşme demek. Bir öğleden sonra biter.
Ekiplerin burada takıldığı yer genelde katılımcı bulmak oluyor. Kurumsal bir üründe gerçek kullanıcıya erişim haftalar sürebiliyor, o yüzden test her sprint yeniden kurulan bir iş olmaktan çıkarılmalı: sabit bir katılımcı havuzu, önceden alınmış izinler, takvimde duran bir saat. Kurulumu bir kez yapıp her sprint aynı saati kullanan ekipler test yapıyor, her seferinde sıfırdan organize etmeye çalışanlar yapmıyor.
Yarı zamanlı UX uzmanı, parça parça ürün demek
Bir UX uzmanının üç dört Agile ekibine bölünmesi, kaynak verimliliği gibi görünüp tam tersini üretiyor. Ekipler birbirinden habersiz ilerlediğinde ortaya çıkan şey, herkesin kâğıdın görünmeyen kısmına kendi parçasını çizdiği o eski oyuna benziyor: teker teker makul, birleşince tuhaf.
Bölünmenin görünmeyen maliyeti de var. Scrum Guide'ın iki haftalık sprint için verdiği üst sınırlar planlamada 4, review'da 2, retrospektifte 1,5 saat. Üç ekibe birden bakan bir kişi için bu, iki haftada 22,5 saat, yani neredeyse üç iş günü, sadece törenlerde geçer. Geriye kalan zamanın araştırma, sentez ve tasarım için bölüşülmesi gerekir. Ben iki ekibi üst sınır kabul ediyorum; üçüncüsü eklendiği anda uzman koordinatöre dönüşüyor ve kimse test yapmıyor.
Her sprint test edilmesi gerekmiyor
Bu tür yazılar genelde "kullanıcı geri bildirimi asla göz ardı edilmemeli" diye biter. Kulağa doğru gelir ama uygulanabilir değil ve uygulanmadığı için de ekipler tavsiyenin tamamını çöpe atar. Daha kullanışlısı, araştırma bütçesini kullanıcının geri dönemeyeceği yerlere yığmak.
Ödeme akışı, hesap silme, tek seferlik kurulum sihirbazı, veri aktarımı: buralarda kullanıcı yanlış anlarsa bedeli kendisi ödüyor ve çoğu zaman geri dönemiyor. Bir buton metnini değiştirmek, bir listeye sıralama eklemek ya da yerleşik bir kalıbı tekrar kullanmak ise teste değmiyor; canlıdaki davranış verisi zaten cevabı veriyor. Ekipler ayırt etmeyi öğrenmediği sürece araştırma ya her yere serpilip hiçbir yerde derinleşmiyor ya da tamamen bırakılıyor.
Kaynaklar