Agile Sprintlerde Kullanılabilirlik Nereye Sıkışıyor
Çevik ekiplerde kullanılabilirlik çalışması genelde ilk sprintlerde canlıdır, altıncı sprintte ortada yoktur. Sebep ekibin ilgisizliği değil, işin ritminin sprint ritmine oturmaması. Paralel izlek gibi standart çözümler bu uyumsuzluğu yönetir, ortadan kaldırmaz; nerede gecikme ürettiklerini bilerek kurmak gerekir.
Paralel izlek gecikmeyi yok etmez, öteler
Reçete tanıdık: tasarım ve araştırma bir sprint önde yürür. Sprint N'de kurgulanan akış, N+1'de kodlanır. Peki test tam olarak ne zaman yapılır? Çalışan arayüz N+1'in sonunda çıkıyorsa gözlem N+2'nin başına, düzeltme N+2'nin backlog'una düşer. İki haftalık sprintlerle bu, bir kullanıcının takıldığı an ile o yerin düzelmiş hâli arasında dört haftalık mesafe demek.
Mesafenin kendisi sorun değil. Sorun, planlamada hiç görünmemesi. Ekip "her sprintte test ediyoruz" der, sprint panosunda test kartı da vardır, ama bulguların hangi sprintte kapanacağı hiçbir yerde yazmaz. Yazmadığı için de kapanmaz.
Prototip üstünde test edilirse mesafe kısalır, çünkü gözlem kodlamadan önceye alınır. Kâğıt prototipin hâlâ ayakta kalmasının sebebi ucuzluğu değil, takvimde erken durabilmesi.
Testin gerçek maliyeti katılımcıda
"Her sprintte beş kullanıcı" tavsiyesi kâğıt üstünde makul görünür. İki haftalık sprintle yılda 26 tur eder, yani 130 katılımcı. Tüketici ürününde belki bulunur. Niş bir B2B üründe, kullanıcısı üç şehirde toplam iki yüz kişi olan bir panelde, bu sayı ikinci çeyrekte tükenir. Ekipler testi bu yüzden bırakır, ilkeyi benimsemedikleri için değil.
Peki sayıyı düşürsek ne kaybederiz? Üç kişiyle de en büyük engeller görünür, kaçırılan şey daha çok ince ayar bulguları olur. Tur sayısını korumak, tur başına kişi sayısını korumaktan daha değerli: seyrek ve kalabalık turlar, sık ve küçük turların yerini tutmuyor.
Aynı katılımcıyı üst üste çağırmak da bir seçenek, ama üçüncü turdan sonra o kişi artık ürünü öğrenmiş olur ve ilk kullanım sorunlarını göremez hale gelirsiniz. Havuzu bilerek ikiye ayırmak işe yarıyor: bir grup akış testleri için tekrar tekrar, bir grup yalnızca ilk temas için tek seferlik.
Bulgu geldi, faturası nereye çıkıyor
Kullanılabilirlik işini backlog'da ayrı bir kalem olarak açmam. Ayrı kalem, sprint sıkıştığında ilk kesilen kalemdir; işin kendisi kötü olduğu için değil, kesilmesi bir şeyi bozmuyor göründüğü için. Kullanılabilirlik ölçütü story'nin kabul kriterine yazılırsa, kesmek için story'nin tamamını ertelemek gerekir. Bu, kesme kararını görünür kılar.
Bulguları sprint planlamasına sokmadan önce uygulama maliyetine göre ayırmak da işi rahatlatır. "Buton metni yanlış anlaşılıyor" ile "kullanıcı bu adımda hangi hesapla işlem yaptığını bilmiyor" aynı listede yan yana durur, ama ikincisi çoğu zaman hesap bağlamını oturum boyunca taşımak demektir; yani uçtaki arayüzü değil, servisin döndürdüğü veriyi ilgilendirir. Birincisi aynı sprintte kapanır, ikincisi kapanmaz. İkisini ayırmadan panoya asmak, ekibin listeye olan güvenini eritiyor.
Küçük ekipte ne kalır
Üç kişilik bir ekipte ayrı araştırmacı yoktur, olması da gerekmez. Ayakta kalması gereken iki alışkanlık var: her sprintte en az bir kişinin gerçek bir kullanıcıyı iş yaparken izlemesi, ve gözlenen her engelin kimin tarafından, hangi sprintte kapatılacağının yazılması. Geri kalan her şey, atölyeler, haritalar, şablonlar, bu ikisi yokken süs kalıyor.
Ya ekip tamamen geliştiricilerden oluşuyorsa? O zaman izleme işini sırayla yapmak, dokümantasyondan daha çok işe yarar. Kendi yazdığı ekranda birinin takıldığını gören geliştirici, aynı bulguyu ikinci elden okuyan geliştiriciden çok daha hızlı davranıyor.
Bilgi projeyle birlikte bitmesin
Persona ve akış çalışmaları proje klasöründe kalırsa, ekip değiştiğinde sıfırlanır. Bunları ürünün değil kurumun belgesi saymak, yılda bir kez gözden geçirilen kısa bir dosyada tutmak yeterli. Uzun rehberler yazmayın; kimse okumuyor. On maddelik bir kullanım ilkesi listesi ve güncel tutulan bir kullanıcı profili, altmış sayfalık bir kullanılabilirlik kılavuzundan daha uzun yaşıyor.