Kullanıcı Hikâyesi Nasıl Yazılır (Örnekler ve Kabul Kriterleriyle)
Kullanıcı hikâyesi, bir özelliğin kullanıcının bakış açısından kısa bir tarifidir: "[kullanıcı türü] olarak, [hedef] yapmak istiyorum, böylece [neden]." Altına kabul kriterlerini yazarsınız: hikâyenin tamamlanmış sayılması için doğru olması gereken birkaç belirli koşul. Her hikâyeyi tek seferde inşa edip test edilebilecek kadar küçük tutun ve kriterleri herkesin kontrol edebileceği biçimde yazın.
Kullanıcı hikâyeleri, çevik yazılım ekipleri sayesinde yaygınlaştı, ama yapay zekâ uygulama oluşturucuyla tek başınıza inşa ederken de aynı derecede işe yarar. İyi bir hikâye, iyi bir istemdir.
Biçim
Bir kullanıcı hikâyesinin üç parçası vardır:
Olarak [kim], istiyorum [ne] böylece [neden].
- Kim, belirli bir kullanıcı türüdür: ilk kez gelen bir ziyaretçi, ödeme yapan bir üye, bir klinik resepsiyonisti, bir yönetici. "Kullanıcı" değil.
- Ne, kullanıcının kendi sözleriyle yapmak istediği şeydir. Ekranın nasıl çalıştığı değil.
- Neden, kullanıcının önemsediği sonuçtur. İnsanların atladığı, ama yanlış şeyi inşa etmenizi engelleyen kısım budur.
Örnek:
Spor salonu üyesi olarak, bir ders rezervasyonunu telefonumdan iptal edebilmek istiyorum böylece bekleme listesindeki biri yerime geçebilsin ve geç iptal ücreti almayayım.
"Neden" kısmı, "ne" kısmının söylemediği iki şeyi söyler: telefonda çalışması gerekir ve bekleme listesi ile ücret kuralları işin içindedir.
Kabul kriterleri
Bir hikâye neyin istendiğini söyler. Kabul kriterleri ise ne zaman tamamlandığını söyler. Bunları iki kişi her birinin geçip geçmediği konusunda hemfikir olacak kadar belirli yazın.
Yaygın bir yazım biçimi Verilen / Eğer / O zaman yapısıdır:
- Verilen bir başlangıç durumu
- Eğer kullanıcı bir şey yaparsa
- O zaman bu sonuç gerçekleşir
Spor salonu rezervasyonu hikâyesi için:
- Verilen 12 saatten daha uzakta bir rezervasyonum varsa, eğer İptal'e dokunup onaylarsam, o zaman rezervasyon kaldırılır ve "Rezervasyon iptal edildi" yazısını görürüm.
- Verilen bir rezervasyonu iptal ediyorum ve dersin bekleme listesi varsa, eğer iptal kaydedilirse, o zaman bekleme listesindeki ilk kişi yeri ve bir e-postayı alır.
- Verilen 12 saatten daha az bir süre kaldıysa, eğer İptal'e dokunursam, o zaman onaylamadan önce geç iptal ücretinin uygulanacağını görürüm.
- Verilen telefon genişliğinde bir ekrandayım, o zaman İptal düğmesi yana kaydırmadan görünür.
Test edilebilir olduğu sürece düz bir kontrol listesi de işe yarar. "İptal etmek kolay" test edilemez. "İptal, rezervasyon listesinden en fazla iki dokunuşla yapılır" test edilebilir.
Adım adım: iyi bir hikâye yazmak
Adım 1: Gerçek bir kullanıcı ve gerçek bir sorunla başlayın
Bir kullanıcı türü ve bugün zorluk çektikleri bir şeyi seçin. Müşteri görüşmeleri yaptıysanız, onların sözlerini kullanın. "Her zaman iptal etmeyi unutuyorum ve ücret alınıyor" demek, "iptal özelliği ekle" demekten daha iyi bir başlangıç noktasıdır.
Adım 2: Tek satırlık hikâyeyi yazın
Şablonu doldurun. İnandırıcı bir "böylece" yazamıyorsanız, özelliğin gerçekten gerekli olup olmadığını sorun.
Adım 3: Üç ila altı kabul kriteri ekleyin
Önce ana başarılı senaryoyu, sonra önemli varyasyonları kapsayın: farklı bir rol, boş bir durum, bir sınır, bir hata. Altıdan fazla yazıyorsanız, hikâye muhtemelen çok büyüktür.
Adım 4: Kapsam dışında kalanları not edin
Tek satır çok fazla gidip gelmeyi önler: "Kapsam dışı: ücretli dersler için iadeler; yöneticilerin üyeler adına iptal etmesi." İnşa ederken hikâyenin büyümesini durdurur.
Adım 5: INVEST ile kontrol edin
INVEST, iyi hikâyeler için yaygın bir kontrol listesidir. Bir hikâye şöyle olmalıdır:
| Harf | Anlamı | Hızlı test |
|---|---|---|
| I | Bağımsız | Başka bir hikâye beklenmeden inşa edilebilir |
| N | Pazarlık edilebilir | İhtiyacı tarif eder, sabit bir tasarım değil |
| V | Değerli | Yayınlansa bir kullanıcı fark eder |
| E | Tahmin edilebilir | Kabaca ne kadar büyük olduğunu tahmin edebilirsiniz |
| S | Küçük | Tek oturumda inşa edilip test edilir |
| T | Test edilebilir | Her kabul kriteri kontrol edilebilir |
Her hikâyeyi puanlamanız gerekmez. Bir hikâye yanlış hissettirdiğinde nedenini anlamak istediğinizde en faydalısıdır.
İyi ve kötü örnekler
| Zayıf hikâye | Sorun | Daha iyi hikâye |
|---|---|---|
| Bir kullanıcı olarak, bir panel istiyorum. | Belirli bir kullanıcı yok, neden yok, test edilemez | Bir dükkân sahibi olarak, bugünkü siparişleri ve geliri tek ekranda görmek istiyorum, böylece günün nasıl gittiğini bir bakışta bileyim. |
| Bir yönetici olarak, veritabanında bir durum sütunu olmasını istiyorum. | İhtiyaç değil, uygulama tarif ediyor | Bir yönetici olarak, siparişleri gönderildi olarak işaretlemek istiyorum, böylece müşteriler nerede olduklarını sormak için e-posta atmasın. |
| Bir müşteri olarak, hesabımı yönetmek istiyorum. | Çok büyük: birçok özelliği kapsıyor | Bir müşteri olarak, e-posta adresimi değiştirmek istiyorum, böylece makbuzlar yeni gelen kutuma gelsin. |
| Bir ziyaretçi olarak, sitenin hızlı olmasını istiyorum. | Hikâye değil; herkesin ihtiyaç duyduğu bir nitelik | Bunu her hikâyede bir kriter olarak yazın ya da ayrı bir performans hedefi olarak. |
Çok büyük bir hikâye nasıl bölünür
Büyük hikâyeler projelerin takıldığı yerlerdir. Yaygın bölme yolları:
- Kullanıcı rolüne göre. Üyeler kendi rezervasyonlarını iptal eder; personel herkesinkini iptal eder.
- Akıştaki adıma göre. Dersleri göz at; bir ders rezerve et; hatırlatma al.
- Önce basit durum. Ücretsiz bir dersi şimdi iptal et; ücretler ve iadeler sonraki bir hikâyede ele alınır.
- Veri çeşitliliğine göre. Önce tek bir konum destekle, sonra birkaç konum.
- Mutlu yol, sonra hatalar. Önce çalışan hâliyle inşa et, sonra dolu dersler, süresi dolmuş paketler vb. için işlemeyi ekle.
Her parça, bir kullanıcının kullanabileceği ve fark edeceği bir şey olmaya devam etmelidir.
Kullanıcı hikâyelerini istem olarak kullanmak
Kabul kriterleri olan bir kullanıcı hikâyesi, bir yapay zekâ uygulama oluşturucu için iyi bir isteme çok yakındır. Yapay zekâya kim, ne, neden ve tamamlanmanın tanımını verir. Mesaj başına bir hikâye gönderin:
Bir spor salonu üyesi olarak, bir ders rezervasyonunu telefonumdan iptal edebilmek istiyorum, böylece bekleme listesindeki biri yerimi alabilsin. Kabul kriterleri:
- İptal, Rezervasyonlarım içindeki her rezervasyonda, bir onay adımıyla bulunur.
- Dersten 12 saatten fazla önce iptal etmek, rezervasyonu yalnızca kaldırır.
- 12 saatten az kala, onaylamadan önce "5 $ geç iptal ücreti uygulanır" yazısını göster ve ücreti rezervasyona kaydet.
- Dersin bekleme listesi varsa, ilk kişi yeri ve bir e-postayı alır.
- Telefon genişliğindeki bir ekranda çalışır. Kapsam dışı: iadeler, personelin üyeler adına iptali. Bunu inşa et, sonra her kriteri önizlemede kontrol et ve hangilerinin geçtiğini söyle.
Yapay zekâdan kaba bir fikirden kullanıcı hikâyeleri taslaklamasını da isteyebilirsiniz; sonra kendiniz düzenleyin:
Uygulama fikrim şu: [iki ya da üç cümle]. Birinci sürüm için kullanıcı hikâyelerini kullanıcı türüne göre grupla yaz; her birinde 3 ila 5 Verilen / Eğer / O zaman kabul kriteri olsun. Lansman için olmazsa olmaz olanları ve sonraya bırakılabilecekleri işaretle.
Sonucu her zaman okuyun ve düzenleyin. Yapay zekâ kullanıcılarınızı bilmez; siz bilirsiniz.
Kabul kriterleri aynı zamanda test planınızdır. Hikâye inşa edildiğinde, her kriteri kendiniz tek tek deneyin. Bu konuda, uygulamanızı lansmandan önce test etme rehberimiz bunun üzerine kurulur.
Kullanıcı hikâyelerinin diğer belgelerle ilişkisi
- Bir ürün gereksinim dokümanı tüm ürünü anlatır: sorun, kullanıcılar, kapsam. Kullanıcı hikâyeleri, onun içindeki ayrıntılı parçalardır. Bkz. yapay zekâyla PRD nasıl yazılır.
- Bir hata raporu, daha önce inşa edilmiş bir hikâyeye göre bozuk olan bir şeyi anlatır. Bkz. iyi bir hata raporu nasıl yazılır.
- Bir MVP, temel değeri sunan en küçük hikâye kümesidir. Bkz. MVP nedir.
Sık yapılan hatalar
- "Bir kullanıcı olarak…" Çok belirsiz. Kullanıcının gerçek türünü adlandırın.
- "Böylece" kısmını atlamak. Neden olmadan, makul ödünleşimler yapamazsınız.
- İhtiyacı değil çözümü yazmak. "Açılır liste istiyorum" diyerek, kimse tasarım üzerinde düşünmeden tasarımı kilitler.
- Test edilemeyen kriterler. "Kolay", "hızlı" ve "sezgisel" dilek kipleridir, kriter değil.
- Aslında epik olan hikâyeler. "Hesabımı yönetmek" on hikâyedir.
- Her hikâyeyi baştan yazmak. Sıradaki birkaç hikâyeyi ayrıntılı yazın; diğerlerini onlara gelene kadar tek satırlık notlar olarak tutun.
Mythex'te hikâyeler
Mythex'te bir fikri hikâyelere dönüştürmek için Plan modu iyi bir yerdir: ajan, bir şeyi düzenlemeden önce yaklaşımı tartışır. Bir hikâye hazır olduğunda Build'e geçin ve mesaj başına bir hikâye yapıştırın. Her birinden sonra /test önizlemede akışı tıklayarak kontrol edebilir, bir cevap ters giderse Bu noktaya geri dön ile geri alabilirsiniz. Dokümanlardaki etkili istemler bölümüne ve yapay zekâ uygulama oluşturucular için istem yazma rehberimize bakın.
Kullanıcı hikâyesi kontrol listesi
- Belirli bir kullanıcı türünü adlandırıyor
- Bir tasarım değil, bir ihtiyacı anlatıyor
- Gerçek bir "böylece" nedeni var
- Üç ila altı test edilebilir kabul kriteri var
- En az bir uç durumu ya da hatayı kapsıyor
- Kapsam dışında kalanları belirtiyor
- Tek seferde inşa edilip test edilecek kadar küçük
- İnşa edildikten sonra kriterler tek tek kontrol edildi
Sorular
Bir kullanıcı hikâyesinin biçimi nedir?
Yaygın şablon şudur: Bir [kullanıcı türü] olarak, [bir hedef] yapmak istiyorum, böylece [bir neden]. Bunun ardından kabul kriterleri gelir; hikâyenin tamamlanmış sayılması için doğru olması gereken kısa bir koşullar listesidir.
Kabul kriterleri nedir?
Kabul kriterleri, bir kullanıcı hikâyesinin ne zaman tamamlandığını tanımlayan, belirli ve test edilebilir koşullardır. Çoğu zaman Verilen / Eğer / O zaman biçiminde yazılır: verilen bir başlangıç durumunda, kullanıcı bir şey yaptığında, belirli bir sonuç gerçekleşir.
Bir kullanıcı hikâyesi ne kadar büyük olmalı?
Tek bir oturumda inşa edilip test edilebilecek kadar küçük, ama tek başına da değerli olmalı. Bir hikâyede beşten fazla ya da altıdan fazla kabul kriteri varsa ya da birden çok ekranı kapsıyorsa, kullanıcı rolüne, akıştaki adıma ya da önce basit durumlara göre bölün, uç durumları sonraya bırakın.
Kullanıcı hikâyeleri yapay zekâyla inşa ederken işe yarar mı?
Evet. Kabul kriterleri olan bir kullanıcı hikâyesi, ideal bir isteme çok yakındır: özelliğin kimin için olduğunu, neye ihtiyacı olduğunu ve çalıştığını tam olarak nasıl kontrol edeceğinizi söyler. Mesaj başına bir hikâye göndermek de yapay zekâ değişikliklerini küçük ve test edilmesi kolay tutar.