Definition of Ready vs Done (DoR & DoD): Her Agile Takımın İhtiyacı Olan Kalite Kapıları
Özet
- “Hazır” (Ready) Kuralı: Eğer Planlama’da “bu ne anlama geliyor?” diye sormanız gerekiyorsa, o iş hazır değildir. Sprint’ten atın. İstisna yok.
- ”Bitti” (Done) Kuralı: Kod derlendiğinde bitmiş sayılmaz. Kendimi utandırmadan bir kullanıcıya sunabildiğimde bitmiş sayılır.
- Anlaşma (The Pact): Bunlar yönetimin dayattığı kurallar değildir. Takım ile gerçeklik arasındaki anlaşmalardır.
- Seri Bağlantısı: Eğer Refinement, Grooming ve Teknik Analiz’i düzgün yaptıysanız, DoR neredeyse otomatiktir. Yapmadıysanız, hiçbir kontrol listesi sizi kurtarmaz.
O hissi bilirsiniz: Sprinte bir iş alırsınız ve üç gün sonra biri “Bir dakika, bu mobil desteği de içeriyor muydu?” diye sorar. Bu bir gereksinim sorunu değildir. Bu bir disiplin sorunudur. “Hazır” ve “Bitti” tanımlarına bürokratik onay kutuları gibi davranıyoruz. Öyle değiller. Onlar, sizinle kaotik, hiç bitmeyen bir sprint arasında duran tek engeldir. Ve çoğu kişinin gözden kaçırdığı nokta şudur: DoR ve DoD tek başına var olmazlar. Bu seride ele aldığımız her seremoninin doğal çıktısıdırlar—Refinement’ın filtrelemesinden Teknik Analiz’in ayrıştırmasına kadar. Eğer önceki fazlar çalışıyorsa, bu tanımlar neredeyse kendini yazar.
Agile Serisi — Kopya Kağıdı’nın 10. Bölümü.
Tüm Seri DoR & DoD’a Nasıl Besleniyor?
Kontrol listelerine dalmadan önce, Agile döngüsündeki her fazın bu tanımlarla nasıl bağlantılı olduğunu görelim. Çoğu takımın kaçırdığı büyük resim budur:
Refinement (Seri #2) → DoR
Peçete arkası ROI hesaplaması zaten yapılmıştır. Fikir filtreyi geçmiştir. Eğer Refinement’ı geçemediyse, backlog’da bile olmaması gerekir, “Hazır” olmak bir yana.
Grooming (Seri #3) → DoR
PO vizyonu sattı. Takım ne istendiğini ve neden değerli olduğunu anlıyor. Bağlam aktarılmıştır. Eğer takım Grooming’den kafası karışık çıkmışsa, o iş Hazır değildir.
Teknik Analiz (Seri #4) → DoR
Takım işi teknik tasklara ayrıştırdı. API kontratları tanımlandı. QA kodlama başlamadan önce test senaryolarını yazdı. Riskler pre-mortem’de gün yüzüne çıkarıldı. Eğer Teknik Analiz düzgün yapıldıysa, o iş tanım gereği Hazırdır.
INVEST (Seri #9) → DoR
Hikaye Bağımsız, Pazarlık Edilebilir, Değerli, Tahmin Edilebilir, Küçük ve Test Edilebilirdir. Herhangi bir INVEST kriterinde başarısız oluyorsa, Hazır değildir.
Daily Standup (Seri #6) → DoD
Burndown grafiği sadece bir madde “Bitti” olarak işaretlendiğinde düşer—kod lokal ortamda çalıştığında değil. DoD, o grafiğin ne zaman hareket ettiğini belirler.
Sprint Review (Seri #8) → DoD
Sadece DoD’u karşılayan maddeler paydaşlara gösterilir. Eğer DoD’u geçemediyse, Review’a girmez. Nokta.
Retrospektif (Seri #7) → DoR ve DoD Evrimi
Tanımlar taşa yazılmış değildir. Retro, bunları öğrendiklerinize göre gözden geçirip evrimleştirdiğiniz yerdir.
Definition of Ready (DoR) - Hazır Tanımı
Hazır Tanımı (DoR), bir backlog maddesinin bir sprinte girebilmesi için karşılanması gereken koşulların kontrol listesidir.
DoR Neden Var: Başlamadan Kaybetmeyi Durdurun
DoR olmadığında ne olur biliyor musunuz? Her sprint bir piyango. Bir sprint düzgün gider çünkü PO o hikayeyi tesadüfen iyi anlatmıştır. Sonraki sprint, başka bir PO yarım yamalak bir fikir atar ve takım üç günü sadece “aslında ne isteniyor?” sorusunu anlamaya harcar. Tanıdık geldi mi?
Sorun şanssızlık değil. Sorun hazırlık için bir standardın olmaması. DoR yoksa, bireysel çabaya ve umuda bel bağlıyorsunuz. Bazı sprintler çalışır, bazıları çalışmaz ve kimse nedenini açıklayamaz. DoR rastgeleliği ortadan kaldırır. Der ki: “Standart bu. İş bu standardı karşılamıyorsa, sprint’e girmez. Nokta.” Standardınız olduğunda, verilen sözler tutulabilir hale gelir. Olmadığında, her sprint farklı bir sürprizle gelir. DoR bürokrasi değildir—sprint başlamadan ekibinizi başarısızlığa mahkum etmemektir.
Örnek DoR
Net Kullanıcı Hikayesi (INVEST Uyumlu)
Hikaye “Bir… olarak, şunu istiyorum… böylece…” formatını net bir değer ile takip eder. Altı INVEST kriterinin tamamını geçer—özellikle Küçük ve Test Edilebilir.
Kabul Kriterleri Tanımlanmış
Başarıyı tanımlayan spesifik, test edilebilir kriterler. “İyi çalışsın” gibi belirsiz dilekler değil.
Teknik Analiz Tamamlandı
Takım işi ayrıştırmıştır. DB değişiklikleri, API kontratları ve refactoring ihtiyaçları belgelenmiştir. Gri alanlar ortadan kaldırılmıştır.
QA Test Senaryoları Yazılmış
QA kodun yazılmasını beklemez. Sprint başlamadan önce test senaryoları mevcuttur—geliştiriciler tam olarak neyin test edileceğini bilir.
Bağımlılıklar Belirlenmiş
Dış bağımlılıklar (API’ler, diğer takımlar, üçüncü partiler) bilinir, planlanmış ve azaltma planı vardır.
UX/Tasarım Hazır
Eğer varsa, mockup’lar veya tasarımlar onaylanmış ve erişilebilir. “UI’ı sonra hallederiz” diye bir şey yok.
Gerçek Hayat Örneği: Ürün Listeleme Sayfası
INVEST yazısındaki ürün listeleme sayfasını hatırlıyor musunuz? DoR’u ona uygulayalım. Eğer biri sprint’e “Ürün listeleme ve filtrelemeyi uygula” diye atarsa, sorun: Hazır mı?
Definition of Done (DoD) - Bitti Tanımı
Bitti Tanımı (DoD), bir maddenin tamamlanmış sayılabilmesi için karşılanması gereken kalite kriterlerinin kontrol listesidir. Sprint Review’da bir şeyin gösterilip gösterilemeyeceğini belirleyen kapı budur.
DoD Neden Var: Ekip Anayasası
Kesinlikle tanık olduğunuz bir sahneyi anlatayım: Bir geliştirici bir ticket’ı “Bitti”ye taşır ve der ki “Kodu yazdım, deploy ettim.” Sonra QA üç bug bulur. Sonra biri fark eder ki hiç log yok. Sonra özellik gece yarısı production’da patlar ve kimsenin haberi olmaz çünkü alarm yok. “Ama ben kodu yazdım!” Evet. Ve sorun da tam olarak bu.
“Ben kendi kısmımı yaptım” bireysel bir zihniyettir. DoD ise takım zihniyetidir. Bir takım kod teslim etmez—bir takım çalışan, test edilmiş, izlenebilir, geri alınabilir bir ürün artımı (increment) teslim eder. Eğer artım DoD’a göre teslim edilemiyorsa, bu başarısızlığın sahibi tüm takımdır—sadece geliştirici değil, sadece QA değil, sadece DevOps değil. Herkes.
DoD’u ekibinizin anayasası olarak düşünün. Yukarıdan dayatılan kurallar değil, takımın kendisiyle yaptığı bir anlaşma: “‘Bitti’ bizim için bunu ifade eder. Köşe kesmeyiz. Erken zafer ilan etmeyiz. Bu standardı karşılamıyorsa, bitti değildir—kodu kim yazmış olursa olsun.” Bir takım bunu gerçekten içselleştirdiğinde, “kodu yazdım” artık bir bitiş çizgisi olmaktan çıkar ve bir kontrol noktası olur. Bitiş çizgisi şudur: “Bunu şu anda kullanıcıya sunabilir ve gece rahat uyuyabiliriz.”
Örnek DoD
Kod Tamamlandı
Tüm uygulama bitti ve takımın kod standartlarına uyuyor.
Testler Geçiyor
Birim testleri, entegrasyon testleri ve gerekli E2E testleri yeşil. Bu pazarlığa kapalıdır—Teknik Analiz’de anlattığımız gibi, QA kodlamadan önce hedefi tanımlamıştı.
Kod Gözden Geçirildi
En az bir akran değerlendirmesi (peer review) tamamlandı ve geri bildirimler ele alındı. Göstermelik onay yok.
Dokümantasyon Güncellendi
Gerekirse API dokümanları, README veya kullanıcıya dönük belgeler güncellendi.
Gözlemlenebilirlik Yerinde
Üretim izleme için loglar, metrikler ve alarmlar yapılandırıldı. Gece 3’te bozulursa, birisi bunu bilir.
Staging'e Dağıtıldı
Staging ortamına başarıyla dağıtıldı ve doğrulandı. “Derleniyor” yeterli değil.
Yayım Planı Tanımlandı
Feature toggle’lar, kademeli yayım veya geri alma stratejisi belgelendi. INVEST yazısında tartıştığımız gibi: canlıya çıkmak (deploy), kullanıma açmak (release) demek değildir. Feature Toggle, Bitti Tanımınızın bir parçasıdır.
DoR vs DoD: Yan Yana
Sprint Öncesi
Maddelerin sprinte giriş kapısı. Takımı belirsiz işlerden korur. Eğer Refinement, Grooming ve Teknik Analiz görevini yaptıysa, bu kapıdan geçmek kolaydır.
Sprint Sonu
Maddelerin sprintten çıkış kapısı. Tutarlı kaliteyi sağlar. Sprint Review’da neyin gösterileceğini ve burndown grafiğinde neyin hareket edeceğini belirler.
| Yön | Definition of Ready (DoR) | Definition of Done (DoD) |
|---|---|---|
| Ne zaman kontrol edilir | Planlamadan önce | Tamamlandı işaretlemeden önce |
| Sahibi kimdir | Ürün Sahibi + Takım | Geliştirme Takımı |
| Amacı | Belirsiz işi önlemek | Kaliteyi sağlamak |
| Başarısızlık modu | Sprint ortasında sürprizler | Yayına alınamayan “Bitmiş” iş |
| Beslenen kaynak | Refinement, Grooming, Teknik Analiz, INVEST | Kod standartları, test, CI/CD, feature toggle’lar |
Takım Boyutuna Göre Uyarlama
Küçük Takım
Hafif DoR/DoD. Güven ve sözlü anlaşmalar işler. Her birini 3-4 maddede tutun. Aşırı süreç küçük takımları boğar.
Standart Takım
Açık kontrol listeleri. Üç ayda bir Retro’larda belgeleyin ve gözden geçirin. Titizliği hızla dengeleyin. Çoğu takım için en uygun nokta burasıdır.
Büyük Takım
Resmi DoR/DoD. Mümkünse otomatik kontroller (CI/CD kapıları, linter kuralları, kapsam eşikleri). Bu liste 10 maddeyi geçiyorsa takımı bölmeyi düşünün.
Sık Yapılan Hatalar
Çok Fazla Kriter
20 maddelik listeler “onay kutusu tiyatrosuna” döner. 5-7 temel maddede tutun. Her şey önemliyse, hiçbir şey önemli değildir.
Asla Güncellenmemesi
DoR/DoD evrimleşmelidir. Retro geri bildirimlerine göre gözden geçirin ve ayarlayın—Seri #7 (Retrospektif) tam olarak bunun içindir.
Baskı Altında Göz Ardı Edilmesi
“Bu sprint testleri atlayalım.” Bu amacı bozar. Tanımlar pazarlığa kapalıdır. Bir teslim tarihi için onları esnettiğiniz an, anlamsız hale gelirler.
Paydaşlara Görünmez Olması
Eğer paydaşlar DoD’u bilmezse, gönderilebilir (shippable) olmayan bir “bitti” için zorlarlar. DoD’u Sprint Review’da paylaşın ki herkes “bitti”nin ne anlama geldiğini bilsin.
Kalıcı Kılmak
Definition of Done, Increment’in (Artım) parçası olarak hangi işin tamamlandığına dair herkese ortak bir anlayış sağlayarak şeffaflık yaratır. Eğer bir Product Backlog maddesi Definition of Done’ı karşılamıyorsa, yayınlanamaz (released).
Sonuç
DoR ve DoD, bir kere yazıp unutacağınız tek başına duran belgeler değildir. İyi işleyen bir Agile döngüsünün doğal çıktılarıdır. Eğer Refinement fikirleri düzgün filtreliyorsa, Grooming bağlamı aktarıyorsa, Teknik Analiz gri alanları ortadan kaldırıyorsa ve INVEST hikaye kalitesini sağlıyorsa—DoR kendini yazar. Eğer kod standartlarınız, test kültürünüz, CI/CD hattınız ve feature toggle stratejiniz sağlamsa—DoD kendini yazar. Basit başlayın, tutarlı bir şekilde uygulayın ve Retro’larda evrimleştirin. Doğru yapıldığında, bu tanımlar görünmez hale gelir—çünkü kalite varsayılan (default) olur.