Şeffaflığı hayatına sokmayan kaldı mı? Çeviklikle beraber gelen en güçlü yeni bakış açımız artık şeffaflık. Bir de şeffaflığı destekleyen iyi pratikler var. Bunlardan akla ilk gelenler “Bitti Tanımı – Definition of Done (DOD)” ve “Kabul Kriteri – Acceptance Criteria“. Hadi gelin bu iki pratiğin farklarına ve ortak noktalarına odaklanalım.
Bitti Tanımı ve Kabul Kriteri takımlarca biraz karıştırılabiliyor. Sebebi de tanımlarının birbirine yakın olmasıdır. Her iki pratik de maddenin “Done” olması için gerekenlerle ilgilidir. Ama kullanım amaçları ve kapsamları ile ayrışırlar.
Kabul Kriteri ve Bitti Tanımı Farkları
Kabul kriteri ve Bitti tanımı arasındaki en temel fark kapsamlarıdır. Bitti Tanımı tüm çalışmalarımızda ortaktır. Kabul Kriteri ise her bir iş parçasına özgüdür.
Bitti Tanımı: Takım, herhangi bir iş parçasının kullanılabilir bir standartta olması için ne gerekiyorsa, bunu Bitti Tanımı ile belirler. Bitti tanımı, herkes için ortak bir anlayış sağlar ve bunu şeffaf hale getirir.
Bitti Tanımı, non-functional özellikler ve kalite faktörlerini kapsama eğilimindedir. Takımlar bitti tanımlarına kalite ve performans süreçlerini ekleyerek, tanımı geliştirebilirler.
Takımlar ürün geliştirirken bazı performans iyileştirmelerini Backlog’larına alabilirler. Bu tarz iyileştirme ihtiyacı sürekli olmaya başladığında ise takım, bitti tanımlarına “performans iyileştirme” adımını ekleyebilir.
Kabul Kriteri: Bir iş parçasının (Ör: User Story – Kullanıcı Hikayesi) bitti denebilmesi için hangi şartları sağlaması gerekiyorsa, takım bunu kabul kriterlerinde belirtir. Bir kullanıcı hikayesinin sınırlarını belirler. Kullanıcı hikayesinin amacındaki gibi çalışıp çalışmadığını teyit etmek için kullanılır. İşlevselliği ve bu işlevselliğin kullanıcılar için sağlayacağı sonuçları açıklar.
Ne zaman oluşturulur?
Bitti Tanımı: İlk bitti tanımı proje veya ilk sprint başlamadan önce yaratılır. Takım rollout etkinliği içinde ürün yöneticisi ve geliştiriciler tanımı belirlemek için tartışır ve takım kararı ile ilk bitti tanımı ortaya çıkar. Belirlenen bitti tanımı herkesçe görünür olması gerekir.
“İlk” tanım dememin bir sebebi var. Takımların, uzun süreli sabit bir DOD kullanmasından ziyade; bitti tanımlarını sürekli geliştirmesi ve iyileştirmesi beklenir. Bu yüzden sürece başlamadan ilk tanım belirlenir, proje/ürün devam ettiği sürece de bitti tanımı değişir ve gelişir. Retrospective etkinlikleri bitti tanımını gözden geçirmek için en iyi zamanlardan biridir.
Retrospective Tekniği : Improve Your Definition Of Done (DOD)
Kabul Kriteri: Ürün sahibi ve geliştiriciler her Backlog Refinement aktivitelerinde veya planlama etkinliklerinde kabul kriterleri üzerinde tartışır ve üzerinde anlaşır. Sonuçlar kullanıcı hikayesiyle birlikte kaydederler. Söz konusu hikaye hakkında daha fazla bilgi edindikçe kabul kriterleri de güncellenir.
Test ve kontroller
Bitti Tanımı: Bir kullanıcı hikayesinin bitti tanımına göre Done olup olmadığından tüm takım sorumludur. Bunun takibi takımca yapılır. Bitti tanımına göre sadece Done olan işler kullanıcılara teslim edilir. (Increment’e dahil edilir) Not Done işler gösterilmez. (Increment’e dahil edilmez)
Kabul Kriteri: Bir kullanıcı hikayesinin kullanıcılar için sağlayacağı sonuçları test etmek için kabul kriterleri kullanılır. Kullanıcılar veya ürün sahibi bu kriterlere göre hikayeyi test eder. Kriterlerin karşılanıp karşılanmamasına göre hikayenin Done veya NotDone olduğunu bildirir.
Scrum Guide
Bitti Tanımı: Scrum Guide 2020 ile birlikte Bitti Tanımı artık, Increment’in bir taahhütü olarak bahsediliyor. Guide’da “Bitti Tanımı, Increment’in ürün için gerekli kalite gereksinimlerini sağladığı halinin resmi bir tanımıdır.” şeklinde tanımlanıyor. Ek olarak geliştiricilerin bitti tanımı ile kaliteyi arttırma sorumluluğu olduğundan ve Planlama etkinliğinin bitti tanımına uygun bir increment oluşturmak çerçevesinde yapıldığından da bahsediyor.
Kabul Kriteri: Scrum Guide 2020 kapsamında kabul kriterleri ile ilgili herhangi bir bölüm bulunmuyor. Genellikle kabul kriteri, iyi bir pratik olarak kabul edilen Kullanıcı Hikayelerinin detaylandırılmasında kullanılan en yaygın yolu olarak karşımıza çıkar. Kullanıcı hikayeleri, Scrum Guide kapsamındaki “Product Backlog Item” olarak eşleştirilebilir.
Kabul Kriteri ve Bitti Tanımı Ortak Noktalar
Kabul Kriteri ve Bitti Tanımı için farklılaşan konulara değindik ama ortak noktaları da var tabii ki.
Takımdaki herkesçe aynı şekilde anlaşılmalıdır.
Özellikle kabul kriterleri herkesçe aynı şekilde anlaşılacak şekilde yazılmalıdır. Bir iş Done denildiğinde hangi standartlardan geçtiği ve hangi kriterlerde olduğu herkesçe aynı şekilde bilinir.
Sürekli gelişir.
Bir kullanıcı hikayesi için yazılan kabul kriteri sabit kalmaz. Bilgi edindikçe kabul kriterleri de sürekli güncellenir. Aynı şekilde sürekli ve sabit bir DOD de istenmez. Gerek duyuldukça takım DOD’sini geliştirir.
Test edilebilir
Bir DOD içinde mutlaka her türlü test aşaması olmalıdır. Bir kullanıcı hikayesinin özelliği de test edilebilir olmasıdır. Bu yüzden kabul kriterleri mutlaka test süreçlerine hizmet etmelidir.
Açık ve net olmalıdır.
Her iki tanım da şeffaflık ilkesine hizmet eden güçlü pratiklerdir. Bu yüzden tanımlar görünür ve herkes için aynı şekilde anlaşılır olması gerekir. (ilk maddeyle ortak bir özellik)
Tahminleme – Sizing/Estimation
Geliştiriciler kullanıcı hikayelerinin büyüklüklerini tahminlerken bu iki tanımı kullanır. İlk önce hikayenin içeriğini kabul kriterlerinden öğrenir, sonra bitti tanımına göre hangi aşamalardan geçeceğini bilir ve bunların toplamına göre büyüklük tahminlemesi yapar.
İlkim Dilara KADAKALOĞLU
d.
İlk Yorumu Siz Yapın