Skip to main content
Key Takeaways

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.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

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. 
Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Tamamlanma Tanımı Nasıl Oluşturulur?

Tamamlanma tanımı oluşturma sürecindeki temel adımlar şunlardır.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

BoyutTamamlandı TanımıKabul Kriterleri
KapsamHer ürün biriktirme listesi öğesi ve artım için geçerlidirTek bir kullanıcı hikâyesine veya ürün biriktirme listesi öğesine özgüdür
SorumlulukTü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ükTü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üncellenirHer yeni kullanıcı hikâyesiyle değişir
Uygulama noktasıHerhangi bir öğe tamamlandı olarak işaretlenmeden önce kontrol edilirHikâ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.