Use Case'ten User Story'ye: 3C, INVEST ve Hangi Durumda Use Case Hâlâ Daha İyi?
Use case bütünü ve dallarını gösteren haritadır, user story ise o haritadan çıkan, tek başına değer veren teslimat birimidir; her alternatif akış story olmak zorunda değildir. Bookstore'un kurumsal sipariş use case'ini yedi story'ye ve kabul koşullarına bölüyor, Jeffries'in card-conversation-confirmation üçlüsünü, "As a / I want / so that" kalıbının sınırlarını, INVEST kontrolünü, epic-story-task ayrımını ve use case'in hâlâ daha iyi olduğu durumları anlatıyoruz.
Sürüm notu: Bu yazı kavramsaldır; story'nin üç parçası için Ron Jeffries'in XP (Extreme Programming) üzerine 30 Ağustos 2001 tarihli "Essential XP: Card, Conversation, Confirmation" yazısı, iyi story ve task nitelikleri için Bill Wake'in xp123.com'da yayımlanan 2003 tarihli yazısı esas alınmıştır.
Önce Tahmin Et
Elicitation bitti. Selin, Emre ve Ayşe toplu siparişi önce bir use case olarak yazıyor, çünkü elicitation'dan gelen bilgi bir akış hâlinde: liste giriliyor, doğrulanıyor, teslimat noktalarına dağıtılıyor, onaya gidiyor, sevk ediliyor. Ortaya yedi adımlık bir ana akış ve yedi alternatif akış çıkıyor.
Ekip şimdi bu use case'i sprint'lerde teslim edilebilecek user story'lere bölecek. Üç öneri var. Emre: "Her adım bir story olsun, yedi story." Ayşe: "Ana akış bir story, her alternatif akış ayrı bir story, toplam sekiz." Selin: "Bir kısmı story, bir kısmı başka story'lerin kabul koşulu." Hangisi doğru? Kaç story çıkar? Okumadan önce kendi sayını not et.
Kurumsal Sipariş Use Case'i
Use case diagram'ı, actor'ları ve Cockburn şablonunun alanlarını UML (yazılım modellemede kullanılan standart diyagram dili) ve Modeling serisinin "Use Case Diagram ve Use Case Spesifikasyonu" yazısında ayrıntılı görmüştük; burada şablonu tekrar etmiyoruz, yalnızca akışları kullanıyoruz. Önceki yazıdaki glossary kararıyla use case'in adı "Kurumsal Sipariş Ver", birincil actor okulun satın alma sorumlusu.
Ana başarı senaryosu: (1) Satın alma sorumlusu kurum hesabıyla yeni bir kurumsal sipariş başlatır. (2) ISBN ve adet listesini girer. (3) Sistem her satırı katalogla doğrular ve sonucu satır satır gösterir. (4) Satın alma sorumlusu satırları kurumun teslimat noktalarına dağıtır. (5) Sistem kurumsal indirimi uygulayarak toplam tutarı gösterir. (6) Satın alma sorumlusu kurumun satın alma emri numarasını girip siparişi gönderir. (7) Sistem siparişi kaydeder, sevkiyat için depoya iletir ve faturayı ERP (kurumsal kaynak planlama sistemi) aktarımına sıraya koyar.
Alternatif akışlar: 2a listede ISBN yok, yalnız kitap adı var; satın alma sorumlusu kitapları adıyla arar. 3a bir ISBN katalogda yok; satır işaretlenir ve düzeltilmeden ya da çıkarılmadan sipariş gönderilemez. 3b aynı ISBN birden fazla satırda; sistem satırları birleştirmeyi önerir. 5a sipariş, kurumsal siparişin minimum adet kuralını karşılamıyor (kuralın kendisi hâlâ açık soru). 6a tutar, kurumun onay limitini aşıyor; sipariş "Onay Bekliyor" durumuna geçer ve kurumun muhasebe yetkilisi onaylayınca devam eder. 7a bir kitabın stoku yetersiz; kurum kısmi sevkiyat ile bekletme arasında seçim yapar. *a satın alma sorumlusu herhangi bir adımda vazgeçer; liste taslak olarak kalır.
Use case'in değeri, bütünü tek bakışta göstermesi. Bu metni okuyan biri, hangi durumların düşünüldüğünü ve hangilerinin henüz cevapsız olduğunu (5a) hemen görür. Eksik olan şey, bu bütünün iki haftalık bir sprint'e nasıl sığacağı.
Akışlardan Story'lere
Ana fikir şu: her alternatif akış ayrı bir story olabilir, ama olmak zorunda değildir. Bir alternatif akışı ayrı bir story yapan şey, kullanıcıya tek başına değer vermesi ve ayrıca teslim edilip gösterilebilmesidir. Ana akışın parçası olmadan anlamı olmayan bir kural ise bir story'nin kabul koşulu olarak kalır.
| Use case parçası | Karar | Story ya da kabul koşulu |
|---|---|---|
| Ana akış 1, 2, 3, 6, 7 | Story | Satın alma sorumlusu ISBN ve adet listesini yapıştırarak kurumsal sipariş verir (tek teslimat noktası, liste fiyatı). |
| 3a, 3b | Kabul koşulu | İlk story'nin parçası: bulunamayan ISBN satır numarasıyla gösterilir; tekrar eden ISBN'ler birleştirilir. |
| Ana akış 4 | Story | Satın alma sorumlusu satırları kurumun teslimat noktalarına dağıtır. |
| Ana akış 5 | Story | Satın alma sorumlusu kurumsal indirimin uygulandığı toplam tutarı görür. |
| 5a | Kabul koşulu (bekliyor) | Minimum adet kuralı netleşince indirim ya da sipariş story'sine eklenir. |
| 2a | Story | Satın alma sorumlusu ISBN'i olmayan kitapları adıyla arayıp listeye ekler. |
| 6a | Story | Onay limitini aşan sipariş, kurumun muhasebe yetkilisi onaylayana kadar bekler. |
| 7a | Story | Stok yetersizken kurum kısmi sevkiyatı ya da bekletmeyi seçer. |
| *a | Story | Satın alma sorumlusu listeyi taslak olarak kaydedip sonra devam eder. |
Sonuç yedi story ve story'lere dağılmış birkaç kabul koşulu. Önce Tahmin Et'teki üç öneriden Selin'inki en yakını. Emre'nin "her adım bir story" önerisi ise bir tuzak: "Sistem satırları doğrular" adımı tek başına kimseye değer vermez; liste girilmeden ve sipariş gönderilmeden doğrulamanın anlamı yok. Adım adım bölmek, ileride göreceğimiz katman katman bölmenin akrabasıdır.
Tablonun gizli bir avantajı daha var: her story hangi use case parçasından geldiğini biliyor. 3a ile 3b'nin ilk story'nin kabul koşulu olduğunu bilen biri, o story test edilirken bu iki durumun da test edileceğinden emindir.
Card, Conversation, Confirmation
User story fikri XP'den gelir ve en sade tarifi Ron Jeffries'indir. Jeffries 2001 tarihli yazısında "The card is a token representing the requirement." der: kart requirement'ın kendisi değil, onu temsil eden bir işarettir. Requirement'ın asıl içeriği, müşteri ile geliştiriciler arasındaki konuşmada aktarılır; konuşmanın sonunda varılan anlaşma ise kabul testleriyle onaylanır. Card, conversation, confirmation üçlüsü bu üç parçanın adıdır.
İlk story'nin kartı Bookstore'da şöyle duruyor. Ön yüz: "Kurumsal sipariş: liste yapıştırarak sipariş ver. Okulun satın alma sorumlusu olarak, öğretmenlerden topladığım ISBN ve adet listesini yapıştırarak sipariş vermek istiyorum; böylece 240 kitabı tek tek aramak zorunda kalmam." Arka yüzde, confirmation için üç cümle: 240 satırlık geçerli bir liste yapıştırıldığında 240 satır ve toplam tutar gösterilir; katalogda olmayan bir ISBN satır numarasıyla gösterilir ve o satır düzeltilmeden sipariş gönderilemez; tireli ve tiresiz yazılmış aynı ISBN aynı kitap sayılır.
Kartın üzerinde olmayan şey, konuşmanın kendisi. Emre'nin "eski baskıların ISBN'leri ne olacak?" sorusu, Gül'ün düzeltme listesinden bahsetmesi, Selin'in bunu ilk sürüme almama kararı. Bu konuşma bir yerde not alınır ama kartın yerine geçmez. Card üçlünün en görünür ama en az önemli parçasıdır; ekiplerin tracker'da en çok emek harcadığı yer ise genellikle tam da odur.
Confirmation parçası serinin geri kalanının çekirdeği. Arka yüzdeki üç cümle, 05. yazıda Example Mapping ile kurallara ve örneklere, 07. yazıda Gherkin senaryolarına, 08. yazıda çalışan testlere dönüşecek.
"As a / I want / so that" Kalıbı ve Sınırları
Kartın ön yüzündeki rol, istek ve gerekçe kalıbı, Agile Alliance sözlüğüne göre 2001'de İngiltere'deki Connextra ekibinde ortaya çıktı ve bugün user story ile neredeyse eş anlamlı hâle geldi. Kalıbın asıl katkısı, ekibe her story'de iki soruyu hatırlatması: bunu kim istiyor ve neden istiyor?
Kalıbın sınırları da aynı yerden gelir. Rol kısmı ancak roller gerçekten farklıysa bilgi taşır; "Kullanıcı olarak..." diye başlayan bir story hiçbir şey söylemez. Toplu siparişte satın alma sorumlusu, kurumun muhasebe yetkilisi ve Bookstore müşteri hizmetleri farklı rollerdir ve story'yi kimin gözünden yazdığın, kabul koşullarını değiştirir.
"So that" kısmı en çok ihmal edilen ve en değerli kısımdır. "...sipariş verebilmek için" diye biten bir gerekçe, isteğin kendisini tekrar eder. "...böylece 240 kitabı tek tek aramak zorunda kalmam" ise ekibe bir ölçüt verir: çözüm aramayı ortadan kaldırmıyorsa amacına ulaşmamıştır.
Kalıp bağlamı da taşımaz. Satın alma sorumlusunun bu işi yılda bir kez, ağustos sonunda, bütçe onayı beklerken yaptığı bilgisi rol cümlesinde yoktur ama tasarımı derinden etkiler. Product Management'a Giriş serisinin "Output Değil Outcome" yazısında bu eksikliği kapatan job story formatına bakmıştık; iki format bir arada kullanılabilir. Son olarak, kalıp bir zorunluluk değil. Ekibin anlaşabildiği kısa ve net bir cümle, kalıba zorla sokulmuş bir cümleden iyidir.
INVEST ile Sınamak
Bill Wake 2003'te iyi bir story'nin altı niteliğini INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) kısaltmasıyla topladı. Her harfi Bookstore'un story'lerinden biriyle sınayalım:
| Nitelik | Sorduğun soru | Toplu siparişte |
|---|---|---|
| Independent | Bu story'yi diğerlerinden önce ya da sonra yapabilir miyiz? | "Teslimat noktalarına dağıtma", liste ile sipariş story'si olmadan çalışmaz; tamamen bağımsız olamaz ama ilk story tek teslimat noktasıyla kendi başına teslim edilebilir. |
| Negotiable | Ayrıntılar hâlâ konuşmaya açık mı? | Kartta "yapıştırarak" yazıyor; dosya yükleme isteği gelirse bu bir sözleşme ihlali değil, yeni bir konuşmadır. |
| Valuable | Kullanıcı ya da iş bu story bitince bir şey kazanıyor mu? | "ISBN normalize eden fonksiyonu yaz" kimseye değer vermez; bu bir task, ilk story'nin içinde yaşar. |
| Estimable | Ekip büyüklüğü kabaca söyleyebiliyor mu? | "Faturayı ERP'ye aktar": ekip ERP'nin API'sini hiç kullanmadı; önce zaman sınırlı bir spike gerekir. |
| Small | Bir sprint içinde, tercihen birkaç günde biter mi? | "Kurumsal sipariş" bütünüyle bir story değil, bir epic. |
| Testable | Bittiğini gösterecek bir test yazabilir miyiz? | "Liste kolay girilsin" test edilemez; arka yüzdeki üç cümle edilebilir. |
Wake de bağımsızlığın her zaman sağlanamayacağını kabul eder; amaç bağımlılığı sıfırlamak değil, story'lerin sırasını bağımlılık yüzünden değil değer yüzünden belirleyebilmek. Estimable harfinin tavsiyesi de pratik: bir story tahmin edilemeyecek kadar belirsizse, onu öğrenmek için zaman sınırlı bir spike ayır ve spike'ın çıktısını "ERP'ye bir test faturası aktarıldı ve aktarım süresi ölçüldü" gibi somut bir cümleyle tanımla. Story'leri bölmenin yollarını bir sonraki yazıda ayrıntılı göreceğiz.
Epic, Story, Task
Üç kelime farklı ayrıntı seviyelerini anlatır ve karıştırıldıklarında backlog okunmaz hâle gelir. Epic, tek bir sprint'e sığmayan, bir grup story'yi şemsiyesi altında toplayan büyük bir iştir: "Kurumsal sipariş" bir epic. Story, kullanıcıya görünür bir davranış değişikliğidir ve tek başına teslim edilip gösterilebilir: "Liste yapıştırarak kurumsal sipariş ver." Task ise bir story'yi bitirmek için ekibin yaptığı iş adımıdır ve kullanıcı onu görmez: "ISBN'deki tireleri ve boşlukları temizleyen fonksiyon", "sipariş satırına teslimat noktası kolonu eklemek", "doğrulama sonucu tablosunun Angular component'i".
Wake aynı yazısında task'lar için de bir kontrol listesi önerir: SMART (Specific, Measurable, Achievable, Relevant, Time-boxed). Bir task'ın kimin üzerinde olduğu, ne zaman bittiği ve hangi story'ye hizmet ettiği belli olmalı. Story'ler Product Owner ile birlikte sıralanır; task'lar ise geliştiricilerin kendi planıdır ve backlog'da story'nin altında yaşar.
Use Case Hâlâ Ne Zaman Daha İyi?
User story'nin yaygınlaşması use case'i gereksiz kılmadı. Bazı durumlarda use case, story'nin veremeyeceği bir şey verir: bütünün sırasını ve dallarını tek bir metinde tutmak.
Çok adımlı ve kurallı akışlar ilk örnek. Kütüphanenin süreci (önce fiyat teklifi, teklifin kurum içinde onayı, sipariş, teslim, teslimden sonra fatura) adımların sırası ve hangi durumda hangi adıma dönüleceği önemli olan bir akış. Bunu yedi bağımsız story'ye dağıtırsan, "teklif onaylanmadan sipariş verilebilir mi?" sorusunun cevabı hiçbir story'de tek başına durmaz.
Regüle alanlar ikinci örnek. Bir denetçinin sistemin bütün davranışını, istisnalarıyla birlikte, tek bir dokümanda görmek istediği işlerde (ödeme, sağlık, kamu ihaleleri gibi) dağınık story'ler bu ihtiyacı karşılamaz; use case, test kanıtıyla birlikte saklanabilecek bir referans olur.
Sözleşmeye bağlı işler üçüncü örnek. Sabit kapsamlı bir projede kabul, imzalanmış bir kapsam dokümanına göre yapılıyorsa, o dokümanın use case'ler biçiminde olması iki tarafa da neyin teslim edildiğini tartışmasız gösterir. Story'ler yine de teslimat birimi olarak kullanılabilir; use case ise kapsamın kaydı olarak kalır.
İki dünyayı birleştirmeye çalışan bir yaklaşım da var: Ivar Jacobson ve ekibinin 2011'de yayımladığı Use-Case 2.0, bir use case'i "use-case slice" denen, her biri ayrı test edilip teslim edilebilen dikey parçalara böler. Bizim yukarıdaki tablomuz, bu fikrin hafif bir uygulaması: use case harita, story'ler teslimat birimi.
Üretimde Dikkat
Story'yi geldiği use case parçasına bağla. Story açıklamasının ilk satırına UC-BULK-01 / 6a gibi bir referans koymak, altı ay sonra "onay limiti kuralı nereden çıktı?" sorusunu tek aramayla cevaplatır. Use case'i ise story'ler bittikçe güncelle; story'lerle çelişen bir use case, hiç olmamasından daha zararlıdır.
Conversation'ın izini tut. Konuşmada verilen kararlar, özellikle "bunu ilk sürüme almıyoruz" türünden olanlar, story'nin yorumlarında ya da bağlı bir notta yazmalı. Yoksa demo'da "eski baskı ISBN'leri neden çalışmıyor?" sorusu geldiğinde kimse cevabın verildiğini hatırlamaz.
Confirmation olmadan story'yi sprint'e alma. Arka yüzü boş bir story, "bitti"nin sprint sonunda tartışılacağı anlamına gelir. Kabul koşullarını yazma ve netleştirme işini 05. yazıda Example Mapping ile ayrıntılı yapacağız.
Sık Düşülen Tuzaklar
İlk tuzak teknik işi story gibi yazmak: "Bir developer olarak, kurumsal siparişler için veritabanı tablolarını oluşturmak istiyorum, böylece siparişleri saklayabilirim." Bu cümle kalıba uyuyor ama kimseye değer vermiyor ve bir story'nin task'ını gizliyor. Tablolar, onları kullanan ilk story'nin içinde oluşturulur. Gerçekten tek başına yapılması gereken bir teknik iş varsa (ERP spike'ı gibi), onu story kılığına sokmadan adıyla yaz.
İkinci tuzak story'yi mini spesifikasyon dokümanına çevirmek. Açıklama alanına üç sayfa ekran tarifi, alan uzunlukları ve hata mesajları yazılmış bir story, konuşmayı gereksiz gösterir; ekip okur, uygular ve yazılmamış soruları hiç sormaz. Kart kısa kalmalı; ayrıntı konuşmada üretilir ve confirmation'da kayda geçer.
Üçüncüsü tersi: yalnızca başlığı olan story. "Kurumsal sipariş - onay" başlıklı, açıklaması ve kabul koşulu olmayan bir kart, konuşmanın hiç yapılmadığının işaretidir.
Dördüncüsü use case'in her adımını ayrı story yapmak. "Sistem satırları doğrular" ve "Sistem toplamı gösterir" ayrı ayrı teslim edildiğinde hiçbiri kullanıcıya değer vermez; Emre'nin önerisinin sorunu buydu.
Beşincisi "so that" kısmını isteğin tekrarına çevirmek. Gerekçe, ekibin çözümü değerlendireceği ölçüttür; "...sipariş verebilmek için" bir ölçüt değildir.
Küçük Bir Deneme
★☆☆ Backlog'undaki beş story'yi INVEST ile sına. Her biri için en zayıf harfi işaretle ve o harfi güçlendirmek için story'de neyin değişmesi gerektiğini bir cümleyle yaz.
★★☆ Bildiğin bir iş akışı için kısa bir use case yaz: ana akış ve en az dört alternatif akış. Sonra bu yazıdaki tabloyu kendi use case'in için doldur: hangi parça story, hangisi kabul koşulu? Kararını "tek başına değer veriyor mu?" sorusuyla gerekçelendir.
★★★ Ekibinin tracker'ında "As a developer" ya da benzeri bir rolle başlayan bir story bul. Onu ya gerçek bir kullanıcının story'sine dönüştür ya da bir story'nin altına task olarak taşı. Hangisini seçtiğini ve nedenini ekiple konuş.
Elimizde yedi story ve bir use case var, ama hâlâ cevaplanmamış bir soru duruyor: eylül başında hangileri çıkacak? Bir sonraki yazıda story'leri bir story map üzerine yerleştireceğiz, walking skeleton'ı bulacağız, büyük story'leri bölmenin yollarına bakacağız ve ilk release'i seçeceğiz.