Kuruluşumda Kalite Güvence / Test yöneticisiyim ve bugüne kadar yazılımın kalitesini doğruladım (testler yazıldı ve yürütüldü ve hatalar düzeltildi). Scrum'da bunu kim doğrulayacak? Ekibin tüm doğru testleri yazdığını ve yaptığını nasıl bilebilirim? Öte yandan, doğrulamayı yapmaya devam edersem ekibin yeterince güçlenmiş hissetmeyeceğinden korkuyorum. Ama "Bitti" nin gerçekten "Bitti" olduğunu belirten bir doğrulama sürecine ihtiyacım var. Sen ne önerirsin?
Yanıtlar:
Scrum'daki ana fikirlerden biri, ekibin "tamamlanmış bir tanım" üzerinde anlaşması gerektiğidir. İdeal olarak, bu, bir kontrol listesinden geçerek herkesin doğrulayabileceği bir dizi nesnel kriter gibi bir şeydir.
Ancak, bir şeyin kayma olasılığını azaltmak için, bir öğeyi uygulayan kişiden veya sizin gibi belirlenmiş bir KG ekibinden başka biri tarafından en çok "tamamlandığını" doğrulayan bir kurala sahip olmak mükemmel bir anlam ifade eder (ancak bu, bir darboğaz).
Şüpheniz varsa, ekip ve Scrum Master ile tartışın ve birlikte karar verin.
Soruda örtük bir varsayım olduğunu düşünüyorum. Bir Ürün Sahibi bir biriktirme öğesi veya görevi Ürün Sahipini tatmin ettiğinde "kabul edildi" ve "tamamlandı" arasında bir fark vardır; bu da biriktirme öğesi ile ilişkili tüm işlerin tamamlandığı anlamına gelir.
Bununla birlikte, bir görevde düzenli olarak Ürün Sahibinin görebildiğinden daha fazlası vardır, genellikle (otomatik ve manuel) test, dokümantasyon ve inceleme dahil olmak üzere en iyi yarı teknik bir kişi. Ürün Sahibi, tamamlanıp tamamlanmadığını, nadiren teknik yönleri bilme pozisyonundadır.
Bu nedenle, sonuçta "yapılan" ın ne anlama geldiğini belirlemek takımın görevidir. Kuruluşun standartları olabilir ve farklı paydaşların kendi gereksinimleri vardır. Scrum yöneticisi veya ilgili yöneticiler genellikle listenin harmanlanması ve uygulanmasından sorumludur.
Örneğinizde, KG / Test yöneticisi olarak, testlerin tamamlanıp tamamlanmadığını söyleyen sizsiniz. Ancak, kodun gözden geçirilip gözden geçirilmediğini, güvenlik gereksinimlerinin karşılandığını, ürünün uluslararasılaştırıldığını, belgelerin tamamlandığını veya başka bir şeyin "tamamlandığını" belirten en iyi kişi olamayabilirsiniz.
"Tamamlandı" kavramı, bir hikayenin bir bütün olarak tamamlanıp tamamlanmadığıdır. Takım, bir hikayenin bittiğini ya da bitmediğini hissettiğinde yapılan tamamın bir tanımını yaratmış olmalıdır. Bu genellikle "kod incelendi", "gecelik testler yapıldı", "tüm kabul ölçütleri karşılandı" vb. Şeyleri içerecektir. Bu şeyler tamamlandığında, ekip her şeyi yaptıklarından emin olabilir bir hikaye bitirmelerini bekliyordu.
Bir sprint sırasında, tamamlanan tanımdaki bu öğelerden birinin gerçekleştirilip gerçekleştirilmediğini belirlemeye çalışıyorsanız, sormanız yeterlidir. Scrum ve çeviklik tamamen açık iletişim ile ilgilidir. Ekibin bir parçasıysanız, ekip arkadaşlarınıza testleri yazıp yazmadığını veya çalıştırarak veya gece işini vb. Oluşturup oluşturmadığını sorun. Bir paydaşsanız scrum yöneticisine sorun.
Takımın dışında oturuyorsanız ancak yine de testleri gözden geçirmeniz gerekiyorsa, ekibin yapılan tanımın bir parçası olarak "testlerin kullanıcı kullanıcısı tarafından gözden geçirilmesi gerekir" ifadesini eklemesini sağlayın. Bir hikayenin yapılması için gereken buysa, bu konuda dürüst olun ve sürecin bir parçası olun. "Yapılan tanım" ın bütün amacı, ekibin kaliteli yazılım sunmak için gerekenleri yaptıklarını kesin olarak bilmesi. Bunun bir kısmı harici bir inceleme ise, öyle olsun.
Nihayetinde, belirli bir hikayeyi imzalayan ürün sahibidir, bu nedenle günün sonunda bir hikayenin bir bütün olarak yapılıp yapılmadığına dair nihai kararı verir.
İlk soru kendinize sormalısınız
Scrum Master siz misiniz ? Eğer evetse.
Scrum'da süreçler Scrum Master tarafından kontrol edilir ve yönetilir.
Bunu nasıl yapıyorsun:
Gereklilik aşamasında kullanabileceğiniz kullanıcı hikayelerini ihtiyaçları doğrulanacak bir test yoktur her biri için.
Her Sprint'te Çalışma öğeleri ürün biriktirme listesinden alınır ve ürün sahibi tarafından yönlendirilir. Her birinin de doğrulama kriterleri olacaktır.
Şimdi Scrum gereksinimlerinde sprint başladıktan sonra değişmez. Sprint'in sonunda yapılan her bir öğenin kriterlerine göre doğrulamayı analiz edebilirsiniz.
Bunun yapılması yalnızca Ürün sahibinin yanıtıyla bulunabilir.
Agile'de gelişim aşamasına geç bile "değişimi kucakla" yı hatırla
Takım karar verir. 'Bitti' sayılanlar için bir kontrol listesi kullanıyorum. Öykü başına, sprint başına, sürüm başına 'neler yapılır'.
Diğerlerinin de belirttiği gibi, sonuçta karar ürün sahibine aittir.
Bunun, kendi uygulamalarınıza bağlı olarak geliştirme / test ekibinin tanımlaması gereken bir şey olduğunu kabul edin. Bazı projeler o kadar çevik çalışır ki alfa akışlarına hata bırakma riskiyle karşı karşıya kalırlar; bazıları, geliştirme grubunun dışına çıkan herhangi bir hatayı işlem hatası olarak görür.
Üzerinde çalıştığım proje, kod değişikliklerinin hakem değerlendirmesini gerektirir ve kodu yazan kişi regresyon testlerini sağlar / günceller ya da bunu neden mümkün olmadığını açıklar. (Onlar ve yorumcuları da bilinen kötü uygulamaları kontrol ettiklerini onaylamak zorundadırlar. Tam test paketini çalıştırdıklarını ve temiz bir sonuç aldıklarını (veya temiz modulo aldıklarını gösterebilirlerse) genellikle çok daha mutlu oluruz. Daha sonra kod, bunlara karşı herhangi bir gerilemeye neden olmadığını göstermek için yoğun otomatik ünite ve işlevsel testlerden sonra hayatta kalmak zorundadır ve otomatik kod analiz sistemi tarafından ortak antipatterns için daha fazla kontrol edilir. sonra bunu ana geliştirme akışına kabul eder ve iş öğesini eksiksiz olarak işaretleriz.
Bu, hiç kimsenin başarısız olmanın yeni bir yolunu bulamayacağını garanti etmez, ancak gelişme hızını büyük ölçüde engellemeden riski kabul edilebilir bir seviyeye düşürür.
DoneveUndone