Agile ve UX Entegrasyonu: Ritim Farkı ve Kapatma Yolları
Agile ile UX'in birlikte yürümediği şikâyeti neredeyse hep aynı yerden çıkıyor: iki işin doğal ritmi aynı değil. Sprint iki hafta sürer; bir araştırma turu katılımcı bulmayla birlikte üç haftayı rahat bulur. Sorun metodoloji seçimi değil, bu farkı yok sayan planlama.
Ritim farkı nereden geliyor
Agile Manifesto 2001'de on yedi kişi tarafından yazıldı ve bu on yedi kişinin tamamı yazılım geliştirme ile süreç tarafından geliyordu. Aralarında tasarımcı yoktu, araştırmacı da yoktu. Metinde geçen kelime kullanıcı değil, müşteri.
Bu bir kusur değil, bir kapsam tercihi. Ama sonucu şu: manifestonun tarif ettiği geri bildirim döngüsü, işi ısmarlayan taraftan gelen geri bildirim üzerine kurulu. Ürünü kullanan kişiden gelen geri bildirimin döngünün neresine gireceği yazılı değil. Ekipler bu boşluğu kendi yöntemleriyle dolduruyor ve çoğunlukla araştırmayı sprintin içine sıkıştırmaya çalışarak dolduruyor.
Araştırma takvimi sprint takvimine sığmaz
Bir kullanıcı testi turunu adım adım açalım. Doğru profilden beş katılımcı bulmak, hazır bir panelin yoksa birkaç gün sürer; kurumsal bir üründe müşteri tarafındaki kişilere ulaşmak bazen bir haftayı bulur. Görüşmeler iki üç güne yayılır, çünkü katılımcıların takvimi senin sprintine göre şekillenmiyor. Notların çözümlenmesi ve bulguların ekibe anlatılabilir hale gelmesi bir gün daha.
Toplam iki haftalık sprinte sığmaz. Sığdığı durumlarda da yapılan şey araştırma değil, aceleye getirilmiş bir ankettir.
Çıkış yolu araştırmayı hızlandırmak değil, sprint sınırından çıkarmak. Araştırma kendi takviminde yürür, çıktısı mevcut sprinte değil backlog'a düşer. Ekip bu hafta ne kodlayacağını üç hafta önceki araştırmanın bulgusuyla belirler; bugün başlayan araştırmanın bulgusu da üç hafta sonrasını belirler. Böyle kurulduğunda sprint sınırı araştırmanın düşmanı olmaktan çıkar, sadece bulgunun sıraya girdiği yer olur.
Bir sprint önde çalışmanın gizli maliyeti
Tasarımın geliştirmeden bir sprint önde gitmesi, yani dual-track düzeni, bu sorunun standart cevabı. İşe yarıyor, ama bedeli konuşulmuyor.
Şöyle işliyor: tasarım beşinci sprintte hazırlanır, altıncı sprintte koda girer. Tasarımın teknik olarak pahalı ya da imkânsız olduğu altıncı sprintte anlaşılır. Düzeltme yedinciye kalır, uygulaması sekizinciye. Bir tasarım kararının yanlış olduğunu öğrenme süresi, tasarımla geliştirmenin aynı anda ilerlediği bir düzene göre iki katına çıkar (dual-track'i bir çözümden çok bir takas olarak görüyorum).
Bunu kapatmanın yolu basit: tasarım henüz çizilirken bir geliştirici masada olsun. Backlog'a girdiğinde değil, karar alınırken. Yarım saatlik bir uygulanabilirlik konuşması, iki sprintlik geri dönüşü baştan siler.
Tasarım kararının kodda karşılığı
Planlama toplantısında tasarımcının sözünün ağırlığı, çoğunlukla önerdiği değişikliğin maliyetini bilip bilmemesine bağlı. Bu maliyet görsel karmaşıklıkla orantılı değil.
Bir formdaki alanların sırasını değiştirmek ucuz. Aynı formu iki adıma bölmek ucuz değil: ara durumun bir yerde tutulması, yarım kalan kaydın temizlenmesi, tarayıcının geri tuşunun ne yapacağı, iki adım arasında oturumun düşmesi. Ekranda iki kutu görünür, arkasında yeni bir durum makinesi vardır.
Renk, boşluk, tipografi ve metin değişiklikleri genelde ucuz taraftadır. Veri modeline, doğrulama kurallarına ya da adım sayısına dokunan her şey pahalı taraftadır. Bu ayrımı yapabilen tasarımcı planlama toplantısında "bunu yapamayız" cevabını çok daha az duyar, çünkü teklifini zaten sınırın doğru tarafından getirmiştir.
Yönetim desteğinin somut karşılığı
Yönetim UX'in değerini anlamalı cümlesi tek başına bir şey söylemiyor. Anlayıp anlamadığının ölçülebilir üç göstergesi var.
Birincisi kullanıcıya erişim: araştırmacı, satış ya da müşteri ilişkileri tarafından izin dilenmeden gerçek kullanıcıyla görüşebiliyor mu. İkincisi katılımcı bütçesi. Küçük bir hediye kartı bütçesi bile olmayan ekip eline kim geçerse onunla test eder, yanlış profille test etmek ise hiç test etmemekten daha kötü sonuç verir; ortaya çıkan bulgu yanlış olduğu halde ekibe güven duygusu yaşatır. Üçüncüsü ve en belirleyicisi: araştırma bulgusu yol haritasını değiştirebiliyor mu. Bulgu rapor olarak arşivleniyor ve yol haritası aynı kalıyorsa, o araştırma bir tören.
Scrum mu, Kanban mı
Bu soruya ekibe göre değişir demek kolay ama işe yaramıyor. Ayrım daha net çizilebilir.
Kapsamı bilinen, ağırlıkla uygulama işi olan bir dönemde sprint disiplini işe yarar: sabit sınır, tahmin edilebilir teslim, düzenli demo. Keşif aşamasındaki bir üründe, yani hangi problemi çözdüğün henüz netleşmemişken, iki haftalık sınır zarar verir. Bulgu geldiğinde yön değiştirmek gerekir, sprint taahhüdü ise tam olarak bunu engellemek için vardır. Orada Kanban daha dürüst bir seçim.
Çoğu ürün ikisi arasında gidip geliyor. Aynı ekip keşif dönemine girdiğinde akışa, teslim dönemine girdiğinde sprintlere geçebilir. Süreci ürünün evresine göre değiştirmek, tek bir yöntemi yıllarca taşımaktan daha az maliyetli.