KG ikilemine karşı iterasyonlar

Şirketimde, çevik uygulamalarla başarılı bir şekilde çalışıyoruz - ancak yinelemeleri kullanmadan. Bunun ana nedeni, bir yineleme döngüsünde KG'ye uyum sağlamak için temiz bir yol bulamamamızdır.

KG'yi, bu yapı müşteriye dağıtılmadan önce belirli bir yapıya (sürüm adayı) fazladan bir doğrulama olarak anlıyoruz . Mesele, tek bir kötü niyetli taahhüdün tüm sürüme zarar vermesini önlemektir. Hangisinin olduğunu asla bilemeyeceğiniz için, KG sürüm için tüm özellikler / taahhütler yapıda olana kadar beklemek zorundadır . (Meşhur son sözler yok "Bu sadece küçük bir değişiklikti".

KG bir sürüm adayında hata bulursa, geliştiriciler bu hataları ilgili sürüm dalında düzeltir (ve gövdeye birleştirir). Tüm hatalar düzeltildiğinde, KG'nin yeniden test etmesi için yeni bir yapı devreye alınır. Yalnızca belirli bir sürüm adayında hiçbir hata bulunmadığında, müşteriye doğrulama için sunulur.

Bu genellikle sürüm başına yaklaşık iki ila üç aday, yaklaşık bir hafta sürer. Düzeltmeleri yazma süresi genellikle test çabalarından çok daha düşüktür. Bu yüzden geliştiriciler meşgul tutmak için KG N üzerinde çalışırken N + 1 sürümü üzerinde çalışıyorlar.

Yinelemeleri kullanmadan, bu sorun değil çünkü N ve N + 1 sürümleri için işi üst üste getirebiliriz. Ancak, anladığım kadarıyla, bu Scrum veya XP gibi yinelemeye dayalı yaklaşımlarla uyumlu değildir. Yinelemeye dahil edilecek tüm test çabalarıyla sonunda bir yinelemenin serbest bırakılabilir olmasını talep ediyorlar.

Bunun zorunlu olarak aşağıdaki istenmeyen sonuçlardan birine yol açtığını düşünüyorum:

(A) Geliştiriciler bir yinelemenin sonunda boşta kalıyor, çünkü KG'nin bir sürüm adayını doğrulamak için zamana ihtiyacı var ve hata düzeltme çalışmaları geliştiricileri tamamen meşgul etmiyor.

(B) KG, ilk sürüm adayı hazır olmadan önce çalışmaya başlar. Stack Exchange'de en çok tavsiye edilen budur. Ancak şirketimin KG olarak anladığı şey bu değil çünkü test edilen belirli bir sürüm adayı yok. Ve her şeyi kıran "küçük değişiklik" hala fark edilmeden tanıtılabilir.

(C) Hatalar bir sonraki yinelemeye taşınır. Bu, Stack Exchange'de de önerilir. Bunun bir çözüm olduğunu düşünmüyorum. Temel olarak, hiçbir zaman doğrulanmış bir yapı almadığımız anlamına gelir, çünkü hata düzeltmeleri yapıldığında, aynı şubeye de yeni, doğrulanmamış taahhütler eklenir.

Bu ikilemden çıkmanın bir yolu var mı?

KG'yi, bu yapı müşteriye dağıtılmadan önce belirli bir yapıya (sürüm adayı) fazladan bir doğrulama olarak anlıyoruz.

Bu kalite güvence formu ile Scrum gibi yinelemeye dayalı metodolojiler arasında doğal olarak uyumsuz hiçbir şey yoktur.
Scrum içinde, ekip müşterisinin X-haftalık döngüsünde bir teslim edilebilirlik sunar. Buradaki önemli kısım, eğer geliştirme ekibi Scrum yapıyorsa, müşterileri ürününüzün son kullanıcısı değil KG ekibidir.

Bir geliştirici olarak, tüm testlerini geçme konusunda savaşma şansı varsa, QA'ya gönderilebilecek bir ürünü düşünürüm. Bu, muhtemelen bazı QA testlerinin günlük yapılarda gerçekleştirildiği anlamına gelir, ancak bunun QA ekibinin resmi sürüm testlerini nasıl etkilediği kuruluşunuza bağlıdır.

Gerçek yaşam durumlarının çoğu için çevik kalite kontrol sistemi (UA) veya onun adı ne olursa olsun durur.

Gerçek yaşam ortamında KG'den Üretime geçme çabası genellikle hafife alınmaktadır. Birçok durumda bu test gerçek iş kullanıcıları, yönetim iş yöneticileri gerçek hattından çıkış, operasyonları vb ile yayın zamanlama vb içerir. Bu önemsiz değil!

Aşırı durumlarda yazılımın dış kuruluşlar tarafından sertifikalandırılması gerekebilir veya sıkı güvenlik testlerine tabi tutulabilir.

Bu durumlarda, hata düzeltmeleri dışında her çeyrekte birden fazla sürüm öngörmek imkansızdır.

Ciddi bir yazılım ürünü için daha da kötüleşir. Belgelerin kanıtlanması ve yayınlanması gerekir. Pazarlama broşürlerinde değişiklik yapılması gerekmektedir. Satış elemanlarına ne sattıkları söylenmelidir (kolay bir iş yok!) Vs. Gerçekten bu işi yılda bir kereden fazla yapmak istemezsiniz.

Çok kısa vadeli çözüm, QA'ya, testi sonlandırmak için yinelemenizden sonra ekstra bir süre vermektir. yani. Eğer iki haftalık bir yinelemeniz varsa, 3. haftaya kadar yayınlamayın.

Ama ne olacağı konusunda sizi uyaracağım (bunu birkaç takımda gördükten sonra): İki haftalık bir iş yaptığınız bir yinelemenin olduğu, QA'nın aşırı yüklendiği bir durumla karşılaşacaksınız, bunun için size geliyorlar tüm KG haftası ve sonraki yinelemede yalnızca bir haftalık işiniz olur. Bu yinelemenin, KG'nin yapacak bir şeyi olmayacak ve sorunu çözdüğünüzü düşüneceksiniz. Ama sonra bir sonraki yineleme döngüye tekrar başlayacaksınız.

Yani, o haftayı eklediğiniz anda, sadece sürümünüzün istikrarlı olduğundan emin olmak için (öğrendiğim bir şey, işin inancını kaybederseniz, Agile'ın katlanarak uygulanması zorlaşır, düz olsun uzun vadeli plan üzerine.

Jez Humble'ın Sürekli Teslimatının bir kopyasını satın alın , okuyun, örtbas edin, ekibin etrafından geçirin. Herkese ilham verin. Sonra ondan yapabileceğiniz her şeyi uygulayın.

Yapım sürecini olabildiğince kaygan hale getirin. Birim testi politikası uygulayın ve her derlemede yayınlanmaya başlayın. Dağıtım işlemini şimdiye kadar gördüğünüz en şık şey haline getirin. Üç tıklama mı? Yeterince kaygan değil.

Tüm bunları yaptıktan sonra, zaman zaman regresyon hatası geçerse çok fazla önemli olmayacaktır. Neden biliyormusun? Çünkü iş parçalara ayrılmadan önce (isteğe bağlı olarak) geri alabilir, düzeltebilir, yeniden dağıtabilirsiniz. Aslında gece kapıcısı sizin için geri dönebilecek, süreç çok basit olacak.

Ne düşündüğünü biliyorum: Bütün bunları yapacak zamanımız yok. Size söyleyeyim, biliyorsunuz. KG'yi aşırı yüklüyorsanız, yineleme başına çok fazla dağıtım yapıyorsunuz. Öyleyse yapma. Zaten aşırı yüklemiyorsanız, neden henüz otomatik test paketlerine sahip olmadıklarını sorun. Yakında olacaksın.

Tüm bunları işletmeye tam görünürlükle yapın. Daha düşük tahmin edin ve bu çalışmaların bir kısmını yinelemeye enjekte edin. Ya da, daha iyisi, hikayelere ayırın ve diğer her şeyin yanında, onları önceliklendirmelerini sağlayın.

Onlara a) sürümün kararlılığını artıracağını ve b) onlar için sorunlara cevap verme yeteneğinizi artıracağını ve c) daha sonra daha fazla hız alacağını açıklayın. Bu şeyleri istemeyen nadir bir şirket. Kesinlikle onları istemeyen bir Agile şirketi değil, eğer direnirseniz, farklı bir sorununuz olduğunu bileceksiniz.

Sürekli Teslimatı aldıktan sonra, KG'nin yinelemenin sonunda aldığı süreyi kısaltmaya başlayabilirsiniz. Yinelemeleri mümkün olan en kısa sürede tekrar paralel hale getirmek herkesin yararınadır. Belki yinelemenin sonunda bir gün geçirirsiniz, burada zaman doldurmanız gerekir. Başka bir yerde bu konuda ne yapacağımı zaten cevapladım .

Yinelemeleri kullanmadan, bu sorun değil çünkü N ve N + 1 sürümleri için işi üst üste getirebiliriz.

Tam olarak neyi oluşturduğuna karar verme şeklinizde bir sorun var gibi görünüyor work for release N.

Garip bir nedenden ötürü (sadece belirli Çevik tariflerin bazı yanlış anlaşılmaları olduğunu tahmin edebilirim) bir şekilde çevik yaklaşımın tüm KG ekibinin iterasyona dahil edilmesi çabalarını zorunlu kıldığına karar verdiniz .

• ^{Eğer durum gerçekten böyle olsaydı, Agile popülaritesinin şimdi gördüğümüze yakın olmayacağını düşünüyorum. Geliştirme ekibi yinelemelerinin KG test döngüleri ile zorunlu senkronizasyonunu "yaşayabilecek" birçok projeyi hayal edemiyorum.}

Aşağıda çeviklik hakkında biraz daha var, ama önce sıralayalım work for release N...

Bakın, geliştirme ekibinin işi bu şekilde tanımlaması için zorlayıcı bir neden yoktur. Tam tersine, açıklamanızdan, monolitik "iş birimi" yerine, hissedilmesi kolay kilometre taşları olan birkaç ünite olduğu açıktır ...

• ^{Örneğin, ilk "birim", aday yapımı test kullanıcılarına iletildiğinde ayrı kilometre taşı ile gösterilir ve diğer kilometre taşları, KG vb. Tarafından gerçekleştirilen test döngülerindeki değişikliklere karşılık gelir.}

Ayrıca tanımlama şeklinizin work for release NKG iş akışı tarafından da zorlanmadığını unutmayın. Açıklamak ne şeyler kendi (ve oldukça makul) zamanlama gibi görünüyor.

Yukarıda verildiği gibi, davanızdaki iş birimlerini tanımlamanın daha gerçekçi bir yolu aşağıdaki gibi olabilir:

1. Yapı KG'ye geçinceye kadar geliştirme faaliyetleri
   Release Candidate N
2. İlk KG test döngüsü ile ilgili geliştirme faaliyetleri
   Release Candidate N patch 1
3. İkinci KG test döngüsü ile ilgili geliştirme faaliyetleri
   Release Candidate N patch 2
4. vs, son yapıya kadar

Agile ya da her ne yaparsanız yapın, çalışma üniteleriniz yukarıdadır.

Bunlar doğal ve olan kullanışlı tanımlamak takip edip izlemek için. Bu aynı zamanda KG programı ile iyi uyum sağlar ve odf dev ve QA çabaları için uygun bir koordinasyon sağlar.

Ancak, anladığım kadarıyla, bu Scrum veya XP gibi yinelemeye dayalı yaklaşımlarla uyumlu değildir. Yinelemeye dahil edilecek tüm test çabalarıyla sonunda bir yinelemenin serbest bırakılabilir olmasını talep ediyorlar.

Agile ile uyumluluk anlayışının temelinde temelde yanlış görünüyor ve işte bu yüzden ...

Yaptığınız varsayımın Agile ile bir ilgisi yoktur, eğer felsefesini adından da anlaşılacağı gibi yüz değerine çıkarırsak , bu çevikliği destekleyen ve uygulayan bir yaklaşımdır .

Bu açıdan bakıldığında, belirli "sabit" iş akışına sadık kalmak ve bunun uygun olup olmadığını görmezden gelmek, Agile'ın ruhuyla çelişir. “Prosedürü” takip etmek , Yarı-Artik Çevik Manifesto'da bu kadar etkili bir şekilde aşağılanmış uygulamalara yol açar ... ... bu bireylerin ('kaynaklar' terimini tercih ediyoruz) nasıl etkileşime girdiğini kontrol etmek için zorunlu süreçlerimiz ve araçlarımız var .

Bununla ilgili daha fazla bilgiyi aşağıda verilen başka bir soruya yanıt olarak bulabilirsiniz . "Sevk edilebilir sürüm" konusundaki nota bir göz atın, o zamanlar OP gibi benzer bir şekilde karıştırıldı:

biri olmalıdır çevik çevik ilkelerin çok uygulama hakkında. Yani, proje gereksinimleri çevik değilse (kararlı veya yavaş değişiyorsa), neden rahatsız oluyorsunuz? Bir keresinde üst yönetimi zorlayan Scrum'ı mükemmel bir şekilde başarılı olan projelerde gözlemledim. Ne büyük bir israftı. Sadece teslimatlarında bir gelişme olmadı, daha da kötüsü, geliştiriciler ve testçiler mutsuz oldu.

Benim için, Agile'nin en önemli kısımlarından biri, her sprint sonunda bir sevk edilebilir sürümüne sahip olmak. Bu birkaç şeyi ima eder. İlk olarak, yapıyı bir müşteriye bırakabileceğinizi düşünüyorsanız, hiçbir gösterişli hata sağlamak için bir test seviyesi yapılmalıdır ...

Sevk edilebilir bir sürüm görüyorum. Hm. Hmmm. Agile kokteylinizebir ya da iki yalın atışekleyin. Yani, bu bir müşteri / pazar ihtiyacı değilse, bu sadece (test) kaynak israfı anlamına gelir.

Sprint-end- release'i ekibi tatmin eden bir kontrol noktası olarak tedavi etmede suçlu hiçbir şey görmüyorum .

• ^{dev: evet, test kullanıcılarına geçebilecek kadar iyi görünüyor; QA: evet, daha fazla gönderilebilir test gerekiyorsa, durum için yeterince iyi görünüyor - böyle şeyler. Takım (dev + QA) memnun, işte bu.}