Kalite Tutarlılığı: Ortak bir tamamlanma tanımı oluşturmak, ekip genelinde kafa karışıklığını önler ve iş kalitesini artırır.
Geliştirilmiş Öngörü: Açık bir tamamlanma tanımı, hızın doğru şekilde öngörülmesine ve daha iyi proje planlamasına yardımcı olur.
Yaygın Tuzaklar: Tanımı aşırı ayrıntılı hâle getirmekten veya uygulanmasını ihmal etmekten kaçının; her ikisi de sorunlara yol açabilir.
Uygulanabilir Adımlar: Makale, çevik ekipler için başarılı bir tamamlanma tanımı oluşturmak üzere somut adımlar sunar.
Tamamlanma tanımı (DoD), çalışmanın gerçekten ne zaman tamamlandığını belirleyen ortak standarttır. Kalite açıklarını, yeniden çalışmayı ve sprintin hemen sonunda ortaya çıkan sürprizleri önlemeye yardımcı olur. Geliştirme ekiplerinin, herkesin "tamamlandı" ifadesini farklı yorumlaması nedeniyle güven kaybettiğini, teslim tarihlerini kaçırdığını ve gereksiz çatışmalar yarattığını gördüm.
Bu kılavuzda, çevik ekibinizi aynı hedefte buluşturan, öngörülebilirliği artıran ve kaliteyi güçlendiren bir tamamlanma tanımının nasıl oluşturulacağını; ayrıca pratik örnekleri, şablonları ve kaçınılması gereken yaygın hataları öğreneceksiniz.
Tamamlanma Tanımı Nedir?
Tamamlanma tanımı, bir ürün iş listesi öğesinin veya artımın ekip tarafından tamamlanmış ve potansiyel olarak yayımlanabilir kabul edilmeden önce karşılaması gereken resmi ve ortak kriterler kümesidir. Bunu, boyutu veya karmaşıklığı ne olursa olsun her iş parçasında ekibinizin uymayı kabul ettiği kalite sözleşmesi olarak düşünebilirsiniz.
Etkili bir tamamlanma tanımının temel özellikleri şunlardır:
- Şeffaf: Ekipteki herkes ve temel paydaşlar bunu her zaman görebilir, okuyabilir ve referans alabilir.
- Ölçülebilir: Her kriter ikilidir. İş ya kriteri karşılar ya da karşılamaz; ancak nicel kriterler için seçtiğiniz eşikler üzerinde gerçekten düşünmeniz gerekir. %80 kod kapsamı hedefi, uygulama açısından ikilidir; ancak %70 veya %90 yerine %80'in seçilmesi, bilinçli olarak vermeniz gereken bir karardır
- Evrensel olarak anlaşılır: Scrum ekibinin her üyesi her maddeyi aynı şekilde yorumlayabilmelidir.
- Tutarlı biçimde uygulanır: Aynı kontrol listesi her teslimata ve ürün iş listesi öğesine uygulanmalıdır.
- Bir sprint içinde ulaşılabilir: Kriterler, ekibin bunları tek bir sprint veya yineleme sırasında karşılayabileceği kadar gerçekçi olmalıdır.
Yazılım geliştirme projelerinde, tamamlanma tanımının sorumluluğu genellikle geliştiricilerdedir; çünkü tanıma uymaktan onlar sorumludur. Bununla birlikte, ürün sahibi ve Scrum yöneticisi de katkıda bulunmalıdır.
Kuruluşunuzun kendine ait tamamlanma standartları varsa her Scrum ekibi bunlara en az temel ölçüt olarak uymalıdır. Ekipler her zaman bunun üzerine daha katı kriterler ekleyebilir; ancak kurumsal tabanın altına inemezler.
Tamamlanma Tanımı Neden Önemlidir?
Açık bir tamamlanma tanımı önemlidir; çünkü kısmen tamamlanmış işlerin gözden kaçmasını önler ve ortak bir kalite standardı sağlar.
Ortak bir tamamlanma tanımının önemli olmasının diğer nedenleri şunlardır:
- Yerleşik bir kalite kapısı görevi görür: Her öğe tamamlanabilmeden önce aynı eşiği geçmelidir. Bu, yarım kalmış işlerin ürün artımınıza sızmasını ve teknik borç olarak birikmesini önler.
- Belirsizliği ortadan kaldırır: Ekip tek bir tanımı paylaştığında, çelişen tanımların işin hızını veya kalitesini etkilediği durumlarla karşılaşmazsınız. Ortak bir tamamlanma tanımı, daha az çatışma, daha az sürpriz ve daha düzenli demolar anlamına gelir.
- Tahminlemeyi geliştirir: Tamamlanmış ifadesi her sprintte aynı anlama geldiğinde, hızı güvenle tahmin edebilir ve yeniden çalışmayı hesaba katmak için tahminlere pay eklemeden sürümleri planlayabilirsiniz.
- Paydaşların güvenini oluşturur: Ürün sahipleri, yöneticiler ve dış paydaşlar ekibinizin açık bir kalite standardını uyguladığını gördüğünde çıktılarınıza güvenir.
- Entegrasyon karmaşasını önler: Çalışmanızı ortak bir artıma entegre etmenizi gerektiren bir şekilde çalışıyorsanız, tamamlanma tanımına ilişkin ortak anlayış, tutarlı ve yayımlanabilir artımların temelidir.
Tamamlanma Tanımı Nasıl Oluşturulur?
Tamamlanma tanımı oluşturma sürecindeki temel adımlar şunlardır.
- Mevcut iş akışınızı denetleyin: İşinizin üretime ulaşmadan önce geçtiği her adımı haritalandırın. Geliştiricilerle, test uzmanlarıyla, tasarımcılarla ve işe dokunan diğer herkesle konuşun. Resmileştirilmesi gereken gayriresmî kalite adımlarını keşfedeceksiniz.
- Pazarlık konusu olmayan kalite kriterlerini belirleyin: Her iş parçası için hangi faaliyetlerin gerçekleştirilmesi gerektiğine karar verin. Bunlar genellikle kod incelemesi, otomatik testler, belgelerin güncellenmesi ve güvenlik taramalarını içerir. Şu anda neleri atladığınız konusunda dürüst olun.
- Kontrol listesini iş birliğiyle hazırlayın: Tüm ekibi bir araya getirin ve herkesin gerçek zamanlı olarak madde ekleyebileceği, bunlara itiraz edebileceği ve maddeleri geliştirebileceği bir beyaz tahta veya ortak belge kullanarak konuyu birlikte ele alın. Uzlaşı yoluyla benimsenen bir tamamlanma tanımı, itirazlara rağmen oylanarak kabul edilenden baskı altında çok daha iyi dayanır.
- Kuruluş standartlarına göre doğrulayın: Taslağınızı, ürününüzün uyması gereken şirket genelindeki kalite politikaları, düzenleyici gereklilikler veya sektör standartlarıyla karşılaştırın. Kuruluşunuzda zaten bir temel tamamlanma tanımı varsa, buradan başlayarak onu geliştirin.
- Görünür kılın: Tamamlanma tanımını ekibinizin her gün çalıştığı yere asın. Bu, duvarda bir poster, Slack'te sabitlenmiş bir mesaj veya proje yönetimi aracınızdaki bir panel olabilir.
- Uygulamaya koymayı taahhüt edin: Son teslim tarihleri yaklaştığında geçersiz kılınan bir tamamlanma tanımı, sahte bir kalite hissi yarattığı için hiç olmamasından daha kötüdür.
Tamamlanma Tanımı Örnekleri
Farklı proje türleri için birkaç tamamlanma tanımı örneğini aşağıda bulabilirsiniz:
Yazılım Geliştirme Projeleri için Tamamlanma Tanımı
Yazılım projeleri; hatalar, güvenlik açıkları, performans gerilemeleri ve entegrasyon başarısızlıkları gibi çok çeşitli kalite riskleriyle karşı karşıyadır. Bir yazılım ekibinin tamamlanma tanımının, koddan yayımlanabilir duruma kadar olan sürecin tamamını kapsaması gerekir.
Bu tanım şu şekilde olabilir:
- Tüm kodlar yazılmış ve en az bir başka geliştirici tarafından akran incelemesinden geçirilmiş
- Birim testleri, üzerinde anlaşılan kapsam eşiğini karşılayarak başarılı olmuş
- CI/CD işlem hattındaki entegrasyon testleri başarıyla tamamlanmış
- Kritik veya yüksek önem derecesine sahip açık hata bulunmuyor
- Yapılan değişiklikleri yansıtacak şekilde teknik belgeler güncellenmiş
- Kod ana dala birleştirilmiş
- Ürün sahibi çalışmayı incelemiş ve kabul etmiş
- Performans kıyaslamaları, üzerinde anlaşılan eşiklere göre karşılanmış
Pazarlama Projeleri için Tamamlanma Tanımı
Pazarlama çalışmalarında genellikle yazılımdan farklı uyumluluk, marka ve ölçüm boyutları bulunur.
Bir pazarlama projesi için tamamlanma tanımı şu şekilde olabilir:
- İçerik, hukuk ekibi tarafından incelenmiş ve onaylanmış
- Meta açıklamaları, alternatif metin ve dahili bağlantılar dâhil SEO kontrol listesi tamamlanmış
- Tüm varlıklar İYS'ye yüklenmiş ve doğru biçimlendirilmiş
- Analiz izleme yapılandırılmış ve hazırlık ortamında doğrulanmış
- Son metin, ekipteki ikinci bir kişi tarafından düzeltme okumasından geçirilmiş
- Kampanya başlatma kontrol listesi ekip lideri tarafından onaylanmış
Tasarım Projeleri için Tamamlanma Tanımı
Tasarım ekiplerinin tamamlanma tanımının, yaratıcı amaç ile teknik teslim arasındaki boşluğu kapatması gerekir. Böyle bir tanım olmadığında tasarımlar geliştirme aşamasına eksik ulaşır; eksik teknik özellikler, doğrulanmamış duyarlı davranışlar veya çok geç keşfedilen erişilebilirlik açıkları ortaya çıkar.
Bir tasarım projesi için tamamlanma tanımına örnek:
- Tasarım, WCAG 2.2 uyarınca erişilebilirlik standartlarına göre incelenmiş
- Tüm teknik özellikleri, varlıkları ve açıklamaları içeren teslim dosyası, üzerinde anlaşılan araçta hazırlanmış
- Paydaşların onayı alınmış ve belgelenmiş
- Yeni tasarım kalıpları kullanıma sunulduysa tasarım sistemi bileşenleri güncellenmiş
- Duyarlı davranış, üzerinde anlaşılan kesme noktaları genelinde doğrulanmış
Tamamlanma Tanımı ve Kabul Kriterleri
Tamamlanma tanımı ekip düzeyindeki kalite standardınızdır; kabul kriterleri ise özellik düzeyindeki işlevsel gerekliliklerdir.
Tamamlandı tanımını evrensel olarak geçerli olan temel standart, kabul kriterlerini ise her sprint biriktirme listesine veya ürün biriktirme listesi öğesine özgü koşullar olarak düşünün. Bir ürün biriktirme listesi öğesi, hem kabul kriterlerini hem de ekibin tamamlandı tanımını karşıladığında tamamlanmış olur.
| Boyut | Tamamlandı Tanımı | Kabul Kriterleri |
|---|---|---|
| Kapsam | Her ürün biriktirme listesi öğesi ve artım için geçerlidir | Tek bir kullanıcı hikâyesine veya ürün biriktirme listesi öğesine özgüdür |
| Sorumluluk | Tüm Scrum ekibinin katkılarıyla geliştiricilerin sorumluluğundadır | Ürün sahibi tarafından veya ürün sahibiyle birlikte yazılır |
| Özgüllük | Tüm çalışmalar için genel kalite standartları | Tek bir çalışma parçasına ilişkin ayrıntılı işlevsel gereksinimler |
| Değişiklik sıklığı | Nadiren değişir; sprint retrospektifleri sırasında güncellenir | Her yeni kullanıcı hikâyesiyle değişir |
| Uygulama noktası | Herhangi bir öğe tamamlandı olarak işaretlenmeden önce kontrol edilir | Hikâye incelemesi veya kabul testi sırasında doğrulanır |
Yaygın Tuzaklar ve Hatalar
Tamamlandı tanımları oluştururken kaçınmanız gereken bazı yaygın hatalar şunlardır:
- Daha hızlı ilerlemek için öğeleri atlamak: Son teslim tarihi baskısı altındaki ekipler genellikle güvenlik incelemesi, erişilebilirlik testi veya belgelendirme gibi kriterleri göz ardı eder. Bu durum, daha sonra hatalar, yeniden çalışma veya uyumluluk sorunları olarak ortaya çıkan gizli teknik borç oluşturur.
- Kontrol listesini gereğinden fazla ayrıntılı hâle getirmek: Aşırı ayrıntılı bir tamamlandı tanımı bürokratik bir angaryaya dönüşür. Kontrol listenizde 30 öğe varsa ve geliştiriciler yazılım geliştirmekten çok kutuları işaretlemeye zaman harcıyorsa, işi fazla ileri götürmüşsünüz demektir. Anlamlı olacak kadar özgül, ancak pratik kalacak kadar genel olun.
- Tamamlandı tanımını her hikâyeye göre değiştirmek: Tamamlandı tanımının temel amacı tutarlılıktır. İşlevselliğe özgü koşullar, tamamlandı tanımına değil, kabul kriterlerine aittir (örneğin ön koşul-eylem-sonuç kabul kriterleri).
- Tanımı hiçbir zaman gözden geçirmemek: Uygulamalarınız olgunlaştıkça, kullandığınız araçlar değiştikçe veya ürününüz büyüdükçe tamamlandı tanımı da gelişmelidir. En azından üç ayda bir retrospektifler sırasında gözden geçirmenizi ve ekip boşlukları ya da sürtüşme noktalarını belirlediğinde gerekli ayarlamaları yapmanızı öneririm.
- Uygulamamak: Önemli biri istediğinde bir kenara bırakılan bir tanım işe yaramaz. Bir paydaş standardı karşılamayan bir şeyi yayımlamak istediğinde bile tanımı korumak Scrum yöneticisinin görevidir. Kriterler rutin olarak geçersiz kılınırsa ekip standarda olan güvenini kaybeder ve standardı ciddiye almayı bırakır.
- "Tamamlandı" ile yayımlandı kavramlarını karıştırmak: Tamamlandı tanımı, bir artımın yayımlanabilir olup olmadığını belirler; yayımlanıp yayımlanmadığını değil. Bir ürün biriktirme listesi öğesi yayımlanmadan da tamamlanmış olabilir. Ekibiniz sürüm yayımlama sürecinin uçtan uca sorumluluğunu gerçekten üstlenmiyorsa tamamlandı tanımınıza "üretim ortamına yayımlandı" ifadesini eklemeyin.
- Tanıma başvurmayı ihmal etmek: Pek çok ekip teknik olarak bir tamamlandı tanımına sahiptir; ancak tanım altı ay önce oluşturulduğundan beri kimse ona bakmadıysa, kalite standardı olarak işlev görmüyor demektir.
Sırada Ne Var?
Ücretsiz DPM üyeliği aracılığıyla pratik araçlar, şablonlar ve uzman görüşleriyle çevik süreçlerinizi ve çalışma biçimlerinizi geliştirin; ekiplerin kaliteli işleri tutarlı bir şekilde teslim etmesine yardımcı olan sistemleri güçlendirin.
