Definition of Done Nedir? Ekiplerin En Çok Yanlış Yaptığı Scrum Pratiği

Sprint bitti. Ekip 'done' dedi. Feature canlıya çıktı. Üç saat sonra P1 bug bildirimi geldi. Testler çalıştırılmamıştı. Deployment script güncellenmemişti. Bir manuel adım atlanmıştı.

Kimse kasıtlı yapmamıştı. Sadece herkesin 'done' için farklı bir tanımı vardı.

Definition of Done tam bu karmaşayı çözmek için var. Ama çoğu ekipte ya hiç yok ya da kağıt üzerinde kalıyor. Bu yazıda DoD'un ne olduğunu, nasıl yazılacağını ve neden bu kadar kritik olduğunu konuşacağız.

Definition of Done (DoD), bir sprint'teki her Product Backlog Item'ın (PBI) 'tamamlanmış' sayılabilmesi için karşılaması gereken kriterlerin resmi listesidir.

2020 Scrum Guide şöyle tanımlıyor: 'Definition of Done, bir Increment'in ürün için gereken kalite ölçütlerini karşıladığındaki durumunun resmi tanımıdır.'

Bu 'developer kodu commit etti' demek değildir. 'Releasable — şu an canlıya çıkarmaya hazır' demektir. Sprint Review'da gösterilebilir, paydaşlara teslim edilebilir kalitede.

DoD tüm ekip için geçerlidir. Her story için ayrı ayrı yazılmaz. Her story için kontrol edilir.

Bu iki kavram Scrum'da en sık karıştırılan ikililerden biridir. Farkı net anlamak kritik.

Acceptance Criteria (Kabul Kriterleri): O story'e özgüdür. 'Kullanıcı şifremi sıfırladığında onay e-postası almalıdır.' Product Owner yazar. Her story için farklıdır. Story tamamlandığında kontrol edilir.

Definition of Done: Tüm ekip için geçerlidir. 'Her kod değişikliği code review'dan geçmeli.' Ekip birlikte yazar. Her story için aynıdır. Her story için kontrol edilir.

Analoji: Acceptance criteria 'Bu yemeği nasıl yapmak istiyorsunuz?' sorusunu yanıtlar. DoD ise 'Mutfağımızın hijyen ve kalite standartları nelerdir?' sorusunu.

Definition of Done olmayan ekiplerde tablo genellikle şöyle:

'Done' denen ama aslında test edilmemiş, deploy hazırlığı yapılmamış story'ler sprint sonunda listeye ekleniyor. Velocity şişiyor çünkü yarım işler done sayılıyor.

Birkaç sprint sonra 'neden bu kadar bug var?' sorusu geliyor. Yanıt genellikle şu: 'Done' tanımı yoktu veya kimse uygulamıyordu.

Scrum Guide buna 'undone work' diyor — görünmez teknik borç. Backlog'da görünmüyor. Sprint review'da konuşulmuyor. Ama canlıda patlıyor.

Undone work en tehlikeli borç türüdür: ne kadar olduğunu bilmiyorsunuzdur.

Soyut maddeler işe yaramaz. 'Kalite sağlanmalı' diye bir DoD maddesi var ama 'kalite' ne demek? Her madde somut ve kontrol edilebilir olmalı.

Tipik bir yazılım ekibi için örnek DoD:

Bu liste bir başlangıç noktasıdır. Ekibinizin teknik yapısına, deployment sürecine ve kalite standartlarına göre uyarlanmalıdır.

DoD'u Scrum Master tek başına yazmamalı. Product Owner da tek başına. Bu bir ekip çıktısıdır. Şu workshop formatı pratikte işe yarıyor:

1. DoD hiç yok: 'Zaten biliyoruz' deniyor. Ama herkesin 'bildiği' farklı. Yazılı olmayan kural, kural değildir.

2. Var ama kontrol edilmiyor: Sprint Review'da hiçbir story DoD'a göre kontrol edilmiyor. Doküman var, uygulama yok. Bu en yaygın senaryo.

3. Çok uzun ve pratik değil: 40 maddelik DoD kimse okumaz, kimse uymaz. 8-12 madde arası ideal. Az ama gerçekten uygulanan maddeler daha değerlidir.

4. Story bazlı yazılıyor: Her story için ayrı DoD yazmak hem hatalı hem verimsiz. DoD ekip genelinde geçerlidir, story'ye özgü değil.

5. Hiç güncellenmiyor: Ekip büyüdükçe, teknik yapı değiştikçe, DoD da güncellenmeli. Yıllarca değişmeyen bir DoD olgunlaşmamış bir DoD'dur.

Bu iki terim sıkça karıştırılıyor. Fark kısa ve net:

Definition of Ready (DoR): Bir PBI'nın sprint'e alınabilmesi için karşılaması gereken kriterler. Sprint planning'e girmeden önce kontrol edilir. 'Bu iş başlamaya hazır mı?'

Definition of Done (DoD): Bir PBI'nın tamamlanmış sayılabilmesi için karşılaması gereken kriterler. Sprint'ten çıkmadan önce kontrol edilir. 'Bu iş gerçekten bitti mi?'

Definition of Done, Scrum'ın en az ilgi gören ama en çok değer katan araçlarından biri.

Sprint velocity'ye, story point'lere, retrospective formatlarına odaklanırken DoD ikinci plana düşüyor. Ama yaşadığınız kalite sorunlarının, beklenmedik bug'ların ve 'neden bu kadar iş birikiyor?' sorularının büyük çoğunluğu done tanımının net olmamasından kaynaklanıyor.

İyi bir DoD şunu sağlar: Herkes aynı 'done' tanımında. Sprint sonunda hangi işin gerçekten bittiği tartışmasız. Teknik borç görünür ve yönetilebilir hale gelir.

Ekibinizde hâlâ bir DoD yoksa, bir sonraki retrospective'de başlayın. Tek bir maddeden bile başlayabilirsiniz. Mükemmel bir DoD bugün başlamaktan değerli değildir.

Her ekip kendi DoD'unu mu yazar? Evet. Her ekibin teknik yapısı, deployment süreci ve kalite standartları farklıdır. Genel bir şablon başlangıç noktası olabilir ama DoD'un ekibe özgü olması şarttır.

Product Owner DoD'u değiştirebilir mi? Tek başına hayır. DoD Development Team tarafından oluşturulur. PO sürece dahil olabilir ama son karar ekiptedir.

Sprint ortasında DoD değiştirilebilir mi? Hayır. Sprint ortasında DoD değiştirmek sprint hedefini değiştirmek demektir. Değişiklikler retrospective sonrasına bırakılmalı.

Bir story DoD'u karşılamıyorsa ne olur? O story done sayılmaz. Sprint Review'da gösterilemez. Bir sonraki sprint'in backlog'una döner.

DoD ne sıklıkla güncellenmelidir? Her sprint retrospective'inde gözden geçirilmeli. Değişiklik zorunlu değil ama fırsat olarak değerlendirilmeli. Ekip büyüdükçe ve süreç olgunlaştıkça DoD da derinleşir.