Edge Davaları İçin Kabul Kriterleri

Çevik bir ekipte ürün sahibiyim. PO kabul testi yaparken genellikle bazı uç durumları denemek için not alırım. Bir şey keşfetmek benim için nadir değil ve sonra devs için geri geçmek. Hikayelerini reddettiğimde geliştiricilerden birinden geri çekiliyorum. Son vakaları ve programın kabul kriterlerinde nasıl yanıt vermesi gerektiği için haksız olduğunu söylüyor, çünkü sadece hikayede tarif ettiğim şeyi kodlama eğiliminde. Kodlama sırasında herhangi bir uç davaya çarparken bana sormasını teşvik ettim, ancak işinin uç davaları, benimkini düşünmek değil, bir sonraki sprint için yeni hikayeler yapması gerektiğini düşünüyor.

Savunmamda öykü için tasarımını o uygulayana kadar bilmiyorum, bu yüzden tüm olasılıkları tekrarlamak zor (bir DB veya özellikler dosyasında mı olacak?). Basitlik adına, hesap makinesi uygulamasına bölüm eklemek için bir hikayemiz olduğunu varsayalım. İdeal SCRUM dünyasında, kabul kriterlerine bir "sıfır senaryo ile bölme tutamacı" eklemek benim için geçerli olacak mı yoksa uygulama 5/0 üzerinde zorlanmayacak şekilde geliştikçe bu durumlar üzerinde çalışıyor mu? Açık olmak gerekirse, bu durumda uygulama 5/0'da sert bir şekilde çöktüğünde kabul etmem, ancak günlük kaydeder, DIV0 yazdırır veya hatayı işlemek için başka bir yol ... çökmedi.

Bence cevap, ikinizin de kendi uç durumlarınızı düşünmeniz gerektiğidir. Geliştirici, herhangi bir kullanıcı girişinden uygulama çökmesi gibi verilere özgü kenar durumlarını ele almalıdır, 5/0 kesinlikle spektrumun bu kısmına düşer. Geliştiricinin, kullanıcının etkileşiminin bir parçası olarak verilen girdi geçersiz bir şeye yol açtığında size uygun bir hata mesajı olacağını düşündüğünüzü sorması gerekir.

Yelpazenin sizin tarafınız, şeylerin iş tarafıdır. Kullanıcının hesabının böl düğmesini kullanmasına izin verilmiyorsa hesap makinesi nasıl davranmalıdır? Hesabın Mod işlemini kullanmasına izin verildiğinde, ancak bölme özelliğine erişimi olmadığında nasıl davranmalıdır?

Tüm ekip üyelerini iletmeniz ve kabul etmeniz gerektiğini düşündüğüm önemli mesaj, hepinizin aynı ekipte olmanızdır. Ürün tamamlanmadıysa, ürün tamamlanmamıştır ve takım sorumlu değildir, herhangi bir üye değil.

Takımın "Benim işim değil, benim sorumluluğum değil" tipi bir tavır / mantranın aksine birlikte çalışması gerekir.

Kabul kriterleri şu şekilde gelir:

• İş Kabulü
• Kalite Güvence Kabulü

Genellikle iş kabulü genellikle şu soruyu yanıtlamaktadır:

• Uygulanan özellik yapmak istediğim şeyi yapıyor mu?

Özellik, iş odaklı bir dizi gereksinime sahip olacak, bu düğmeye basarsam bu eylemin gerçekleşmesini bekliyorum. Beklenen iş senaryolarını ve beklenen davranışları listeleyecektir, ancak olası tüm durumları kapsamaz .

Kalite güvencesinin ticari olmayan gereksinimlerle ilgili herhangi bir teknik geliştirebilmesi için, iş gereksiniminin bir yinelemeden önce tanımlanması beklenir. Kalite güvencesi, yıkıcı vakaları ve gerektiğinde son vakaları geliştirmelidir.

Herhangi bir öykü çalışmasına başlamadan önce her iki gereksinim kümesi de gözden geçirilmelidir, böylece iş birimi için resmi bir tahmin ve taahhüt gerçekleşebilir. Bu yapıldıktan sonra, özellik / hikayeler üzerinde çalışılabilir. Bu noktada herkes, hem iş hem de teknik açıdan nelerin sunulacağı konusunda açıktır.

İş ve kalite güvence ekibi üyeleri hikayeyi imzaladıktan sonra hikaye son kabulüne ulaşır. Bu, hem iş kabulü hem de kalite güvence kabulü için yineleme sırasında gerçekleşmelidir. Bu, ek hikaye çalışmasının başlatılabileceğini gösteren tamamlanmış (DoD) tanımdır.

Yeni bulgular kusur veya ek hikaye ani olarak kaydedilebilir. Mükemmel bir dünyada bu asla olmazdı, ama gerçekte bir özellik / hikaye üzerinde çalışırken genellikle bir miktar “keşif” vardır. Bu doğal.

Takım birlikte çalışmalıdır gereklerin herhangi belirsiz keşif türü dışarı karma (iş, QA, geliştirici). Bu çevikse, ortaya çıkabilecek sorulara iletişimi ve hızlı çözümü teşvik etmek için hepsi aynı masada oturuyor olmalıdır. Bunun gibi bir şey olmalı:

QA:

"Hey, Geliştirici bu özel senaryoyu ele almalıyız. Bu verileri girersem bir hata aldığımı keşfettim."

DEV:

"Bu herhangi bir gereksinimin kapsamına girmedi, ancak bunu kapsayacak ek işlevler ekleyebiliriz. Tamam, Hey İş Adamı, uygulamanın> bu durum için nasıl davranmasını istersiniz?"

İŞ:

"Standart hata mesajımızı gösterelim ve kullanıcının bu senaryo için tekrar denemesine izin verin. O zaman ne kadar fazla çaba gösterilecek?"

DEV:

"Kolay olacak, sadece bir iki saat daha. Bu yineleme için taahhütte bulunabilirim. KG lütfen bu senaryo için kabul kriterlerinizi güncelleyin, bunun için ek bir hikayeye ihtiyacımız yok. Teşekkürler!"

Ya da çok fazla iş varsa, biriktirme listesine yeni bir hikaye eklenir. Takım, orijinal hikayeyi tüm orijinal gereksinimleri karşıladığı için kabul edebilir ve bir sonraki yinelemede başak hikayesini alabilir.

Yanlış veya belirsiz girdi karşısında sağlam bir şekilde davranan yazılım yazmak, bir yazılım geliştiricisinin işinin önemli bir parçasıdır.

Geliştiricileriniz bu şekilde görmezse, gereksinim belirtimine bu gereksinimi açıkça ifade eden ek işlevsel olmayan gereksinimler ekleyin ve geliştiricilerinize, final işlemlerini göndermeden önce bu işlemi kendileri uygulayabilmeleri için test sürecinizin bir örneğini sağlayın. inceleme için kod.

Kabul testleri, her türlü gereksinim belgesinin hayati bir parçası olmalıdır. Bir gereklilik kabul kriterlerini de belirtmezse, bu gerçekten bir gereklilik değildir; bu bir dilek.

Burada olan, değer keşfettiğinizdir . Giriş değeri, hikayenin (ve kabul kriterlerinin) ne zaman yazıldığı veya kodun ne zaman yazıldığı düşünülmüyordu. Kabul kriterlerinin bir parçası değilse, hikayeyi reddetmek için gerçekten bir temeliniz yoktur.

Ekibimde yapacağımız şey:

1. Beklenen ve gerçek davranışı detaylandıran bir Hata oluşturun.
2. Kabul kriterlerini, bulunan yeni gereksinimin belgeleneceği şekilde güncelleyin.
3. Sonraki yinelemede diğer tüm Hikayeler ve Hatalarla birlikte Hataya öncelik verin.

Buradaki fayda, bu hatayı düzeltmenin bir sonraki en önemli şey olup olmadığını düşünmek zorunda kalmanızdır. Düzeltmek için yeterince önemli olabilir veya olmayabilir, ancak değerinin dikkate alınması önemlidir.

Tabii ki, yine de geliştiricileri (ve kendinizi) bu uç vakaları önceden keşfetmeye teşvik etmek için bir yol bulmanız gerekiyor. Geliştirici ekibiniz hikayeleri parçalamak için zaman harcamıyorsa, üzerinde çalışmaya başlamadan önce ayrıntılı bir planlama oturumu yapmaya teşvik edin.

Bazı gözlemler:

... hikayelerini reddettiğimde

Çalışma kültürünüzü veya sürecinizi bilmiyorum, ama bana göre bir hikayeyi reddetmek ciddi bir adım. Eğer geliştirici olsaydım, bana ve takıma kötü yansıyan kaydedilmiş bir eylem olduğu için buna geri iterdim.

Uç vakaları belirtmediğim için haksız olduğunu söylüyor.

Tüm uç vakaları bilmenizi beklemek haksızlıktır. Ama aynı zamanda, ondan beklemeniz haksızlık olur. Her değişikliğin riski vardır ve sorunlar keşfedildikçe, bunları ele almak için bir ekip olarak birlikte çalışmanız gerekir.

Hikaye için tasarımını, uygulayana kadar bilmiyorum

Tasarımı bilmek zorunda değilsiniz. İş yükü yönetimi için hangi hikayelerin daha kolay veya daha zor olduğu hakkında ilk eğitimli tahminler yapmak için tasarımı bilmek faydalı olabilir. Ancak, hikayeler yazarken geliştiriciyi tasarımınıza hapsetmekten kaçının. PO için sesle etkinleştirilen bir klavye olduğunuzda tüm eğlenceyi berbat eder.

Süreç iyileştirme üzerinde çalışmanız ve bazı ekip oluşturma yapmanız gerektiği anlaşılıyor. İşlem için önerebileceğim bazı şeyler:

• Geliştiricinin, keşfedilen uç vakaları tespit eden kapak için hikayeye zaman eklemesini önerin. Heck, her kullanıcı hikayesinin bir parçası olun. Bu, tanıtılan 0 yeni böcek hedefi ile kolayca savunulabilir. Sorun şu ki geliştirici şu anda planlamıyor. Ve sorunları keşfettiğinizde zamanı doldu. Her iki şekilde de zaman alacaktır, bu yüzden planlama sırasında görünür olduğu hikayeye koyun.
• Testinizden sonra (ve bu arada test ettiğiniz için teşekkür ederiz!), Geliştiriciye keşfedilen sorunların bir listesini gönderin. Bu sorunların giderilmesi, "son vakaların tespiti" memnuniyet durumuna aykırı olacaktır.
• Sabit olmayan bir şey kalırsa veya çok geç keşfedilirse, kullanım senaryosunun yerine getirilip getirilemeyeceğine bağlı olarak öykünün aktarılması gerekip gerekmediğine karar verin. Bilinen sorunlar ve geçici çözümler olur. Onları sürüm notlarında açıkladı ve düzeltmek için yeni hikayeler yaratın.
• İşlemde geri itme oluşturan belirli bir kaba nokta varsa, işleminizi değiştirin! Sonuçta, süreç iyileştirme Scrum'ın bir parçasıdır. Örneğin, hikayenizi reddettiğinizde geliştiriciniz üzülürse, ekibe düzeltmenin tetiklenmemesi için ekibe işlemde bir değişiklik önerin. Tamamlanmadan ve Reddedilmeden önce testi ve düzeltmeleri yapın.
• Takımla ve ürettikleriyle çalışın ve en iyi şekilde yararlanın. Mükemmel bir iş yapmıyorlar ve siz de yapmıyorsunuz. Öyleyse planlayın. Takımlarım genellikle adanmışlardı, bu yüzden ortaya çıkan sorunlar için her sprint'te Planlanmamış Destek kullanıcı hikayemiz var ... planlanamayanları planlıyoruz.

Gereklilikler açık ve öz olmalıdır. Eğer değillerse, tam olarak size olanları olur. Bu sizin hatanızdır ve gereksinimleri belirlerken yapabileceğiniz en kötü şey bir şeyleri varsaymaktır.

Sıfıra bölme hakkında belirli bir örnek. Hatayı günlüğe kaydetmek istediğinizi belirtmediyseniz, geliştiricinin sonuç olarak 100 yazdırıp yazdırmadığından şikayet etmeyin.

Ancak bu gibi durumlarda, eksik boşlukları doldurup geliştiriciye iletirim. Sonuçta, gereksinimlerdeki hatalar gerçekleşir.