Kullanıcı Hikayeleri: Şablonun İşe Yarayan Kısmı ve Sınırları
Kullanıcı hikayesi, bir gereksinimi kullanıcının ağzından tek cümleyle söyleme biçimidir. Şablon üç parçadan oluşur ama ekiplerin çoğu ilk ikisini yazıp üçüncüsünü geçiştirir. Asıl iş o üçüncü parçada, geri kalanı görev listesinden ibaret.
Şablonun işe yarayan kısmı
Kalıp bilinir: "Bir rol olarak şunu yapmak istiyorum, böylece şu olsun." Rol, istek, fayda. Fayda cümlesi "böylece işim kolaylaşsın" gibi bir doldurmaya dönüştüğü anda hikaye ölür; elde kalan şey, kullanıcı kılığına sokulmuş bir iş emridir.
Fayda kısmı aynı zamanda tek testtir. "Böylece parolamı hatırlamak zorunda kalmam" cümlesini kurabiliyorsan istek gerçektir. Kuramıyorsan, büyük ihtimalle toplantıda birinin aklına gelen bir özelliği hikaye formatına giydirmişsindir. Bu ayrımı yapmak beş saniye sürer ve sprintin üçte birini kurtarır.
Her gereksinim hikayeye sığmaz
Kullanıcı hikayesi, kullanıcının fark ettiği davranışları tarif etmekte iyidir. Fark etmediklerini tarif etmekte kötüdür. "Loglar 90 gün saklanır", "TLS 1.2 altındaki bağlantılar reddedilir", "yedek günlük alınır" maddelerinin bir rolü yoktur. Bunları "Bir sistem yöneticisi olarak..." diye zorlamak sahte bir persona uydurmaktan başka bir şeye yaramaz, üstelik gerçek personaların listesini de kirletir.
Bu tür kısıtların yeri hikayelerin içi değil, kabul kriterleri ve ekibin ortak "definition of done" listesidir. Bir kere yazılır, her hikaye için geçerli olur.
Bölerken katmanı değil dilimi böl
Bir sprinte sığmayan hikaye epiktir, bölünmesi gerekir. Yaygın hata yatay bölmektir: "veritabanı tablosu", "API ucu", "arayüz". Üçü birden bitmeden kullanıcıya hiçbir şey teslim edilmez, dolayısıyla üçü bitmeden hiçbir geri bildirim de gelmez. İteratif görünen, aslında sadece parçalara ayrılmış bir şelale.
Doğru bölme dikeydir: aynı işin dar bir halini baştan sona çalışır biçimde teslim etmek. Önce tek dosya yükleme, sonra çoklu yükleme, sonra sürükle bırak. Her adım tek başına kullanılabilir, her adımdan sonra fikir değiştirebilirsin.
Kabul kriteri hikayenin sözleşmesidir
Bill Wake'in 2003'te önerdiği INVEST kısaltması (bağımsız, tartışılabilir, değerli, tahmin edilebilir, küçük, test edilebilir) hâlâ en pratik kontrol listesi. Pratikte ilk ve son harf yeter: hikaye başka bir hikayenin bitmesini beklemiyorsa ve nasıl test edileceği yazılıysa, kalan dört madde kendiliğinden düzelir.
Kabul kriterlerini hikayeyi yazan kişi değil, hikayeyi test edecek kişi yazsın (bu küçük değişiklik "bitti mi bitmedi mi" tartışmalarının yarısını buharlaştırıyor).
Hikayeler toplantı odasından çıkmaz
Ekibin kendi aklından ürettiği hikaye, ekibin kendi alışkanlıklarını koda çevirir. Destek kayıtları, site içi arama sorguları, terk edilen form adımları ve on beş dakikalık kullanıcı görüşmeleri aynı işi tahminden çok daha ucuza yapar.
Müzik sitesi örneği bunu iyi gösterir. Kendi dinleme alışkanlığınıza bakarak yazdığınız hikaye, besteciyle dinleyicinin aynı kişi olduğunu varsayar. Değiller: biri parçasını yüklemek ve kime ulaştığını görmek ister, diğeri aradığını üç tıkta bulmak. Aynı ekranı ikisine birden yazmaya çalıştığınızda ortaya kimseye uymayan bir şey çıkar.