Çoğu BT ekibi, bazen mevcut personelle üstesinden gelinmesi imkansız olan çok sayıda role ihtiyaç duyar. Ve bu gibi durumlarda yapılacak ilk şey, ekip üyeleri arasında görev dağılımı yapmaktır. Burada, KG görevlerinin devredilmesinin ürününüz için neden tehlikeli olduğunu düşünmeye çalışacağız.

Her zamanki mağaza

Bir şirkette yeni bir BT ürününün PO'su olduğunuzu düşünelim. Ürün perspektiftir, rakipler arkanızda ama o kadar uzak değil ve en kısa zamanda bir ekip tutacaksınız. Önceki tüm projelerinizi, geçmiş deneyimlerinizi düşünüyorsunuz ve üç BE geliştiricisine, iki FE geliştiricisine, bir QA uzmanına (elbette otomatik testler bilgisine sahip), bir scrum ustasına, bir iş analistine ve bir UX/UI'ye ihtiyacınız olduğuna karar veriyorsunuz. tasarımcı. Ardından, bütçe tahmininden sonra, projenin bu kadar çok ekip üyesini karşılayamayacağını anlarsınız ve gerçekte kimin gerekli olduğuna karar vermeniz gerekir.

Tamam, kod kendi kendine yazamaz, bu nedenle geliştiriciler gereklidir. Bu yıl zaten tatilde olan 2 BE geliştiricisi ve 1 FE geliştiricisi ile hayatta kalmaya karar veriyorsunuz.

Gereksinimleri toplayabilirsiniz, ancak dürüst olalım, Jira'da görevler oluşturmak ve dokümantasyonu sürdürmek dışında yapacak çok şeyiniz var. Yani en azından iş analistleri size bu konuda yardımcı olma sorumluluğunu alabilir.

Bir prototip olmadan çalışmaya başlayamazsınız, bu nedenle bir UX/UI tasarımcısına ihtiyacınız var.

Herkes yeni ürünlerle yüksek motivasyona sahip, daha önce scrum ile çalıştı ve artık bir scrum ustasına gerek yok.

Zaten bütçeniz tükendi, ancak testten kim sorumlu olacak? Birkaç görüşmeden sonra, ekibinizle birlikte başlangıçta iş analistlerinin test senaryolarını da kapsayabileceği konusunda karşılıklı bir anlaşmaya varırsınız. Ancak ürün büyür gelişmez, bir KG mühendisi işe alacağız.

Geliştirme başladı, birkaç ay geçti ve her şey mükemmel çalışıyor ancak paydaşlar daha fazla özellik bekliyor. UX/UI tasarımcısı, her zamanki gibi önceden tüm prototipler üzerinde çalışır ve geliştirmeye hazırdır ve siz daha fazla geliştirici tutmaya karar verirsiniz. Evet, herkes QA'yı işe almayı planladığımızı hatırlıyor, ancak yeni özellikler geliyor, bu çok heyecan verici! Tabii ki, bazı hatalarınız var, bunlar kritik değil ve zaten birikmiş durumda, bu yüzden endişelenmeyin.
Ürün büyüyor ve paydaşlar mutlu. Teknik birikmiş işler beklenenden daha büyük, ancak ekip üyelerinin çoğu kritik sorunları nasıl çözeceklerini ve sistemi nasıl geri yükleyeceklerini biliyor.

Borç kartopu

Ama birikmiş listemizin en altından bu küçük hataları düşünelim. Bunların temel nedeni neydi? Bir kod incelemesi yapıldı. İş analisti işlevselliği kontrol etti. Neden ortaya çıktılar?

Ne yazık ki, ana faaliyetlere paralel olarak uygun testler yapılamaz. Ürün sahibi ve iş analisti süreçleri anlar ve işlevselliği test edebilir, ancak genellikle hatalar bazen kabul kriterlerinde açıklanmayan "özel" durumlarda ortaya çıkar.

QA uzmanları, genellikle bazı özel durumlarda hataları bulmak için bu süper güce sahiptir. Evet, kulağa bariz geliyor, ancak bir ekipte QA'ya sahip olmanın uzun vadeli avantajlarını en başından vurgulamak istiyorum.

Sistemdeki hatalarla ilgili sorunlardan biri de dikkat gerektirmesidir. Başlangıçta çok fazla sorununuz yok, bu nedenle ekip QA olmadan testi yönetebilir gibi görünüyor. Ancak test kalitesi çok düşük ve binlerce satır kodunuz olduğunda hangi yerin düzeltilmesi gerektiğini araştırmak giderek daha karmaşık hale geliyor. Ayrıca, 1 gün önce yazdığınız kodu düzeltmek, birkaç ay önce yazılan koddan daha kolaydır.

odak süresi

Her geliştirici, bir görevden diğerine geçmenin ne kadar zor olabileceğini bilir. Bazı gerçekten karmaşık görevler, 1-2 saatten fazla derin odaklanma gerektirir. Yani ideal bir dünyada, bir geliştirici gün boyunca 1 göreve odaklanabilir ve bir önceki kapatıldığında yeni bir göreve başlayabilir.

Odaklanmak biraz zaman alır ve en verimli zaman, 10-20 dakikalık bir görevden sonra başlar. Dolayısıyla odaklanmadaki artışın geliştirme sürecini hızlandırdığı konusunda hemfikir olabiliriz.

Gerçek dünyada elbette başka birçok anlaşmamız, tartışmamız, araştırmamız ve acil görevlerimiz var ve bu nedenle çalışma günleri odaklanma süresi açısından istediğimiz kadar ideal değil.

Yine de bu o kadar da kötü değil elbette günün sonunda odaklanmamız azalıyor ama kod inceleme ve tartışmalar da çalışma süremizin bir parçası ve bundan kaçınamayız.

Ancak bir geliştirici, başlangıçta düzeltilmemiş günlük küçük sorunlarla dikkati dağıldığında ne olur?

• "Cron işi yine başarısız oldu, lütfen yeniden başlatır mısınız?"
• "Ah, dahili bir sunucu hatası var, lütfen günlükleri kontrol eder misiniz?"
• “Rapor 1 dakikadan fazla yükleniyor, lütfen bir göz atın”

Elbette gerçekte iş günü boyunca daha fazla olay oluyor, ancak ana fikir, görevlere daha az odaklanmanın daha az kalite ve geliştirme hızı anlamına geldiğidir.

Uzun vadeli görüş

Bu hataları üretimde ortaya çıkar çıkmaz düzeltmemiz gerekiyor. Ancak devam etmekte olan düzenli özelliklerimiz de var ve sprinti kaybetmeyi göze alamayız. Ve ne zaman takım bir karar vermek zorunda kalsa: eski bir hatayı hemen şimdi düzeltin mi yoksa mevcut görevi bitirip bir sonraki Sprint'te düzeltmeyi mi planlayın? Ekibin özellikleri zamanında teslim etme taahhüdü vardır ve bir keresinde bu hiç bitmeyen bir hikayeye dönüşür.

Bu tür hatalar başlangıçta QA tarafından vurgulanabilirdi, ancak sorumlu bir kişimiz yoktu ve geliştirme hızı öncelikliydi. Ve bu doğru, QA tarafından vurgulanan hataların olmaması, ekibin destek taleplerini daha hızlı kapatmasını sağlar. Aşağıdaki şemaya bakın:

Geliştiriciler görevlere odaklanır ve genellikle kod incelemesinden sonra kapatılır, böylece bir sonraki görev üzerinde çalışmaya başlayabilirler. Ancak bulunan hatalar ve sorunlar nedeniyle QA katılımı ile döngü süresi artacaktır.

Ancak uygun KG testi olmadan birkaç ay çalıştıktan sonra daha fazla hatayla ve bilinen sorunla karşılaşacaksınız ve incelemeniz daha uzun sürecektir.

Yıllarca böyle bir yaklaşımdan sonra, sprint hızı önemli ölçüde azalacaktır:

Bir takımın bir sprintte kaç hikaye puanı alabileceğini anlamak giderek daha karmaşık hale geliyor. Bazen geliştirmeyi durdurmak ve teknik birikmiş işler için tam bir sprint harcamak gerekir. Ve tabii ki odaklanma süresi kaybı yeni hatalara ve yavaş bir geliştirme sürecine yol açar.

Son düşünce

Elbette, Kalite Güvencesinin iş itibarı açısından önemli olmasının birçok farklı nedeni vardır, ancak QA'yı en baştan bir ekipte tutmanın stratejik avantajlarını vurgulamak istiyorum. Bazen bazı QA etkinliklerinin diğer ekip üyelerine devredilebileceği görülüyor, ancak bu tam olarak doğru değil. Bu, iyi dağıtılmış bir sorumluluğun yanlış bir temsilidir ve bir gün bu saatli bomba, projenin daha da geliştirilmesi için bir tehdit haline gelecektir.