User Story
Kullanıcı Hikâyesi
- Okunuşu
- yuzır stori
Kısaca
User story, bir özelliğin kullanıcının bakış açısından, kimin neyi neden istediğini açıklayan kısa ve sade bir dille yazılmış tanımıdır.
User story (kullanıcı hikâyesi) nedir?
User story, yararlanacak kişinin bakış açısından yazılmış küçük bir iş birimidir. Teknik bir şartname yerine, bir ihtiyacı gündelik dille, genellikle şu kalıpla anlatır: [kullanıcı türü] olarak, [bir sebep] için [bir hedef] istiyorum. User story'ler Extreme Programming'den (XP) çıkmıştır ve bugün Scrum ile Kanban kullananlar da dahil çoğu Agile ekip tarafından kullanılır.
Bir story kasıtlı olarak kısadır; ekip ile ihtiyacı anlayan kişiler arasındaki bir konuşmanın yer tutucusudur. Ron Jeffries bunu üç C olarak tanımlamıştır: Kart (Card, kısa yazılı story), Konuşma (Conversation, ayrıntıların tartışılması) ve Onay (Confirmation, story'nin ne zaman tamamlandığını gösteren kabul kriterleri). Kabul kriterleri çoğu zaman Given/When/Then biçiminde yazılır; bu da onların otomatik testlere dönüştürülmesini kolaylaştırır.
İyi story'ler yaygın olarak INVEST kontrol listesiyle denetlenir: Independent (bağımsız), Negotiable (müzakere edilebilir), Valuable (değerli), Estimable (tahmin edilebilir), Small (küçük) ve Testable (test edilebilir). Bir sprint'te bitirilemeyecek kadar büyük story'ye epic denir ve daha küçük story'lere bölünür. Story'leri bir restorandaki siparişlere benzetebilirsiniz: çocuğunuz için fındıksız vejetaryen bir yemek istemek, tarifi dikte etmeden mutfağa neyin önemli olduğunu söyler.
User story çoğunlukla görev (task) ya da gereksinimle karıştırılır. Görev, bir veritabanı tablosu oluşturmak gibi teknik işi tanımlar; story ise kullanıcıya sağlanan değeri tanımlar ve onu teslim etmek için birkaç görev gerekebilir. Bir başka yaygın biçim olan use case daha ayrıntılıdır ve bir kullanıcı ile bir sistem arasındaki adım adım etkileşimleri tanımlar.
Önemli noktalar
- User story, bir ihtiyacı teknik tasarımı değil, kullanıcının bakış açısını esas alarak tanımlar.
- Yaygın kalıp: [Kullanıcı] olarak, [sebep] için [hedef] istiyorum.
- Kabul kriterleri bir story'nin ne zaman tamamlandığını tanımlar.
- Büyük story'lere epic denir ve daha küçüklere bölünür.
- INVEST kontrol listesi ekiplerin iyi story yazmasına yardımcı olur.
Örnek
Title: Reset password by email
As a registered customer,
I want to reset my password using my email address,
so that I can get back into my account if I forget it.
Acceptance criteria:
- Given I am on the login page,
when I click "Forgot password" and enter my email,
then I receive a reset link within 5 minutes.
- Given I open a reset link older than 1 hour,
then I see a message that the link has expired.Sık sorulan sorular
User story ile epic arasındaki fark nedir?
Epic, tek bir sprint'te bitirilemeyecek kadar büyük bir iş kümesidir. Her biri kendi başına tamamlanıp teslim edilebilecek birkaç küçük user story'ye bölünür.
User story'leri kim yazar?
Ekipteki herkes yazabilir; ancak en değerli story'lerin backlog'da olduğundan ve net biçimde anlaşıldığından emin olmak genellikle Product Owner'ın ya da ürün yöneticisinin sorumluluğundadır.
Kabul kriterleri (acceptance criteria) nedir?
Kabul kriterleri, bir story'nin tamamlanmış sayılması için karşılaması gereken beklenen davranış veya uç durumlar gibi belirli koşullardır. Tüm işe uygulanan tamamlanma tanımından (definition of done) farklı olarak tek bir story'ye aittirler.
İlgili sayfalar
- AgileEkipler ve Süreç, s. 3Agile, çalışan yazılımı küçük ve sık parçalar halinde teslim eden ve planları düzenli geri bildirime göre ayarlayan bir yazılım geliştirme yaklaşımıdır.
- ScrumEkipler ve Süreç, s. 21Scrum, küçük bir ekibin tanımlı roller, olaylar ve çıktılarla ürünü sprint denen sabit uzunluklu döngülerde teslim ettiği bir Agile framework'üdür.
- Story PointsEkipler ve Süreç, s. 27Story point, Agile ekiplerin iş öğelerinin göreli büyüklüğünü saat yerine karmaşıklık, iş miktarı ve belirsizliği birleştirerek tahmin ettiği birimdir.
- Definition of DoneEkipler ve Süreç, s. 8Definition of Done, bir işin ekip tarafından tamamlanmış sayılabilmesi için karşılaması gereken kalite standartlarının ortak kontrol listesidir.
- SprintEkipler ve Süreç, s. 25Sprint, bir Scrum ekibinin tek hedefe doğru çalışıp kullanılabilir bir ürün artışı ürettiği, bir ay veya daha kısa, çoğunlukla iki haftalık sabit dönemdir.
- MVPEkipler ve Süreç, s. 14MVP, gerçek kullanıcıların kullanabileceği en sade ürün sürümüdür; temel bir varsayımı test etmek ve en az emekle en çok şeyi öğrenmek için geliştirilir.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin