User Story mi, Use Case mi? Sahada İşe Yarayan Seçim Rehberi
- 2 gün önce
- 7 dakikada okunur
Yıllar boyunca farklı analiz ve ürün geliştirme ortamlarında aynı tartışmanın tekrarlandığını gördük: “User Story mi yazalım, Use Case mi?” Bir taraf User Story’yi çevikliğin vazgeçilmez dili, diğer taraf Use Case’i eksiksiz analizin güvencesi olarak savunuyor. Oysa sahada yaşanan sorunların çoğu, tekniklerden birinin yanlış olmasından değil; doğru tekniğin yanlış zamanda, yanlış derinlikte kullanılmasından doğuyor.
Bir ekip kullanıcı değerini netleştirmeden sayfalarca akış yazdığında ayrıntı hızla eskimeye başlıyor. Başka bir ekip ise tek satırlık User Story’yi yeterli sanıp alternatif ve istisna akışlarını konuşmadığında kritik davranışlar geliştirme sırasında ortaya çıkıyor. Bu yazıda “hangisi kazanır?” sorusuna değil, hangi belirsizlikte hangi araç daha çok işe yarar ve ikisi nasıl birlikte kullanılabilir? sorusuna yanıt arayacağız.
Not: Aşağıdaki saha örnekleri tek bir kurumun ya da projenin birebir anlatımı değildir. Yıllara yayılan çalışmalarda tekrar tekrar karşılaşılan örüntüler, kişi ve kurum bilgisi içermeyen birleşik senaryolar olarak aktarılmıştır.
Bu yazıda neler bulacaksınız?
Sorun teknikte değil, yanlış zamanda derinleşmekteydi
Bir çalıştayda ekip, henüz “Bu özellik hangi kullanıcı problemini çözüyor?” sorusunda uzlaşamamışken ayrıntılı bir Use Case hazırlamaya koyulmuştu. Ön koşullar, ekran adımları ve alternatif akışlar yazıldı; fakat ürün hedefi netleşince çözüm yaklaşımı değişti ve dokümanın önemli bölümü geçerliliğini yitirdi. Buradaki sorun Use Case değildi. Sorun, keşif aşamasındaki belirsizliği akış ayrıntısıyla kapatmaya çalışmaktı.
Başka bir ekipte bunun tersini gördük. Ödeme özelliği için “Müşteri olarak siparişimi kartla ödemek istiyorum; böylece alışverişimi tamamlayabilirim” cümlesi yazılmış, birkaç başarı kriteri eklenmiş ve çalışma hazır kabul edilmişti. Refinement ilerledikçe 3D Secure reddi, zaman aşımı, tekrarlanan istek, stok rezervasyonunun düşmesi ve iade gibi yolların farklı kişilerce farklı yorumlandığı ortaya çıktı. Bu kez sorun User Story değildi. Sorun, dallanan ve riskli bir etkileşimi tek satırlık kayıtla açıklamaya çalışmaktı.
Bu iki gözlem bize aynı dersi verdi: Teknik seçimi metodoloji etiketinden önce belirsizliğin türüne bakılarak yapılmalı. Değer ve kapsam belirsizse konuşmayı User Story ile başlatmak; davranış, aktör ve istisna belirsizse Use Case veya senaryo modellemesiyle derinleşmek daha sağlıklı sonuç veriyor.
User Story neyi görünür kılar?
User Story, bir ihtiyacı kullanıcı veya paydaş açısından, beklenen değerle birlikte kısa biçimde görünür kılar. İyi bir User Story’nin gücü, cümlenin kendisinden çok başlattığı konuşmadadır. Agile Alliance’ın aktardığı Card, Conversation, Confirmation yaklaşımı da hikâyeyi yalnızca bir kart ya da iş takip kaydı olarak değil; konuşma ve doğrulamayla tamamlanan bir çalışma biçimi olarak tanımlar.
Sahada User Story’yi özellikle şu durumlarda verimli bulduk:
Ürünün nedenini ve kullanıcı değerini ekipçe netleştirirken,
Büyük bir ihtiyacı teslim edilebilir küçük parçalara ayırırken,
Backlog üzerinde öncelik ve sıra kararı verirken,
Çözüm ayrıntısını erken sabitlemeden öğrenmeye alan açarken,
İş birimi, ürün, geliştirme ve test ekipleri arasında ortak konuşma başlatırken.
Ancak kısa olmak, eksik bırakmak anlamına gelmez. Hikâyenin bağlamı, kapsam sınırı, iş kuralları ve nasıl doğrulanacağı konuşulmamışsa elimizde yalnızca düzgün yazılmış bir cümle kalır. Kullanıcı hikâyelerinde format yerine iletişimin neden belirleyici olduğunu daha önce ayrıntılı ele almıştık.
Use Case neyi görünür kılar?
Use Case, bir aktörün belirli bir hedefe ulaşırken sistemle kurduğu etkileşimi adım adım görünür kılar. Ana akışın yanında alternatif ve istisna akışlarını da düşündürdüğü için özellikle “Burada başka ne olabilir?” sorusunu sistematik biçimde gündeme getirir.
Use Case’i yalnızca bir UML diyagramı sanmak sahada sık rastladığımız bir yanılgıdır. Diyagram; aktörleri, sistem sınırını ve kullanım durumları arasındaki ilişkileri kuş bakışı gösterebilir. Fakat kritik iş kuralları, koşullar ve dallanan davranışlar çoğu zaman metinsel akışlarda ya da destekleyici modellerde netleşir.
Use Case’in değerini en çok şu durumlarda gördük:
Birden fazla aktör veya sistem aynı işleme katıldığında,
Ana akışın yanında çok sayıda alternatif ya da istisna bulunduğunda,
Hatanın maliyeti yüksek, süreç düzenlemeye tabi veya denetlenebilir olduğunda,
Entegrasyon sınırları ve sorumluluk geçişleri belirsiz olduğunda,
Test senaryoları için uçtan uca davranış bağlamı gerektiğinde.
Use Case burada “daha fazla doküman” değil, doğru riske odaklanmış bir düşünme aracıdır. Yalnızca gerçekten karar vermeyi veya doğrulamayı kolaylaştıran ayrıntıyı tutmak gerekir.
Agile–Waterfall eşleştirmesi neden yanıltıcıdır?
“User Story Agile içindir, Use Case Waterfall içindir” cümlesi ilk bakışta pratik görünür; fakat gerçek çalışma ortamlarını açıklamakta yetersiz kalır. Scrum rehberi Product Backlog öğelerinden söz eder, bunların mutlaka User Story biçiminde yazılmasını şart koşmaz. User Story, Scrum ile birlikte sık kullanılan tamamlayıcı bir pratiktir; Scrum’ın zorunlu artefaktı değildir.
Benzer şekilde Use Case de yalnızca baştan sona ayrıntılı dokümantasyon üreten geleneksel projelere ait değildir. Ivar Jacobson International’ın Use-Case 2.0 yaklaşımı, kullanım durumlarının dilimler hâlinde ele alınarak yinelemeli ve artımlı geliştirmede kullanılabileceğini açıkça gösterir. Yani bir Use Case’i tamamen baştan yazmak yerine, yalnızca sıradaki değerli senaryo dilimini “yeteri kadar, gerektiği zaman” derinleştirmek mümkündür.
Saha açısından daha kullanışlı ayrım şudur:
Değer, kapsam ve öncelik konuşulacaksa: User Story güçlü bir başlangıçtır.
Etkileşim, alternatifler ve istisnalar netleştirilecekse: Use Case güçlü bir derinleşme aracıdır.
Her ikisi de belirsizse: Teknikleri birlikte kullanmak çoğu zaman daha az yeniden çalışma yaratır.
Bu nedenle yöntemi araçla karıştırmamak gerekir. Çeviklik, belirli bir belgeyi yasaklamak değil; doğru bilgiyi doğru zamanda, geri bildirime açık biçimde üretmektir. Agile projelerde planlamanın nasıl katmanlı ve uyarlanabilir ilerlediğini anlattığımız yazıdaki mantık, analiz dokümantasyonu için de geçerlidir.
Aynı özelliği iki teknikle birlikte nasıl ele aldık?
Ödeme senaryosuna dönelim. Çalışmaya önce kullanıcı değerini taşıyan bir User Story ile başladığımızı düşünelim:
Müşteri olarak siparişimi güvenli biçimde kartla ödemek istiyorum; böylece satın alma işlemini tamamlayabileyim.
Bu kayıt, konuşmayı doğru hedefe yöneltir; fakat ödeme gibi kritik bir akışta tek başına yeterli değildir. Ardından Use Case görünümüyle davranışı açarız:
Müşteri ödeme yöntemini seçer.
Sistem tutarı ve sipariş uygunluğunu doğrular.
Ödeme sağlayıcısına yetkilendirme isteği gönderilir.
Gerekirse ek doğrulama tamamlanır.
Başarılı sonuçta sipariş onaylanır ve kullanıcı bilgilendirilir.
Sonra ana akışın dışında kalan soruları masaya getiririz:
Yetkilendirme reddedilirse kullanıcı ne görür?
Sağlayıcı yanıt vermezse işlem hangi durumda tekrar denenir?
Aynı istek iki kez gelirse mükerrer tahsilat nasıl engellenir?
Ödeme başarılı, sipariş oluşturma başarısız olursa telafi akışı nedir?
Stok rezervasyonu ödeme sırasında sona ererse hangi karar uygulanır?
Bu soruların yanıtlarından bir bölümü kabul kriterlerine, bir bölümü iş kurallarına, bir bölümü de teknik veya test senaryolarına dönüşür. Böylece User Story backlog’daki değer ve planlama birimi olmaya devam eder; Use Case ise riskli davranışı görünür kılar. Ayrıntılı kayıtlar hikâyeyi boğmaz, hikâye de sistem davranışının yerine geçmez.
Bu yaklaşım, backlog yönetiminde iş parçalama ve önceliklendirme ile gereksinim analizinde doğrulama ve görselleştirme adımlarını aynı çalışma akışında buluşturur.
User Story mi, Use Case mi? Karar tablosu
İhtiyaç veya risk | Önce User Story | Use Case ile derinleş | Birlikte kullan |
|---|---|---|---|
Kullanıcı değeri ve öncelik belirsiz | ✓ | ||
Hızlı keşif ve küçük teslim parçaları gerekli | ✓ | ||
Çok sayıda alternatif/istisna akışı var | ✓ | ||
Birden fazla aktör ya da sistem etkileşiyor | ✓ | ||
Hem değer hem uçtan uca davranış belirsiz | ✓ | ||
Düzenleme, güvenlik veya yüksek hata maliyeti var | ✓ | ||
Backlog birimi gerekirken davranış bağlamı da korunmalı | ✓ |
Bu tablo bir kural kitabı değil, tartışmayı başlatan bir karar desteğidir. Basit görünen bir işlem kritik iş kuralları barındırabilir; karmaşık görünen bir ihtiyaç ise önce değer hipotezinin sınanmasını gerektirebilir. Son kararı bağlam verir.
Seçimden önce sorduğumuz altı soru
Yıllar içinde teknik tartışmasını kısaltmak için altı sorunun yeterince ayırt edici olduğunu gördük:
Şu anda hangi belirsizliği azaltmaya çalışıyoruz? Değer mi, kapsam mı, davranış mı, kural mı?
Yanlış anlaşılmanın maliyeti nedir? Kolayca geri döndürülebilir mi, yoksa para, güvenlik, uyum veya itibar riski doğurur mu?
Kaç aktör ve sistem etkileşiyor? Sorumluluk geçişleri arttıkça akış modeline duyulan ihtiyaç artar.
Alternatif ve istisna yolları ne kadar yoğun? Mutlu yol dışındaki senaryolar işin önemli bölümünü oluşturuyorsa tek satır yetmez.
Ekip bir sonraki kararı verebilmek için ne kadar ayrıntıya ihtiyaç duyuyor? Gelecekte belki lazım olur diye ayrıntı üretmek yerine sıradaki kararı destekleyecek kadarını yazmak gerekir.
Bu bilgi nerede yaşayacak ve nasıl güncellenecek? Backlog, model, karar kaydı ve test varlıkları arasında sahiplik net değilse her format hızla eskir.
Soruların yanıtı “ikisini de kullanalım” diyorsa bu gereksiz bürokrasi anlamına gelmez. Aynı bilgiyi iki kez yazmak yerine farklı amaçlara hizmet eden kayıtları birbirine bağlamak gerekir: User Story değer ve teslimat dilimini, Use Case ise ilgili etkileşim derinliğini taşır.
Sahada en sık gördüğümüz dört hata
1. Şablonu ortak anlayış sanmak
“Bir kullanıcı olarak…” cümlesi doğru yazılmış olabilir; ama iş kuralı, kapsam sınırı ve doğrulama biçimi konuşulmadıysa ekipler yine farklı şeyler anlayabilir.
2. Use Case’i baştan sona doldurulacak form kabul etmek
Her alanı eksiksiz doldurmak kalite garantisi değildir. Henüz karar verilmemiş ayrıntıları kesinmiş gibi yazmak, yanlış güven ve bakım yükü doğurur.
3. İzlenebilirliği yalnızca Use Case’e, test edilebilirliği yalnızca User Story’ye vermek
Her iki teknik de uygun bağlantılar ve doğrulama ölçütleriyle izlenebilir ve test edilebilir hâle gelebilir. Bunlar formatın otomatik özelliği değil, analiz disiplininin sonucudur.
4. Seçimi ekip kimliği tartışmasına dönüştürmek
“Biz Agile ekibiz, Use Case yazmayız” veya “Biz kurumsal projeyiz, User Story bize uymaz” cümleleri bağlamı kapatır. Daha verimli soru şudur: Bu kararı güvenle verebilmek için hangi bilgiyi görünür kılmamız gerekiyor?
Sonuç: Doğru format değil, yeterli ortak anlayış
User Story ile Use Case arasında mutlak bir rekabet yoktur. User Story kullanıcı değerini, konuşmayı ve teslim edilebilir dilimi öne çıkarır. Use Case aktör–sistem etkileşimini, alternatifleri ve istisnaları görünür kılar. Biri diğerinin daha kısa ya da daha ayrıntılı sürümü değildir; farklı analiz sorularına cevap verirler.
Sahada en dayanıklı yaklaşımın şu olduğunu gördük: Önce ihtiyacı ve değeri görünür kıl, sonra yalnızca riskli veya belirsiz davranışı gerektiği kadar derinleştir. Bu bazen yalnızca User Story, bazen yalnızca Use Case, çoğu karmaşık üründe ise ikisinin bağlantılı kullanımı demektir.
Ekibinizde user story, backlog, kabul kriterleri ve lightweight dokümantasyon pratiğini geliştirmek istiyorsanız IIBA Agile İş Analizi Eğitimi programını; kullanım senaryosu, UML ve davranış modelleme tekniklerini uygulamalı çalışmak istiyorsanız IIBA İş Analizi Teknikleri Eğitimi programını inceleyebilirsiniz.
Sık Sorulan Sorular
User Story ile Use Case aynı ihtiyacı mı anlatır?
Aynı ihtiyacın farklı yönlerini anlatabilirler. User Story çoğunlukla kullanıcı değerini ve teslimat dilimini taşır; Use Case aktör ile sistem arasındaki etkileşim akışını ve dallanmaları açıklar.
Agile projede Use Case kullanılabilir mi?
Evet. Use Case’leri baştan sona ayrıntılandırmak yerine değerli senaryo dilimlerini gerektiği zaman ele almak çevik çalışmayla uyumludur. Use-Case 2.0 yaklaşımı bu kullanım biçimini sistematikleştirir.
Bir User Story için mutlaka Use Case yazmak gerekir mi?
Hayır. Basit, düşük riskli ve ekipçe ortak anlaşılan bir davranış için konuşma ve kabul kriterleri yeterli olabilir. Akış dallanıyor, aktör sayısı artıyor veya hata maliyeti yükseliyorsa Use Case ile derinleşmek anlamlıdır.
Kabul kriterleri Use Case’in yerini tutar mı?
Her zaman değil. Kabul kriterleri beklenen sonucu ve sınırları doğrulamak için güçlüdür; fakat uzun etkileşim zincirleri ile çok sayıda alternatif ve istisna yolunu tek başına açıkça göstermeyebilir.
Hangisi daha izlenebilir veya daha test edilebilirdir?
İzlenebilirlik ve test edilebilirlik yalnızca formata bağlı değildir. Her iki teknik de iş hedefleri, kurallar, tasarım kararları ve testlerle doğru bağlandığında izlenebilir ve doğrulanabilir olabilir.
