Kullanıcı Hikayeleri: Kart Değil, Kartın Ardındaki Konuşma

Kullanıcı hikayesi, bir gereksinimi tek cümlede toplayan not: kim, ne istiyor, neden istiyor. Formatı öğrenmek on dakika sürer. Zor olan, o cümlenin arkasındaki konuşmayı yapmaktır ve çoğu ekip kartı yazıp konuşmayı atlar. Geriye kısaltılmış bir şartname kalır.

Format bir şartname değil, hatırlatmadır

Yaygın kalıp şu: “Bir e-ticaret müşterisi olarak sepetimi görmek istiyorum ki alacaklarımı satın almadan önce kontrol edebileyim.” Üç parça var: rol, istenen şey, gerekçe. İlk ikisi zaten her gereksinim listesinde bulunur. Yeni olan üçüncüsüdür.

Gerekçe cümlesi çözümü sabitlemediği için işe yarar. Sepet sayfası istendiğini bilen geliştirici sepet sayfası yapar. Amacın “satın almadan önce kontrol” olduğunu bilen geliştirici, ödeme ekranının üstüne konan bir özet kutusunun aynı işi daha ucuza gördüğünü söyleyebilir. Kartın değeri burada, cümlenin güzelliğinde değil.

Ron Jeffries'in üç C'si (kart, konuşma, teyit) bu yüzden hâlâ anlatılıyor. Kart, bir konuşma sözüdür. Konuşma yapılmazsa elde kalan metin uzun şartnameden daha kötüdür, çünkü eksik olduğu belli olmaz.

Kabul kriteri olmayan hikaye tahmin edilemez

“Sepeti gör” bir günlük iş de olabilir, bir haftalık iş de. Farkı, kimsenin sormadığı ayrıntılar yaratır. Aynı hikayenin kabul kriterleri şöyle görünür:

• Sepette ürün yokken sayfa boş sepet mesajı gösterir.
• Adet değiştirildiğinde ara toplam sayfa yenilenmeden güncellenir.
• Stoğu tükenen ürün sepette kalır, satın alma düğmesi kapanır.

Üçüncü madde yazılmadan önce kimse stok durumunu düşünmemişti. Kabul kriteri, hikayeyi test edilebilir yapmadan önce onu anlaşılır yapar. Kriteri yazmak zorlaşıyorsa hikaye ya çok büyüktür ya da henüz kimse ne istendiğini bilmiyordur.

Sırayı Scrum Master belirlemez

Sıkça tekrarlanan bir hata: backlog'daki hikayelerin önceliğini Scrum Master'ın belirlediği söylenir. Scrum Guide'da bu sorumluluk Product Owner'a aittir. Scrum Master süreci ve ekibin etkinliğini üstlenir, işin sırasını değil.

Ayrım biçimsel görünür, sonucu somuttur. Sırayı belirleyen kişi, müşteriyle konuşan ve ürünün değerinden hesap veren kişi olmalı. Bu rol süreç kolaylaştırıcısına kaydığında öncelik ölçütü sessizce değişir: iş değeri yerine ekibin akışını bozmayan iş öne geçer. Backlog o noktada bir ihtiyaç listesi olmaktan çıkar, üretim çizelgesine döner.

Formatın taşıyamadığı gereksinimler

Performans, güvenlik, erişilebilirlik. “Bir kullanıcı olarak sayfanın iki saniyede açılmasını istiyorum” yazıldığı anda, sistemin tamamını ilgilendiren bir kısıt tek bir karta indirgenmiş olur. Kart sıraya girer, özelliklerle yarışır ve genellikle kaybeder. Hiçbir planlama toplantısında “bu hafta yavaşlığı düzeltelim” demek, yeni bir ekran eklemek kadar cazip gelmez.

Bu gereksinimlerin yeri tamamlanma tanımı ya da ayrı bir kısıt listesidir. Kısıt bir kez yazılır, her hikaye onu sağlamak zorunda kalır. Hikaye formatına zorlanan mimari gereksinim ise çoğu ekipte projenin sonuna ertelenen madde olur.

Tahmin ile esneklik aynı anda vaat edilemez

Kullanıcı hikayelerinin iki faydası genellikle yan yana sayılır: iş küçük parçalara bölündüğü için maliyet ve süre öngörülebilir hale gelir, gereksinimler süreç içinde değişebilir. Bu ikisi aynı anda tam olarak doğru olamaz. Toplam maliyet tahmini backlog'un kabaca sabit kaldığını varsayar, değişime açıklık ise tersini söyler.

Gerçekte elde edilen şey kısa menzilli öngörülebilirliktir. Son birkaç sprint'te ne bitirdiğine bakan bir ekip, önümüzdeki sprint'te ne bitireceğini makul doğrulukla söyler. Aynı sayıyla dokuz ay sonrasını hesaplamak, hem hızın sabit kalacağını hem de kapsamın büyümeyeceğini varsaymak demektir. Uzun süren hiçbir projede ikisi birden tutmaz.

Bir tarih vermek gerekiyorsa daha dürüst yol, tahmini kapsamdan türetmek yerine kapsamı tarihten türetmektir. Süre sabitlenir, hangi hikayelerin o süreye sığdığı sırayla belirlenir. Kullanıcı hikayeleri bu işi kolaylaştırır, çünkü sıralanabilir büyüklükte parçalar üretirler. Yaptıkları katkı budur, geleceği bilmek değil.