Uygulama Geliştirmede Backlog: Nedir, Yapısı ve Görev Yönetimi
Backlog — bir projede uygulanması gereken tüm görevlerin, gereksinimlerin ve iyileştirmelerin sıralı bir listesidir. Çevik metodolojilerin merkezi bir yapıtıdır: Scrum'da backlog Product Owner tarafından yönetilir, Kanban'da — tüm ekip tarafından. Scrum Guide, 2020'ye göre, backlog asla tamamlanmaz: ürün ve pazar talepleriyle birlikte sürekli gelişir.
Temel Noktalar
- Backlog — öncelik ve yürütmeye hazır olma durumuna göre sıralanmış tüm proje görevlerinin listesi.
- Ana öğeler — kullanıcı hikayeleri, hatalar, teknik borç, araştırmalar ve iyileştirme görevleri.
- Önceliklendirme — anahtar süreç: backlog'un üstündeki görevler en önemli ve sprint'e hazır olanlardır.
- Product Owner — backlog'un sahibi, içeriğinden ve önceliklerinden sorumludur.
- Grooming (refinement) — backlog öğelerini netleştirme, tahmin etme ve yeniden önceliklendirme için düzenli bir aktivite.
Geliştirmede Backlog Nedir?
Backlog — üründeki tüm değişiklikler için tek bir gereksinim kaynağıdır. Product Owner, içeriğinden, kullanılabilirliğinden ve şeffaflığından sorumludur: ekip üyelerinin her biri, backlog'da hangi görevlerin olduğunu ve hangi sırayla uygulanacağını anlamalıdır.
Product Backlog ve Sprint Backlog Arasındaki Fark
Product Backlog gelecek için tüm proje görevlerini içerir — önümüzdeki çeyreğin özelliklerinden yılın fikirlerine kadar. Sprint Backlog, ekibin mevcut sprint'e aldığı Product Backlog'taki görevlerin bir alt kümesidir. Sprint Backlog sprint boyunca dondurulurken, Product Backlog sürekli değişir.
Scrum vs Kanban'da Backlog
In Scrum'da backlog sıkı bir şekilde yapılandırılmıştır: Product Backlog ve Sprint Backlog vardır, görevler story point olarak tahmin edilir, sprint'ler sabit uzunluktadır. Kanban'da backlog daha esnektir: görevler geliştiriciler müsait oldukça çekilir, öncelikler günlük değişebilir ve WIP (work in progress) limitleri görev akışını düzenler.
Backlog Öğeleri: Nelerden Oluşur
Kaliteli bir backlog, yalnızca yeni özellikler değil, çeşitli türde görevler içerir. Dengeli bir backlog, ürün geliştirmenin tüm yönlerini dikkate alır.
| Öğe Türü | Açıklama | Örnek |
|---|---|---|
| User Story | Kullanıcı bakış açısından yeni işlevsellik | “Kullanıcı olarak, şifremi sıfırlamak istiyorum” |
| Bug | Mevcut işlevsellikte kusur veya hata | “Kayıt butonu iOS 16'da çalışmıyor” |
| Tech Debt | Kullanıcıya görünmeyen kod tabanı iyileştirmesi | “Bağımlılıkları en son sürümlere güncelle” |
| Spike / Research | Belirsizliği azaltmak için araştırma veya prototip | “Jetpack Compose'a geçiş olasılığını araştır” |
| Improvement | Süreç veya altyapı iyileştirmesi | “Otomatik derlemeler için CI/CD kurulumu” |
User Story Ana Öğe Olarak
Backlog'un ana yapı taşı User Story'dir (kullanıcı hikayesi). Kaliteli bir User Story, hangi teknik eylemlerin yapılması gerektiğini değil, kullanıcının elde edeceği değeri açıklar. INVEST formatı: Independent, Negotiable, Valuable, Estimable, Small, Testable. Bir hikaye bir sprint'e sığmalıdır, aksi takdirde parçalanması gerekir.
Kabul Kriterleri
Kabul kriterleri, bir görevin ne zaman tamamlanmış sayılacağını belirler. Given-When-Then formatında veya basit bir koşul listesi olarak yazılırlar. Örneğin: “Kullanıcı e-posta ile şifresini sıfırlayabilir, e-posta 30 saniye içinde gelir, bağlantı 24 saat geçerlidir.” Net kabul kriterleri, demo aşamasındaki anlaşmazlıkları ortadan kaldırır.
Backlog Önceliklendirmesi: Yöntemler ve Yaklaşımlar
Önceliklendirme, backlog yönetiminin en önemli ve karmaşık sürecidir. Product Owner, iş değeri, çaba, riskler ve görevler arası bağımlılıkları dikkate almalıdır.
MoSCoW: Must-Should-Could-Won't
MoSCoW klasik bir önceliklendirme yöntemidir. Must have — görev ürün için kritiktir. Should have — ertelenebilecek önemli bir görev. Could have — yapılması iyi olacak bir iyileştirme. Won't have — geleceğe ertelenen görevler. Dağılım: %60 Must, %20 Should, %20 Could. Yöntem, kritik işlevselliğe odaklanmaya yardımcı olur.
Değer vs Çaba Matrisi
Değer vs Çaba Matrisi görevleri dört çeyreğe ayırır: Quick Wins (yüksek değer, düşük çaba) — önce yap, Big Bets (yüksek değer, yüksek çaba) — önceden planla, Fill-ins (düşük değer, düşük çaba) — arada yap, ve Avoid (düşük değer, yüksek çaba) — yapma. Bu yaklaşım, sınırlı kaynaklarla değeri en üst düzeye çıkarır.
Weighted Shortest Job First (WSJF)
WSJF, SAFe'den bir önceliklendirme yöntemidir ve şu formüle dayanır: değer / görev boyutu. Değer-boyut oranı ne kadar yüksekse, öncelik o kadar yüksektir. WSJF, iş değerini, zaman kritikliğini ve riskleri dikkate alır. Yöntem, büyük backlog hacmine sahip olgun ürün ekipleri için uygundur.
Backlog Nasıl Yönetilir: En İyi Uygulamalar
Etkili backlog yönetimi düzenli aktiviteler, doğru araçlar ve tüm ekibin disiplinini gerektirir.
Backlog Refinement (Grooming)
Refinement, ekibin backlog öğelerini netleştirdiği, tahmin ettiği ve yeniden önceliklendirdiği düzenli bir toplantıdır (genellikle haftada bir). Scrum Guide, refinement için ekip zamanının %10'undan fazlasını harcamamayı önerir. Sonuç: backlog'un üst %20-30'u sprint planlaması için hazırdır — tahminler, kabul kriterleri ve onayları vardır.
Backlog İçin DEEP Kuralları
- Detailed appropriately — yakın görevler detaylıdır, uzak olanlar sadece fikirdir.
- Estimated — tüm üst düzey görevler story point veya saat olarak tahmin edilmiştir.
- Emergent — backlog sürekli değişir: görevler eklenir, kaldırılır, yeniden önceliklendirilir.
- Prioritized — her görevin kendi sırası vardır, hiçbir görev aynı önceliği paylaşmaz.
Backlog Yönetimi İçin Araçlar
Backlog yönetimi için en popüler araçlar: Jira (esnek iş akışı yapılandırmasıyla endüstri standardı), Linear (hızlı ve modern izleyici), Trello (küçük ekipler ve Kanban için), Notion (veritabanlarıyla esnek çalışma alanı) ve YouTrack. Araç seçimi ekip büyüklüğüne, metodolojiye ve bütçeye bağlıdır.
Backlog Yönetiminde Yaygın Hatalar
Deneyimli Product Owner'lar bile ekip etkinliğini ve ürün kalitesini düşüren backlog yönetiminde hatalar yapar.
Backlog'un Fikir Çöplüğü Olması
En yaygın hata, filtreleme veya önceliklendirme yapmadan tüm fikirleri backlog'a atmaktır. Backlog yüzlerce göreve ulaşır ve gezinmek imkansız hale gelir. Çözüm: backlog'u düzenli olarak temizleyin — eski görevleri kaldırın, benzerlerini birleştirin, acil olmayanları erteleyin. Sağlıklı bir backlog binlerce değil, 50-100 öğe içerir.
Teknik Görevlerin Eksikliği
Backlog yalnızca User Story'lerden oluştuğunda, teknik borç büyür ve altyapı iyileştirmeleri ertelenir. Er ya da geç ekip, güncel olmayan bağımlılıklar, test eksikliği veya mimari sorunlar nedeniyle performans sınırına ulaşır. Kural: bir sprint'teki görevlerin %20'si teknik olmalıdır — yeniden düzenleme, testler, güncellemeler.
Aşırı Detaylı Uzun Vadeli Backlog
3-6 ay ilerideki görevleri detaylandırmak zaman kaybıdır. Gereksinimler değişir, pazar gelişir ve detaylı görevler yeniden yazılmak zorunda kalır. Yalnızca önümüzdeki 1-2 sprint'e girecek görevleri detaylandırın. Uzak görevler için bir başlık ve kısa bir açıklama yeterlidir.
Hataları Görmezden Gelmek
Küçük hatalar, “zaman yok” veya “sonra düzeltiriz” diye backlog'a girmez. Zamanla hatalar birikir, kalite düşer ve ürün kullanıcı güvenini kaybeder. Kural: önceliği düşük olsa bile her hata backlog'a kaydedilir. Hatalar birikmişse — bunları düzeltmek için bir sprint ayırın.
Sıkça Sorulan Sorular
Product Backlog ile Sprint Backlog arasındaki fark nedir?
Product Backlog, Product Owner tarafından yönetilen, uzun vadeli tüm proje görevlerinin tam listesidir. Sprint Backlog, ekibin mevcut sprint'e aldığı Product Backlog'taki görevlerin bir alt kümesidir. Sprint Backlog sprint boyunca dondurulurken, Product Backlog sürekli değişir.
Scrum'da backlog'dan kim sorumludur?
Backlog'dan Product Owner sorumludur. Öncelikleri belirler, görevleri formüle eder ve öğelerin sprint için ne zaman hazır olduğuna karar verir. Geliştiriciler değişiklik önerebilir, teknik görevler ekleyebilir ve karmaşıklığı tahmin edebilir, ancak önceliklerle ilgili nihai karar Product Owner'a aittir.
Backlog grooming ne sıklıkta yapılmalıdır?
Grooming haftada bir veya en az sprint başına bir kez önerilir. Scrum Guide, geliştiricilerin zamanının %10'undan fazlasının refinement'a harcanmamasını önerir. İki haftalık bir sprint için bu haftada yaklaşık 1-2 saattir. Düzenli grooming, backlog'da “çöp” birikmesini önler.
Bir backlog kaç öğe içermelidir?
Sağlıklı bir Product Backlog 50-100 öğe içerir. Daha azı, ekibin geleceği düşünmediği anlamına gelir; daha fazlası, backlog'un çöplüğe dönüştüğü anlamına gelir. Önemli olan öğe sayısı değil, kalitesidir: üst %20-30'u sprint'e hazır olmalı, geri kalanı farklı detay seviyelerinde olabilir.
Sprint sırasında backlog değiştirilebilir mi?
Product Backlog her zaman değiştirilebilir — bu onun normal durumudur. Ancak Sprint Backlog, ekibin hedefe odaklanabilmesi için sprint boyunca dondurulur. Tek istisna: Product Owner'ın bir görevi artık alakalı olmadığı için sprint'ten kaldırmasıdır.
Özet
- Backlog — Product Owner tarafından yönetilen, projedeki tüm değişiklikler için tek gereksinim kaynağı.
- Ana öğeler — User Story'ler, hatalar, teknik borç, araştırmalar, süreç iyileştirmeleri.
- Önceliklendirme — PO'nun temel becerisi: MoSCoW, Değer vs Çaba, WSJF yöntemleri öncelikleri belirlemeye yardımcı olur.
- DEEP kuralları — backlog ayrıntılı, tahmin edilmiş, ortaya çıkan ve önceliklendirilmiş olmalıdır.
- Grooming — üst düzey görevleri netleştirme ve tahmin etme için haftalık aktivite.
- Yaygın hatalar — fikir çöplüğü, teknik görev eksikliği, aşırı detaylandırma, hataları görmezden gelme.
- Sağlıklı boyut — 50-100 öğe, üst %30'u sprint'e hazır.
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun