30 saniyelik özet

Definition of Done, kısaca DoD, ürün çalışmasının tamamlanmış sayılması için karşılaması gereken kalite koşullarının ortak tanımıdır. Türkçede tamamlanmış sayılma tanımı olarak ifade edilebilir. Kodun yazılması, ekranın gösterilmesi veya bir yöneticinin beğenmesi tek başına yeterli olmayabilir. Ekip, sonucun hangi koşullarda kullanılabilir olduğunu açıkça değerlendirmelidir. DoD, beklentiyi kişisel yorumdan çıkarıp ortak bir standarda bağlar. Bununla birlikte kalite koşullarını karşılamak, geliştirilen özelliğin kullanıcı ihtiyacını çözdüğünü veya ticari başarı getirdiğini tek başına kanıtlamaz. Tamamlanma ve ürün etkisi ayrı sorulardır.

Neden önemli?

Satış ekibine bir özelliğin tamamlandığı söyleniyor. Müşteri toplantısında ekran çalışıyor, fakat gerçek kullanımda yetki kontrolünün eksik olduğu anlaşılıyor. Destek ekibi hata durumlarını açıklayamıyor; geliştiriciler gerekli kayıtları göremediği için sorunu incelemekte zorlanıyor. Aynı iş farklı kişiler için farklı anlamda “bitmiş” olabilir.

Bu belirsizlik, teslimatın güvenilirliğini etkiler. Yönetici tamamlanan işler üzerinden söz verirken ekip henüz gerekli doğrulamaları yapmamış olabilir. Takvimde görünmeyen kalite çalışmaları, sonraki işlerin kapasitesini tüketebilir. Sorun yalnızca bir testin unutulması değildir; ilerleme hakkında yanlış bilgiyle karar verilmesidir.

Ortak tamamlanma koşulları bu farkları görünür kılar. Hangi testler gerekli? Yetki davranışı nasıl doğrulanacak? Kullanım bilgisi güncel mi? Değişiklik mevcut işlevleri etkiliyor mu? Ürünün bağlamına uygun soruların baştan konuşulması, kalite işlerinin sonradan ortaya çıkan sürprizler gibi ele alınmasını önleyebilir.

Product Owner, yani ürün sahibi, kapsam seçeneklerini değerlendirirken bu çalışmaları hesaba katmalıdır. Küçük görünen bir özellik, güvenilir biçimde sunulabilmesi için ek doğrulama gerektirebilir. Yönetici de teslimat baskısının hangi koşulları atlamaya yol açtığını anlamalıdır. Kapsamı daraltmak, yeterince doğrulanmamış geniş bir kapsamı tamamlanmış ilan etmekten farklı bir karardır.

DoD ayrıca ekipler arası iletişimi destekler. Bir değişikliği teslim alan kişi, gerekli kontrollerin her seferinde yeniden sorulmasına ihtiyaç duymadan ortak tanımı inceleyebilir. Ancak bu güvenin dayanağı, listede koşulların bulunması kadar o koşulların gerçekten karşılandığını gösteren kanıttır.

Terim nedir?

Scrum, karmaşık ürün çalışmalarını yönetmeye yardımcı olan bir çerçevedir. 2020 Scrum Guide, DoD’yi Increment’ın ürün için gereken kalite ölçütlerini karşıladığı durumu açıklayan resmî tanım olarak belirtir. Increment, önceki ürün durumuna eklenen kullanılabilir ürün artışıdır.

Kurumsal bir DoD standardı varsa takımlar en az bu standarda uyar. Böyle bir standart yoksa Scrum Takımı ürününe uygun tanımı oluşturur. Aynı ürün üzerinde çalışan birden fazla Scrum Takımı ortak bir DoD tanımlayıp uygulamalıdır. Geliştiriciler bu koşullara uymakla sorumludur.

DoD’yi karşılamayan madde Increment’ın parçası sayılmaz; yayımlanamaz veya Sprint Review’da tamamlanmış ürün artışı olarak sunulamaz. Sprint Review, çalışma döngüsünün sonucunu ve sonraki uyarlamaları değerlendirme etkinliğidir. Eksik iş, gelecekte ele alınmak üzere ürün iş listesine döner.

Çerçeve kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020.

Acceptance Criteria, yani kabul kriterleri, belirli bir işten beklenen davranışı açıklar. Örneğin arama sonuçlarının tarih aralığına göre süzülmesi o özelliğe ait bir kriter olabilir. Değişikliklerin gerekli testlerden geçmesi ise ürüne ilişkin ortak kalite koşuludur. Birinin varlığı diğerini gereksiz kılmaz.

Definition of Ready, yani hazır olma tanımı, işe başlangıç için kullanılan hazırlık anlaşmasıdır. Başlamaya uygun bir madde henüz tamamlanmış değildir. Release, yani sürümün kullanıcılara sunulması, zamanlama ve sunum kapsamını da içeren ayrı bir karardır. Tamamlanmış bir değişikliğin herkese hemen açılmaması mümkün olabilir; bu ayrım eksik kalite çalışmasını gizlemek için kullanılmamalıdır.

Gerçek vaka: DWP’de erişilebilirlik olmadan tamamlanma yok

Birleşik Krallık Department for Work and Pensions, yani Çalışma ve Emeklilik Bakanlığı, erişilebilirlik rehberinde DoD için somut koşullar yayımlıyor. Erişilebilirlik, farklı yetenek ve ihtiyaçlara sahip kişilerin hizmeti kullanabilmesini destekleyen yaklaşımı ifade eder.

Rehber, erişilebilir olmayan hizmetin tamamlanmış sayılmaması gerektiğini belirtiyor. Örnek koşullar arasında otomatik erişilebilirlik testlerinin geçmesi, elle yapılan kontroller, ekran okuyucu ve ekran büyütücüyle kullanılabilirliğin incelenmesi bulunuyor. Sesle kullanımın kontrol edilmesi ve erişilebilirlik açıklamasının güncellenmesi de listeleniyor.

Bu uygulama, genel bir “Kaliteli olmalı” ifadesinin değerlendirilebilir koşullara nasıl dönüştürülebileceğini gösteriyor. Otomatik testin varlığı diğer kontrolleri ortadan kaldırmıyor; rehber farklı doğrulama biçimlerini birlikte ele alıyor.

Kaynak, kurumun yayımladığı çalışma beklentisini doğruluyor. Her takımın uygulama sonuçlarını veya bu koşulların hata maliyetini ne kadar azalttığını gösteren bir karşılaştırma sunmuyor. Bu nedenle sayısal bir iyileştirme iddiası çıkarılamaz. Vakadan alınabilecek ders, önemli bir kalite beklentisinin tamamlanma tanımında açık ve kontrol edilebilir hale getirilmesidir.

Kaynak: DWP Accessibility Manual, Agile teams, Definition of done bölümü.

Varsayımsal örnek: Abonelik iptalini güvenilir hale getirmek

Bir abonelik ürünü, müşterilerin hesaplarından iptal işlemi yapabilmesini geliştirmek istiyor. İlgili kabul kriterleri, yetkili kullanıcının iptal talebini iletmesini ve aboneliğin hangi tarihte sona ereceğini görebilmesini açıklıyor.

Ekibin ürüne uygun DoD’si, değişikliklerin incelenmesini, gerekli testlerin geçmesini, yetki kontrollerinin doğrulanmasını ve destek bilgisinin güncel olmasını içeriyor. İptal gibi önemli işlemler için kaydın tutulması ve hata durumunun izlenebilmesi de bu üründe gereken koşullar arasında bulunuyor.

Ekran tamamlandığında geliştirici işlemin başarılı olduğunu gösteriyor. Ancak arka plandaki ödeme yenilemesiyle bağlantı henüz doğrulanmamış. Kullanıcı iptal edildiğini düşünürken yeniden tahsilat yapılma riski var. Ekip bu işi tamamlanmış ilan etmiyor; eksik doğrulamayı ve etkisini görünür tutuyor.

Ürün sahibi, sonraki görsel iyileştirmeyi ertelemeyi değerlendiriyor. Kalite koşulunu kaldırarak takvimi korumak yerine, kullanıcıya sunulacak kapsamın güvenilir biçimde çalışması önceliklendiriliyor. Gerekli kontroller tamamlanana kadar müşteri iletişiminde de durum açık anlatılıyor.

DoD karşılandıktan sonra değişiklik sınırlı bir kullanıcı grubuna açılabilir. İptal akışının anlaşılır olup olmadığı ve kullanıcıların destek ihtiyacı ayrıca incelenir. Teknik olarak doğru çalışan bir süreç yine de kafa karıştırıcı olabilir. Bu öğrenme, tamamlanma standardının yerine geçmez; ürün kararlarını besler.

Yaygın üç hata

  1. Tamamlanmayı kişisel onaya bağlamak

“Ürün sahibi baktı” ifadesi hangi kalite koşulunun karşılandığını açıklamaz. Gerekli kontrolleri ve kanıtlarını görünür tutun. Bir kişinin onayını bütün doğrulama çalışmalarının yerine koymayın.

  1. Süre dolunca kalite koşulunu gevşetmek

Son güne bırakılan testleri sonraki döngüye taşırken işi tamamlandı saymak, gerçek durumu gizler. Eksik çalışmayı ve etkisini kaydedin. Yeni planlamada kalite işlerini kapsamın parçası olarak hesaba katın.

  1. Genel ve doğrulanamayan koşullar yazmak

“Güvenli, hızlı, sorunsuz” ifadeleri tek başına kontrol yöntemi sunmaz. Ürün bağlamına uygun ölçütü, yöntemi ve kanıtı açıklayın. Gereksiz ayrıntıya boğmadan ekip üyelerinin aynı değerlendirmeyi yapabilmesini sağlayın.

Mini uygulama / şablon

Yakın zamanda tamamlandı denilen bir değişiklik seçin ve şu alanları doldurun.

Ürüne ait ortak kalite beklentileri
—
Bu değişikliğin özel kabul kriterleri
—
Gerekli inceleme ve doğrulamalar
—
Veri, güvenlik ve erişilebilirlik kontrolleri
—
Mevcut işlevlerle birlikte çalışma kanıtı
—
Gerekli kullanım ve destek bilgisi
—
Her koşulun doğrulama yöntemi
—
Kanıtın bulunduğu yer
—
Karşılanmayan koşullar ve etkileri
—
Tamamlanma durumunun gerekçesi
—

Ardından aynı kayıtları başka bir ekip üyesinin incelemesini sağlayın. Aynı kanıtlardan aynı sonuca ulaşabiliyor mu? Belirsiz koşulları netleştirin. Sonradan ortaya çıkan sorunları da değerlendirin: Koşul eksik miydi, kontrol uygulanmadı mı, yoksa yöntem yetersiz mi kaldı? DoD’yi öğrendiklerinizle geliştirin; listeyi uzatmayı otomatik çözüm saymayın.

İlgili terimler

Increment, Definition of Ready, Acceptance Criteria, Sprint Review, Sprint Planning, Product Backlog, Product Owner, Release Planning, Quality Assurance, Accessibility, Technical Debt, Continuous Integration, Regression Testing, Outcome ve Output