Geliştiricilerin ve test uzmanlarının belirli bir özelliğin nasıl çalışması gerektiği konusunda tartıştığını kaç kez gördünüz? Peki, istediğiniz özelliği nasıl geliştireceğinden emin olmayan geliştiricilerin kafası karışmış yüz ifadelerine ne demeli? Her ikisi de yazılım dünyasında oldukça yaygın sorunlardır ve neyse ki bunları çözmek için cephaneliğinizde güçlü bir araç var: kabul kriterleri.
Bu rehberde, gereksinimleri yazıya dökme biçiminin doğasını açıklayacak, ürün yönetimindeki rolünü anlatacak ve harika kabul kriterlerinin nasıl yazılacağını göstereceğim.
İçindekiler
Kabul Kriterleri Yazmanın Amacı Nedir?
İyi Yazılmış Kabul Kriterleri Nasıl Olmalıdır?
Yaygın Kabul Kriteri Biçimleri
Kabul Kriterleri Nedir
(ve Çevik/Scrum İçinde Nereye Oturur?)
Çevik metodolojide kabul kriteri, Çevik ürün yöneticilerinin (veya iş analistlerinin), ekibin geliştirmeyi planladığı özelliklerin farklı durumlarını ve davranışlarını açıkça iletmek için kullanıcı hikâyelerine eklediği en küçük işlevsel veya tasarımsal gereksinim birimidir.
Teknik olarak kabul kriterlerini istediğiniz her yerde kullanabilirsiniz. Ancak geleneksel olarak bunlar, Çevik epiklerin bileşenleri olan kullanıcı hikâyelerinin bir parçasıdır.
Kabul kriterlerini daha iyi anlamak için önce anılarımızı tazeleyelim, bu hiyerarşideki unsurları gözden geçirelim ve her birinin ne için kullanıldığını görelim.
Epikler
Epikler, birbiriyle ilişkili büyük bir özelliğin veya özellik grubunun üst düzey işlevsel ve işlevsel olmayan gereksinimlerini içeren görevlerdir. Genellikle bir epik, müşterileriniz için kapsamlı bir kullanım senaryosunu kapsar ve söz konusu kullanım senaryosunu karşılamak için uygulamanız gereken tüm temel özellikleri ve işlevleri içerir.
Spotify'daki ürün ekibinin bir parçası olduğunuzu ve internete erişimi olmayan ya da hareket hâlindeki kişiler için yeni bir kullanım senaryosu ekleyerek uygulamanın kullanımını genişletmek istediğinizi düşünün.
Bu kullanım senaryosunu karşılamak için “Spotify için çevrimdışı mod” adında yeni ve büyük bir özellik eklemeyi düşünebilirsiniz. Bu özellik, kullanıcıların internet bağlantısı olmadığında müzik dinlemesini sağlayacak tüm genel gereksinimlerin yanı sıra, özelliğin belirli bölümlerine ilişkin gereksinimleri içeren çeşitli kullanıcı hikâyelerini barındıran ürün iş listenizde bir epik hâline gelebilir.
Kullanıcı Hikâyeleri
Kullanıcı hikâyeleri daha küçük boyutludur ve epik içindeki tek ve farklı bir işlev parçasını temsil eder. Bunlar, Çevik ekibin tek bir iterasyon içinde teslim etmeyi taahhüt edebileceği, küçük iş parçalarıdır.
Bir kullanıcı hikâyesinin temel özelliklerinden biri, temsil ettiği işlevin tamamlanmış ve potansiyel olarak kullanılabilir bir şey olması gerektiğidir.
Örneğin, çevrimiçi bir dosya depolama uygulaması geliştiriyorsanız ve kullanıcılarınızın yükledikleri dosyaları yeniden adlandırmasına izin vermek istiyorsanız, hem ön yüzde (yeniden adlandırma kullanıcı arayüzü ve deneyimi) hem de arka uçta (yeni adın depolanması) çalışma yapmanız gerekir.
Özelliğin tamamlanmış ve kullanılabilir olması için her iki görevi de bitirmeniz ve ön uç ile arka uçtaki bölümleri birbirine bağlamanız gerekir. Ekibiniz tüm bunları tek bir kullanıcı hikâyesinin kapsamında yapar.
Yalnızca arka uç çalışmasını yapacak olsaydınız, görev tamamlanmış ve kullanılabilir olmayan bir teslimat içereceğinden bu görev uygun bir hikâye olmazdı.
Ürün sahipleri, geliştirme ekibinin özelliğin nasıl görüneceğini ve nasıl davranması gerektiğini bilmesini sağlamak için bu hikâyeye ilişkin kabul kriterleri yazar.
Have an account? Log In
Kullanıcı Hikâyesi Kabul Kriterleri
Son olarak, yazılım ürünü gereksinimleri hiyerarşisindeki en küçük öğelere, yani kabul kriterlerine sahibiz. Bunlar, söz konusu işlevin bireysel kullanım senaryolarını veya mühendislik ekibinin hikâyeyi uygularken önemli bulacağı bilgi parçalarını temsil eder.
Yukarıdaki örnek için bir kabul kriteri, kullanıcı yüklediği dosyanın üzerindeki ✏️Yeniden adlandır düğmesine tıkladığında, dosyanın adı önceden doldurulmuş bir metin alanının açılması olabilir.
Tamamlanma Tanımı (Evet, Kabul Kriterlerinden Farklıdır!)
Bazen ürün sahipleri (özellikle de Scrum rolünde nispeten yeni olanlar), tamamlanma tanımını kabul kriterleriyle karıştırır.
Açıkçası, her ikisi de “özelliğin tamamlanıp tamamlanmadığını kontrol etmek için kullanılan kriterler” olduğundan, başlangıçta benim için de oldukça kafa karıştırıcıydı.
Tek fark, tamamlanmış tanımının ekibin geliştirme süreçleri açısından tamamlanmışlığı ifade etmesidir.
Kabul kriterleri ise işlevsel gereksinimleri temsil eder (özelliğin nasıl görünmesi ve davranması gerektiğini).
Bu, ekibin uyguladığı tüm hikâyeler için tamamlanmış tanımının aynı kalacağı anlamına gelir; ekip retrospektifler sırasında bu tanımda değişiklik yapmaya karar vermediği sürece. Öte yandan kabul kriterleri, söz konusu özelliğin nasıl çalışması gerektiğini açıkladıkları için her hikâyeye özgüdür.
Not: Bazı ürün yönetimi araçları, hikâyelerinizde hem tamamlanmış tanımına hem de kabul kriterlerine yer vermenize olanak tanır.
Artık epiklerin ve hikâyelerin ne olduğunu ve kabul kriterlerinin bunlarla nasıl ilişkili olduğunu hatırladığımıza göre, ürün sahiplerinin öncelikle neden kabul kriterleri yazdığını anlamaya geçelim.
Kabul Kriterleri Yazmanın Amacı Nedir?
Herhangi bir kabul kriteri eklemeden bir kullanıcı hikâyesi açıklamasını istediğim şekilde yazabilir miyim? Zaten kabul kriterleri yazmanın faydası nedir?
Elbette hikâyelerinizi istediğiniz şekilde yazabilirsiniz. Ancak gereksinimlerinizi formüle ederken kabul kriterlerini kullanmanızı öneriyorum; çünkü bu format çok çeşitli avantajlar sunar. İşte değerlendirmeniz için birkaç tanesi.
Davranış Odaklı Düşünmeyi Teşvik Ederler
Kabul kriterleri için BDD formatını seçerseniz (buna daha sonra değineceğiz), kabul kriterleriniz müşterilerinizin söz konusu özelliği kullanırken izledikleri yolu açıklayacaktır.
Bu yaklaşımın güzelliği, düşünce biçiminizi kuru teknik gereksinimlerden uzaklaştırıp özelliğe kullanıcının bakış açısından bakmaya başlamanızdır. Bu şekilde, kullanıcıların özelliğinizle etkileşime girdiklerinde ne deneyimlediklerini ve hissettiklerini görselleştirebilirsiniz.
Ürün sahibinin, tasarladığı işlevselliğe kullanıcılarının bakış açısından baktığında bunun en iyi seçenek olmadığını anlaması oldukça yaygındır.
Ben de bunu birçok kez yaşadım. Örneğin, bir matematiksel formül düzenleyicisi için gereksinimler oluştururken (o sırada geliştirmekte olduğumuz finansal analiz SaaS ürününün bir parçasıydı), düzenleme sürecinin şöyle görünmesini istiyordum:
- Formülün yanında bir düzenleme düğmesi.
- Düzenleme düğmesine tıklamak, formül alanını düzenlenebilir hâle getirecek ve ✅ Kaydet ile ❎ İptal düğmelerini gösterecekti.
- Bunlardan herhangi birine tıklamak düzenleme modundan çıkılmasını sağlayacak ve kullanıcının seçimine bağlı olarak kaydedilen yeni sürüm ya da formülün eski sürümü orada görünecekti.
Bu davranış mantıklı görünüyor, değil mi?
Aslında, analistlerin bunu kullandığı senaryoları yazmaya başlayıp önemli bir kullanılabilirlik kusuru keşfedene kadar öyle görünüyordu. Analistler genellikle formülde küçük değişiklikler yaparak ve istedikleri formülü elde edene kadar hesaplama sonucuna bakarak formülle oynarlar.
Düzenlemenin benim tasarladığım şekilde çalışması, hedef kullanıcılarım için son derece can sıkıcı olacaktı; çünkü art arda 20-30 kez düzenleme moduna girip çıkmaları gerekecekti. Bu nedenle hatayı fark eder etmez kabul kriterlerini hızla değiştirdim ve gerçek zamanlı olarak değişiklik yapabileceğiniz bir formül düzenleyicisinin geliştirilmesini istedim.
Tek Bir Doğruluk Kaynağı Oluşturmaya Yardımcı Olurlar
“Acemi” bir ürün yöneticisi olarak en büyük zorluğum, ürün gereksinimlerini farklı mesleklerden, hatta farklı ekiplerden insanlara aktarmaktı. Sorun, her birinin gereksinimleri farklı anlaması ve aralarındaki iletişimin belirsiz bir karmaşaya dönüşmesiydi.
İşte o zaman deneyimli bir ürün yöneticisi, ürün gereksinimlerimi çok net bir şekilde formüle ederek tek bir doğruluk kaynağı kavramını uygulamamı (gereksinimlerin toplanmasında yapay zekâ bu konuda yardımcı olabilir), bunu herkesle paylaşmamı ve çalışmalarını yalnızca orada yazılanlara dayandırmalarını istememi önerdi.
Bu büyük bir başarıydı; çünkü herkes özelliğin nasıl çalışması gerektiği konusunda aynı anlayışa sahipti ve herhangi bir anlaşmazlık olduğunda gereksinime geri dönüyorlardı.
Kabul kriterleri, özelliği açık ve okunması kolay bir şekilde tanımladıkları ve yüksek ayrıntı düzeyine sahip oldukları için (özelliğin tüm temel ayrıntılarını kapsamalıdır) tek bir doğruluk kaynağı oluşturmanın harika bir yoludur.
Kabul Testlerinin Kalitesini Artırırlar
Yazılım mühendisleri için kabul kriterleri, özelliği oluştururken izleyecekleri ürün gereksinimleri olarak hizmet eder. Öte yandan kalite ekibiniz için kabul kriterlerinin birkaç ek işlevi vardır:
Test senaryolarına öncelik vermeye yardımcı olurlar. Yazılım test ekibinizin bu özellik için çok sayıda test senaryosu varsa ve hepsini gözden geçirmek için yeterli zaman yoksa, en kritik kullanıcı akışlarını açıkladıkları için kabul kriterleriyle eşleşen test senaryolarına öncelik verir ve önce bunları çalıştırırlar.
Bir kabul kontrol listesi işlevi görürler. Bu nokta hem KG ekipleri hem de özelliği kabul etmesi gereken ürün sahipleri için geçerlidir. Kabul kriterleri, adından da anlaşılacağı gibi, özelliğin başarılı/başarısız durumuna karar vermek için bir kontrol listesi görevi görür. Kabul kriterlerinden biri veya daha fazlası karşılanmazsa KG ekibi hikâyeyi yeniden açar ve mühendislik ekibinden eksik işlevselliği eklemesini ister.
Özetlemek gerekirse, kabul kriterleri ürün gereksinimlerini doğru bir şekilde iletmek isteyen ürün sahiplerinin elindeki paha biçilmez araçlardır. Peki iyi kabul kriterlerini nasıl yazarsınız? Şimdi bu konuda size yardımcı olayım.
İyi Yazılmış Kabul Kriterleri Nasıl Görünmelidir?
Yazdığınız kabul kriterlerinin kalitesi, ekibinizin teslim ettiği özelliklerin kalitesini doğrudan etkiler. Nelerin oluşturulacağı ve nasıl test edileceği konusunda net bir anlayışa sahip olan ekibiniz, özelliği minimum aksaklıkla sizin öngördüğünüz şekilde oluşturacaktır.
Kabul kriterleri yazma konusunda başarılı olmak için aşağıdakilere dikkat etmeniz gerekir.
Açıklık
Bir ürün sahibinin yapabileceği 1 numaralı günah, belirsiz ve muğlak kabul kriterleri yazmaktır. Yazdıklarınızı insanların birden fazla şekilde yorumlayabileceği ortak bir anlayış fikrini unutabilirsiniz.
Ne kadar büyük bir fark yarattığını görmek için size bir örnek göstereyim.
Bu cümleden ne anladınız? ATM'nin kullanıcıyı doğrulayıp doğrulamamaya karar vermek için kart türünü nasıl kullanacağını söyleyebilir misiniz? ATM, tüm bu kriterler aynı anda karşılanırsa mı kullanıcıyı doğrulayacak, yoksa yalnızca bir tanesinin karşılanması yeterli mi?
Bu kabul kriterini mühendislerinize verirseniz, sizi sorulara boğar ve gereksinimlerinizi daha açık ifade etmenizi isterler. Şimdi bunu daha iyi hâle getirelim.
Çok daha iyi görünüyor, değil mi? Bu kabul kriteriyle yukarıdaki tüm soruların yanıtlarını da vermiş olduk. ATM'nin kullanıcının taktığı kart türünü desteklemesi ve ATM'nin kimlik doğrulaması yapabilmesi için üç kriterin de aynı anda karşılanması gerekir.
Uzman İpucu: Kabul kriterlerinizi SMART (özgül, ölçülebilir, ulaşılabilir, ilgili ve test edilebilir) hâle getirin. Evet, sonuncusunu test edilebilir olarak değiştirdim; çünkü etkili kabul kriterlerinin önemli bir özelliğidir.
Okunabilirlik
Kabul kriterlerinizde muğlaklıktan kaçınmanın yanı sıra onları basit tutmalı ve gösterişli terimlerden veya karmaşık İngilizceden kaçınmalısınız.
İngilizcedeki en gösterişli ve karmaşık kelimeleri ve ifadeleri kolayca okuyup anlayabilen, yüksek eğitimli yıldızlardan oluşan bir ekibiniz olduğuna eminim; ancak bilişsel güçlerini metinlerinizi çözümlemeye harcamalarını gerçekten istemezsiniz.
Bu nedenle, bunun yerine.
Bunu söyleyin.
İlk kabul kriterini tamamen okumaya bile zahmet etmediğinizi varsayıyorum; çünkü siz de zamanınızı ve zihinsel gücünüzü boşa harcamak istemediniz!
Durumların Kapsanması
Şeytan ayrıntıda gizlidir. Bazen geliştirme aşamasında çok geç bir noktaya geldiğinizde özelliğinizde gözden kaçırdığınız can sıkıcı bir durumu fark eder ve bunun için takip niteliğinde bir geliştirme görevi açmanız, hatta tüm işi baştan yapmanız gerekir.
Tanıdık geliyor, değil mi?
Kabul kriterlerinizde başlangıçta ne kadar çok durumu göz önünde bulundurursanız, iş listesi öğelerinizde böyle bir senaryoyla karşılaşma olasılığınız o kadar azalır.
Şimdi aşağıdaki kabul kriterlerine bakalım.
Burada tuhaf bir şey görüyor musunuz? İlk bakışta gereksinim açık: e-posta adresini ekliyorsunuz, gönder düğmesine basıyorsunuz ve kişi erişim kazanıyor. Gerçekte burada birçok durumu göz önünde bulundurmamışız:
- E-posta adresi belgeye erişimi olan kullanıcılar listesinde zaten varsa, kullanıcıya bunu bildiren bir hata mesajı göstermek iyi olabilir.
- Kullanıcıya bir davet e-postası göndereceksiniz; bu nedenle paylaşılan listenizde daveti kabul edip etmediğini göstermek faydalı olabilir.
- Davetiyeyi kabul etmediyse, “daveti yeniden gönder” düğmesi eklemek iyi olabilir.
Ayrıca bir şey boş olduğunda veya bir hata meydana geldiğinde özelliğinizin davranışını netleştirdiğiniz negatif durumlar da vardır.
Görsel Yardımcıların Etkin Kullanımı
Yukarıda paylaştığım kabul kriterleri sizin için tamamen açık mıydı? “Kişi ve Grup Ekleme” alanından bahsettiğimde, bunun neyle ilgili olduğunu net bir şekilde anladınız mı?
Bazen gereksinimleri ekibinize açıklığa kavuşturmak için kelimeler yeterli olmaz; anlatmak yerine göstermek daha iyi olabilir. Şimdi bu kabul kriterlerini biraz geliştireyim.
Görseli ve yorumlarımı yan yana görseydiniz, bu kabul kriterleriyle ne anlatmak istediğimi kolayca anlayacağınızı varsaymakta haklı mıyım? Bence anlardınız.
Böylece kabul kriterlerinin “kabul kriterlerini” ele aldık; şimdi ürün ekiplerinin kullandığı farklı türleri ve biçimleri inceleyelim.
Yaygın Kabul Kriteri Biçimleri
Size karşı açık konuşmam gerek. Kullanıcı hikâyelerimin tamamında nadiren aynı biçimi kullanırım. Bunun nedeni, farklı kabul kriteri biçimlerinin farklı kullanım alanları için uygun olması ve kendinizi her zaman aynı biçimi kullanmaya zorlamanın her zaman iyi bir fikir olmamasıdır.
Bu nedenle biçimi, hikâyeye ve kabul kriterlerinde yazmak istediğim bilgi türüne göre seçerim.
Şimdi yaygın biçimlerden bazılarına ve bunlara karşılık gelen kabul kriteri örneklerine bakalım.
BDD Biçimi
BDD, Davranış Odaklı Geliştirme anlamına gelir ve yazılım geliştirme ile ürün ekibi üyelerini, gereksinimleri son kullanıcılarının özellikle nasıl etkileşime gireceklerine göre tanımlamaya teşvik eden bir çerçevedir.
Kullanıcı davranışına dayalı gereksinim yazma yöntemi olarak BDD kabul kriterleri şu özel şablonu izler:
Verilen: Belirli kullanıcı davranışı senaryosunun ön koşulu.
Ne zaman: Kullanıcının gerçekleştirdiği eylem.
Ardından: Eylemin sonucu.
Örneğin bir ATM'nin para çekme özelliğinin nasıl çalıştığını açıklamak isteseydiniz, kabul kriterleriniz şöyle görünürdü:
Kabul kriterlerinin verilen/ne zaman/ardından biçimi, kullanıcı bakış açısını vurgulayarak ekibinizde kullanıcı ihtiyaçlarına yönelik empati oluşturmak istediğinizde oldukça etkilidir.
More Articles
Kontrol Listesi Biçimi
BDD'nin (diğer adıyla “senaryo odaklı” biçimin) aksine, bu biçim son kullanıcının bakış açısını göstermez. Bunun yerine, özelliğin iş mantığının uyması gereken belirli kuralları açıklamaya odaklanır (bu biçimin alternatif adı “kural odaklı”dır). Şöyle görünür:
Açıklamak istediğiniz mantık karmaşıksa bu biçim sizin için en uygun seçenek olacaktır; çünkü mantığı anlaşılması ve uygulanması daha kolay olan birden fazla küçük kurala ayırmanıza yardımcı olur.
Akış Biçimi
Bu muhtemelen en çok kullandığım biçimdir.
Akış biçimi, kullanıcının bakış açısını göstermesi bakımından BDD biçimine benzer. Ancak BDD'nin aksine katı bir yapı (Verilen/Ne Zaman/O Zaman) dayatmaz. Bu nedenle, kullanıcının attığı adımları istediğiniz şekilde anlatmakta özgürsünüz.
Kayıt olma süreci bu biçimde şöyle görünürdü.
Bir kullanıcı empatisi oluşturmak (tıpkı BDD'de olduğu gibi) istiyor ancak katı bir yapıyı takip etmek istemiyorsanız, akış biçimi en iyi seçeneğiniz olacaktır.
Kabul Kriterleriyle Herkesin Aynı Noktada Olmasını Sağlayın
Kabul kriterleri, ürün sahiplerinin elindeki güçlü araçlardır; tek bir doğruluk kaynağı oluşturmalarına ve ekip arkadaşlarının söz konusu özellikle ilgili vizyonlarıyla uyumlu kalmalarına olanak tanırlar.
Ürün profesyonellerine yönelik bunun gibi daha fazla rehber ve diğer harika kaynaklar için bültenimize abone olun!