Agile Sprintlerinde Kullanıcı Araştırmasını Dilimlemek

Agile'da kullanıcı araştırmasının tıkandığı yer yöntem değil, takvim. Bir kullanılabilirlik testi iki haftaya sığmaz; sığmadığı için backlog'a girmez, girmeyen iş de yapılmaz. Çözüm araştırmayı hızlandırmak değil, sprint sınırına göre dilimlemek.

Araştırmayı sprinte sığdırmaya çalışmayın

Görüşme ve test çalışmaları doğası gereği birden fazla sprinte yayılır. Bunu kusur sayıp çalışmayı kısaltmak yerine işi teslim edilebilir dilimlere bölün: katılımcı bulma bir madde, oturumları yürütme ayrı bir madde, analiz ve bulgu paylaşımı üçüncüsü. Her dilimin sprint sonunda gösterilebilecek bir çıktısı olur, pano üstünde haftalarca açık duran tek bir dev madde kalmaz.

Sprint sonunda ekibe tek slaytlık bir özet yeter (uzun araştırma raporlarının okunduğuna pek tanık olmadım).

Az ve sürekli, çok ve seyrekten iyi çalışır

Bütçeniz on iki katılımcıysa iki seçeneğiniz var. Hepsini tek çalışmada harcarsınız ve altı ay sonra bir kez öğrenirsiniz. Ya da her sprintte iki kişiyle konuşursunuz: aynı on iki katılımcı, aynı maliyet, ama altı ayrı karar noktası. İkincisi ürün geliştirmede neredeyse her zaman daha çok değer üretir, çünkü yanlış yönde harcanan süre tek bir sprintle sınırlı kalır.

İstisnası şu: karşılaştırma ya da ölçüm hedefi olan çalışmalarda, örneğin iki akışın görev tamamlama oranını kıyaslarken, katılımcıları sprintlere bölmek veriyi kullanılamaz hale getirir. Arada arayüz değişirse iki grup aynı ürünü test etmemiş olur. Orada tek partide toplayın.

Bulgu backlog'a girmiyorsa çalışma bitmemiştir

Araştırmanın çıktısı rapor değil, backlog maddesidir. Analiz biter bitmez her bulguyu ya bir hata kaydına, ya bir iyileştirme maddesine, ya da "şimdilik yapmıyoruz" gerekçesine bağlayın. Üçüncüsü de geçerli bir sonuçtur, yeter ki yazılı olsun ve gerekçesi görünsün.

Sprint review bunun için en ucuz yer. Bulguyu orada anlatıp maddeyi aynı oturumda açarsanız, iki hafta sonra kimsenin hatırlamadığı bir dosya kalmaz geriye.

Çıktı değil sonuç sorun

Ekipler kolayca özellik üretmeye odaklanır, çünkü özellik sayılabilir. Bir sprintte kaç madde kapandığı panodan okunur, o maddelerin kullanıcı davranışında ne değiştirdiği okunmaz. Ölçmek istiyorsanız her araştırma turundan önce tek bir davranış metriği seçin ve turdan sonra aynı metriğe bakın. Metriği sonradan seçerseniz elinizde kalan şey ölçüm değil, açıklama olur.

Her sprint araştırma gerekmez

Sürekli araştırma, sürekli görüşme demek değil. Ekip eldeki bulguyu henüz uygulamadıysa yeni veri toplamak yalnızca kuyruğu şişirir. Ölçüt basit: önceki turun bulguları backlog'a geçtiyse yeni tur başlar, geçmediyse önce onlar bitirilir.