Ana sayfa → Bölüm 08
Epic, Story, Task: İşi Kırmanın Mantığı ve 8 Saat Kuralı
Tahtada bir kart var: “Ödeme entegrasyonu”. Üç gündür “devam ediyor” sütununda. Sorduğunda alınan cevap hep aynı: “bitmek üzere.” Bu yazı tam olarak o kart hakkında.
- Epic neden, story ne, task nasıl. Üçü aynı şeyin büyüğü küçüğü değil; farklı sorulara cevap veriyorlar.
- Task bir günü geçmemeli. Sebep tahmin değil görünürlük: iki günlük işin “yüzde altmışı” diye bir şey yok.
- Story dikey kesilir, task da öyle. “API”, “veritabanı”, “ekran” diye kırmak en kolay ama en kırılgan yöntem.
- Kıramıyorsan anlamamışsındır. Bu bir efor problemi değil, bir netlik problemi.
Önce şu üç kelimeyi yerine oturtalım
Çoğu ekipte epic, story ve task aynı şeyin farklı boylarıymış gibi kullanılıyor: büyükse epic, ortaysa story, küçükse task. Aslında öyle değil. Üçü farklı sorulara cevap veriyor ve bunu karıştırınca backlog bir anda anlamsızlaşıyor.
| Seviye | Sorduğu soru | Kim okur | Süre |
|---|---|---|---|
| Epic | Neden yapıyoruz? | İş tarafı, yönetim | Birkaç sprint |
| Story | Kim için ne çıkıyor? | PO, ekip, QA | Bir sprint içinde biter |
| Task | Nasıl yapacağız? | Sadece ekip | Bir günden az |
En kritik ayrım şurada: story tek başına canlıya çıkabilir, task çıkamaz. Bir story bittiğinde dışarıda bir kullanıcı bir işini yapabiliyor olmalı. Task bittiğinde ise sadece ekip bir şey biliyor. Bu tek cümle çoğu tartışmayı bitiriyor.
Gerçek bir örnek: iade süreci
Somut olalım. Bir e-ticaret sitesinde iadeler çağrı merkezi üzerinden yürüyor. Müşteri arıyor, temsilci sistemde elle iade kaydı açıyor. Günde 400 çağrı, her biri ortalama 4 dakika. İş tarafının derdi belli: bu yükü azaltmak.
Müşteri iadeyi kendi başlatabilsin.
Hedef: iade çağrılarının %60’ının kesilmesi. Tahmini süre 2–3 sprint. Bu satır nedeni taşıyor ve altı ay sonra “bu iş niye yapılmıştı” sorusunun cevabı burada duruyor. Epic tek başına teslim edilmez, kapanır.
Şimdi bunu story’lere bölelim. Dikkat: bölerken “önce arayüzü yapalım, sonra servisi” demiyoruz. Her parça kendi başına işe yarayacak şekilde kesiliyor:
- S1 — Müşteri olarak, teslim edilmiş bir siparişim için iade talebi oluşturabilmek istiyorum; böylece çağrı merkezini aramam gerekmez.
- S2 — Müşteri olarak, iade talebimin hangi aşamada olduğunu görebilmek istiyorum; böylece durumu sormak için aramam gerekmez.
- S3 — Temsilci olarak, gelen iade taleplerini tek listede görüp onaylayabilmek istiyorum; böylece her biri için ayrı ekran gezmem gerekmez.
- S4 — Müşteri olarak, iade kargo kodumu ekranda alabilmek istiyorum; böylece kargo şubesinde beklemem gerekmez.
Dördü de tek başına canlıya çıkabilir. Sadece S1 çıksa bile bir değer var: müşteri talebi açar, arkada temsilci elle işler. Çağrı yükü daha ilk sprint’te düşmeye başlar. İşte “dikey dilim” dediğimiz şey bu.
Şimdi task’lara inelim
S1’i alalım: “Müşteri iade talebi oluşturabilsin.” Çoğu ekibin yaptığı şey şu üç kartı açmak:
- Backend geliştirmesi 3 gün
- Frontend geliştirmesi 2 gün
- Test 1 gün
Üç kart, altı gün. Ve hiçbiri sprint ortasında sana bir şey söylemiyor.
- İade talebi tablosu + migration 3 sa
- POST /iade uç noktası, mutlu yol 5 sa
- İade uygunluk kuralı: 14 gün kontrolü 4 sa
- Uygun olmayan sipariş için hata cevabı 3 sa
- İade formu ekranı (statik) 5 sa
- Formu uca bağlama + hata gösterimi 4 sa
- Temsilciye bildirim e-postası 3 sa
İkinci listede toplam süre aynı. Değişen tek şey görünürlük. İkinci gün daily’de artık “backend’e devam” değil, “uç nokta ve kural bitti, hata cevabındayım” cevabını alıyorsun. Sprint’in yarısında tahtaya baktığında gerçekten nerede olduğunu görüyorsun.
8 saat kuralı: neden bir günü geçmemeli
Kural basit: hiçbir task bir günden uzun olmasın. Bunu bir tahmin disiplini sanmak yaygın bir yanlış. Asıl sebep dört tane ve dördü de tahminle ilgili değil.
- İlerleme ölçülemez hale gelir. Üç günlük bir işin “yüzde altmışı” diye bir şey yoktur; o yüzde bir histir. Tek günlük task’ta iki durum vardır: bitti ya da bitmedi. His yok.
- Takılma geç fark edilir. Üç günlük task’ta insan ikinci günün sonuna kadar “hallederim” der. Tek günlük task’ta ertesi sabah bitmediyse bu herkesin gördüğü bir sinyaldir.
- Tahmin hatası büyür. Bir günlük tahminde yanılma payın saatlerle ölçülür. Beş günlük tahminde günlerle. Aynı belirsizlik, farklı fatura.
- İş devredilemez. Biri hastalanınca üç günlük yarım task’ı başkasına vermek neredeyse imkânsızdır. Bir günlük parçalarda devretme mümkün.
Ve bunun bir yan etkisi var, en sevdiğim kısmı da bu: bir işi bir günlük parçalara kıramıyorsan, o işi henüz anlamamışsındır. Kıramama bir efor problemi gibi görünür ama değildir; netlik problemidir. O yüzden “bu kırılmıyor abi” cümlesi bir itiraz değil, bir teşhistir. Cevabı da bellidir: önce anlaşılacak.
Task nasıl kırılır? Altı kesme yöntemi
1. Akışa göre: önce mutlu yol
Her şeyin yolunda gittiği senaryoyu ayrı, hata durumlarını ayrı task yap. Yukarıdaki örnekte “POST /iade mutlu yol” ve “uygun olmayan sipariş için hata cevabı” bu şekilde ayrıldı. Mutlu yol bitince gösterecek bir şeyin olur; hata yolları da tek tek bitirilebilir.
2. Veriye göre: önce bir tip
Beş farklı ödeme tipi mi var? İlk task sadece kredi kartı olsun. Kalanlar ayrı task’lar. Genelde ilk tip mimariyi kurar, diğerleri ikişer saat sürer. Bunu tersten yapan ekipler “hepsini birden düşünelim” deyip iki hafta soyutlama tasarlıyor.
3. Kurala göre: önce basit hal, sonra istisnalar
“14 gün içinde iade edilebilir” bir task. “Kampanyalı ürünlerde 7 gün, hijyenik ürünlerde iade yok” ayrı bir task. Kural istisnaları neredeyse her zaman tahmin edilenden uzun sürer; ana kuralla aynı karta koymak o kartı şişirir.
4. İşleme göre: önce okuma, sonra yazma
Listeleme ve görüntüleme genelde hızlıdır ve hemen değer üretir. Oluşturma, güncelleme ve silme ayrı ayrı gider. Bir CRUD ekranını tek task yapmak klasik bir üç günlük kart üretme yöntemidir.
5. Arayüz ile servisi ayır — ama dikkatli
Bunu yapabilirsin, sadece şartı var: ekranı statik veriyle bitirip gösterilebilir hale getir, sonra bağla. Böylece iki task da tek başına “bitmiş” sayılabilir. Şartı sağlamadan “önce backend, sonra frontend” diye kırarsan sprint’in son gününe kadar ortada gösterilecek hiçbir şey olmaz.
6. Bilinmeyeni ayır: araştırma ayrı bir madde
“Kargo firmasının API’si nasıl çalışıyor bilmiyoruz” bir geliştirme task’ı değildir. Ayrı bir araştırma maddesi olur, süresi baştan sınırlanır (örneğin 4 saat) ve çıktısı koddur değil karardır. Bunu ayırmayan ekiplerde “5 saatlik” task iki gün sürer ve kimse sebebini anlamaz; sebep koddaki zorluk değil, cevabı olmayan sorudur.
“Veritabanı”, “servis”, “ekran” diye kırmak en kolayı ve en yaygını. Sorun şu: hiçbiri tek başına çalışmaz. Üçü de bitmeden ortada gösterilecek bir şey yoktur ve entegrasyonda çıkan sürpriz — ki çıkar — sprint’in son gününe denk gelir. Katmanlı kırmak istiyorsan bari ince bir dikey dilimi baştan sona götür: tek alanlı bir form, tek uç nokta, tek kayıt.
Sık düşülen üç tuzak
| Kart | Sorun | Ne yapmalı |
|---|---|---|
| “Analiz” task’ı | Bitiş ölçütü yok, her zaman uzar | Süresi sınırlı araştırma maddesi yap, çıktısı bir karar olsun |
| Sona konan “Test” task’ı | Sprint sonunda QA boğulur, hata düzeltmeye vakit kalmaz | Testi her task’ın bitiş tanımına göm; ayrı kart açma |
| “Refactor” task’ı | Sınırı belirsiz, üç gün sürer, kimse ne olduğunu bilmez | Dokunulacak sınıfı ve amacı adıyla yaz: “SiparisServisi’ni iki servise böl” |
Story ne zaman büyümüş sayılır?
Pratik ölçü: bir story’nin task’ları bir sprint’e sığmıyorsa o artık story değil, küçük bir epic’tir. Bölmek gerekir. Genelde bölünecek yer belli olur: “ve” kelimesinin geçtiği yer. “Müşteri iade talebi oluşturabilsin ve durumunu takip edebilsin” cümlesindeki “ve” aslında iki story olduğunu söylüyor.
Tersi de geçerli: bir task tek başına canlıya çıkıp bir kullanıcının işini görüyorsa onu task olarak tutmanın anlamı yok, story yap. Seviyeler kutsal değil; amaç doğru soruyu doğru yerde sormak.
Kontrol listesi
- Bu bir story mi? Tek başına canlıya çıksa birinin işine yarar mı?
- Task’ların hepsi 8 saatin altında mı?
- Kartın adında ne yapılacağı yazıyor mu, yoksa “X geliştirmesi” mi?
- Bilinmeyen bir şey varsa ayrı ve süresi sınırlı bir araştırma maddesi açıldı mı?
- Ayrı bir “test” kartı var mı? (Varsa kaldır, bitiş tanımına koy.)
- İlk gün sonunda QA’e verilebilecek bir task var mı?
- Story’nin metninde “ve” geçiyor mu? (Geçiyorsa muhtemelen ikiye bölünecek.)
Sonuç
İş kırmak bir Jira alışkanlığı değil, bir düşünme biçimi. Kartları küçültmenin amacı tahtayı kalabalıklaştırmak değil, her sabah gerçekte nerede olduğunu görebilmek.
Ve başa dönelim: o üç gündür “devam ediyor” yazan “Ödeme entegrasyonu” kartı aslında yedi ayrı task’tı. Kırılmadığı için üçü bitmiş, biri takılmış, üçüne hiç başlanmamıştı — ve bunu kimse göremiyordu. Kart bir taneydi çünkü.
Story’lerin nasıl yazılacağı ve kabul kriterlerinin nereye kadar detaylanacağı Grooming bölümünde; task’ların sprint içinde nasıl çekileceği Sprint Planning bölümünde.