Definition of Done veya kısa adı ile DoD bir PBI'ın Production ortamına verilmesi hazırmış gibi kabul edilen, PBI'ın bitmesi için oluşturulan kabul kriterlerine ve adımlarına denir. DoD kriterleri bir PBI'ın kalitesini ölçmekte en önemli etkendir. Siz DoD kriterlerini esnetir veya bazı adımlarını geçiştirir seniz günün sonunda kalitesiz ürün ile karşılaşırsınız.
Kaliteli ürün ve kaliteli şekilde Done olmuş bir PBI, takımın Velocity değerini de yükseltecektir. Velocity bilgisi PBI bazında olup, DoD kriterlerine sadık kalan takımlar Done yaptıkları PBI'lar ile kendi kalitesini Scrum sürecinden göreceklerdir. Ayrıca PBI almadan önce Definition of Ready(DoR) çalışması yapılabilir.
Aşağıda örnek bir Definition of Done listesi oluşturdum. Bu kriterlerde hangi adımları kimler beraber yaparsa kaliteli ürünün çıkmasına ve çevik yaklaşımın gelişmesine yardımcı olmalıdan bahsettim.
Örnek Definition of Done Adımları;
Kapsam Çalışması(Requirements) (Analist)
Analiz (Analist + Tester)
Tasarım(Dizayn) (UI/UX)
Teknik Analiz (Developer)
Kodlama(Development) (Developer)
Code Review (Developer + Developer)
Unit Test(Birim Test) (Developer + Tester)
Fonksiyonel Test(System Test) (Tester)
Analiz Review (Analist + Tester)
Otomasyon Testi (Automation Testing) PreProd testidir ve genel yapı bozulmuş mu test edilir.
UAT-KKT (Production Testi) Kullanıcı kabul testidir ve ayrı tutulabilir.
Bir projenin başlangıç kısmı olan İş Analizi, proje hakkında stratejik iş birimi veya kullanıcıdan (Müşteri) ne istenildiği öğrenilerek ürünün dokümantasyon sürecine denir. İyi bir analiz takıma zaman kazandırır. Analizin daha kaliteli olması için Testçi de projenin başında dahil olarak sürece katkı sağlayabilir. Çünkü proje sonunda ürünü kontrol edeceği için sonradan sadece dokümantasyon üzerinden gidilen test süreci çok verimli olmayabilir.
Teknik Analiz kısmı ise proje hakkında Developer'ın teknik olarak yazdığı dokümandır. Projede kullanacağı teknoloji, mimari yapı, servis yapısı, veri tabanı bilgileri gibi birçok konu test yaparken hem lazım olacaktır hemde Developer proje üzerinde tekrar bir çalışma yapacağı zaman veya o projeden bir Product Defect geldiği zaman teknik analiz dokümanına ihtiyaç duyacaktır. Ayrıca Testçi için test senaryoları sadece iş analizi dokümanından çıkmaz teknik test case'ler teknik analiz dokümanından çıkar. Daha kaliteli test süreçleri için teknik analiz safhası önemlidir.
Code Review kısmı ise temiz kod(Clean Code) dediğimiz açığı tamamlar. Daha kaliteli, işlevsel ve geriye dönüp bakıldığında okunabilen, Spaghetti Code olmayan kodları yazmak için bu kriteri uygularsınız. Code Review sayesinde birçok Developer kodlarını en son UAT-KKT gibi Prod-PreProd ortamlarından bir önceki kritik ortamlara Commit etmeden kontrol eder. Yanlış Commit veya Code Review eksiği Deploy sonrası çalışan parçacıkları da bozabilir ve ürünün kalitesi iyice düşer. Bu yüzden Code Review, Developer'ın en önem vermesi gereken adımlardan biridir. Code Refactoring(Kod Düzenleme) ile kodu daha anlaşılır hale getirme ve optimize etme yine bu safhada olur.
Unit Test(Birim Test) genelde Developer'dan beklenen bir süreç olsa da bu adım sadece Developer'a bırakılmamalıdır. Bu adımda yapılması gereken Developer yaptığı adımları kontrol ederken yanında Tester ile birlikte yapmalıdır. Bu sayede Tester hem arka planda Coder'ın ne yaptığını ve adımlarını, Debug yapışı dahil hepsini görür ve kontrol eder. Bu sayede yapılan iş Developer gözünden Testçi ye aktarılmış olur hemde o anda bir bulgu ile karşılaşılırsa hemen müdahale edilir. Çünkü birçok kritik hata doğru birim test yapılırken çıkmaktadır.
Fonksiyonel Test(System Test) Tester tarafından test senaryolarının hazırlanıp, işletilmesi safhasıdır. Testçi sistem testi yaparken detaylı yapar ve Tüm case'leri düşünür. En detaylı ve kaliteli test bu safhada yapılır. BUG/FIX süreci bu adımda başlar. Tüm fonksiyonel testler ve bulgular kapanmadan testi asla bitirmeyin, bu sefer ürün kalitesinden yine ödün vermiş olursunuz.
Analiz Review; Analist ve Tester tarafından yapılan kalite kontrol safhasıdır. Bu adım çok önemlidir. Projede müşteri tarafından istenilen her şeyi analist bildiği için ürünün son safhasını testçi ile kontrol etmesi kalite kontrol kalitesini artırır. Hatta Analist bile bulgu açabilir ürünü kontrol ederken. Bu sayede Analist ve Testçi takımda bir QA Team (Quality Assurance) katmanı oluşturmuş olur. Bu katman kaliteli ve hatasız ürünü ortaya çıkarır. Product Defect sayısını sıfıra yakın tutar. Testçi olarak mutlaka son adımı Analiz arkadaş ile yapıp ürünü kontrol etmenizi öneririm. Çünkü sizinde gözünüzden kaçırdığınız case'ler olabilir veya Analiz dokümanında olmayıp Analistin ürünü kontrol ederken aklına geleceği bir durum varsa bu safhada görmesi ve müdahale etmesi mümkün olur.
Son olarak kaliteli ürün ve şeffaflık için DoD kriterleri ve adımlarını uygulamak önemlidir. Scrum süreci içerisinde takım DoD kriterlerini geliştirebilir ve üretkenliğini artırabilir. Kalite her zaman Development Team sorumluluğundadır.
Burak AVCI
