Çevik ekipler günlük olarak yeni özellikler sunmalı mı?

Şirketim şelale tarzı gelişiminden Çevik / Scrum'a bir geçişin ortasında. Diğer şeylerin yanı sıra, her günün sonunda yeni çalışma, test edilebilir (QA) özelliklerine sahip olmamızın beklentimiz olduğu söylendi .

Devlerimizin çoğu toplantılara ve diğer girişimci ek yüklere günde 2 saat kaybediyor. Bu, herhangi bir 6 saatlik (en iyi ihtimalle) dönemde, Kalite Güvencesi için tam bir özellik oluşturmak için yeterli kod tasarlamamız, yazmamız, birim test etmemiz, kurmamız ve dağıtmamız gerektiğidir (sürüm notlarıyla birlikte). Derleme / konuşlandırma / sürüm notlarının uygun bir CI kurulumuyla otomatikleştirilebileceğini biliyorum ancak henüz orada değiliz.

Sunucu tarafı kodumuzu yazan büyük bir açık deniz koşulunda da 12 saatlik zaman farkı bunu daha da zorlaştırıyor.

Özellikleri mümkün olduğu kadar çabuk bitirmek için hikayeleri dar, derin dikey dilimler halinde vermeye çalışıyoruz, ancak çoğu gün kendimi çılgınca hissediyor ve çoğu zaman QA'nın üretkenliğini sağlamak için aptal, kırılgan kısayollar alan insanları yakalarım. Kaçınılmaz kusurların yuvarlanmaya başladığı ve aynı 6 saatlik pencereye sığması gerektiğinde, bu sorun bir sprint birkaç gündür devam ettikten sonra daha da artmaktadır.

Bu Çevik ekipler için normal bir tempo mu? Bir CI kurulumunu gerçekleştirebilsek bile, bu temposu nasıl sürdürebileceğimizi ve hala kaliteli yazılımlar oluşturabileceğimizi göremiyorum.

Düzenleme: Burada birkaç iyi cevap var. Agile takımlarının günlük olarak yeni özellikler sunması gerektiğinin asıl sorduğumun farkında olduğumu fark ettim . Başlığı buna göre güncellendi.

Bugünlerde Çevik adına işlenen suçlar beni üzüyor. Birçok insan bu geçişi yapmakta zorlanıyor.

Çevik Manifesto: "İnsanlara ve etkileşimlere süreç ve araçlar üzerinden değer veriyoruz". İnsanlar açıkça acı çektiğinde, süreç yanlış. Nasıl yapılacağını söylemek istemiyorum ama nasıl yaptığımı paylaşacak.

Ekiplerimde önemli olan kısım, ekibin geri kalanını boşa harcayacak şekilde bozulan ortak bir repo koduna bağlı kalmaktan kaçınmak. Sadece bu anlamda, 'her gün çalışma kodu sunmaya' çalışıyorum. KG'yi bozma. Diğer geliştiricileri engellemeyin. İdeal olarak hiç bir hatayı kontrol etmem. (ha ha).

Sonuç olarak, her gün bir şeyler yapmak zorunda değilsiniz. Bunun anlamı, yalnızca iyi şeyler yapmanız gerektiğidir, böylece her gün, birinin yaptığı tüm iyi şeylerin bir yapısını elde edebilirsiniz. Bu şekilde takım tüm silindirlere ateş eder.

Takımlarımda KG sabittir. Ticari ürünler yapıyorum, bu yüzden ürün kullanılmayana kadar proje asla bitmedi. QA Mühendisleri test etmek için mevcut olan özellikleri test eder. QA Mühendisleri her zaman bir birikime sahiptir. İdeal olarak isteyeceğimiz her şeyi test etmek ya da otomatikleştirmek için hiçbir zaman yeterli QA zamanı yoktur.

Geliştiricilerin bir özellik veya düzeltmede yapılan değişikliklerin birleştirilmesinden önce birkaç güne ihtiyaçları varsa, zamanımızı riske atmadan hemen önce kodu almalarına yardımcı olmaları önerilir. Geliştiriciler ekibi veya KG'yi etkilemeden özel depolarına veya şubelerine kod işleyebilir. Geliştiriciler, geliştiricinin deposundan veya özel şubesinden oluşturulan kod üzerinde birim testleri veya regresyon otomasyonu yapabilir. Özellikle riskli durumlarda, bir QA Mühendisi, birleşmeden önce test etmek, ekibi gecikmeden korumak için geliştirici ile birlikte çalışacaktır.

Bu anlamda yöneticilerinizin ne istediğini pratik yapıyorum. Son 12 yılda neredeyse her gün, geliştirme ekiplerimin paylaşılan depoda çalışan kodları oldu. Neredeyse her zaman gemiye hazırız. Bazen bunu başaramıyoruz, ama bunun için fazla endişelenmiyoruz. Bazen, büyük takım değişikliklerini veya zor birleşmeleri sağlamak için kasıtlıdır.

Çevik Manifesto, bana göre, 1990'larda ortaya çıkan gelişme sürecindeki yeni düşüncenin en iyisini özetliyor. Neredeyse bu ilkelere inanan biriyim, ancak süreç detayları değişebilir. Gördüğüm kadarıyla Agile'nin amacı, işleminizi bir köle olarak değil, ürününüzün ve müşterilerinizin ihtiyaçlarına göre uyarlamaktır.

Dün çalışan bir yazılımınız olsaydı, neden bugün çalışmıyordu? Bugün herhangi bir görevi tamamlamadıysanız, bugünün yapımı dün ile aynı olacaktır. Günlük yapılar ve gelişim hızı ayrı şeylerdir. Sırf günlük inşaata sahip olduğun için, her binada yeni özelliklerin olduğu anlamına gelmez.

Sonunda bazı özellikler ana dalda bitip kontrol edildiğinde, yazılımı derleyen ve testler yapan otomatik bir işlem yapmanız gerekir. Test oluşturma veya koşma testleriyle ilgili bir sorun varsa, takıma bildirilir ve tekrar çalışması için çabalarına odaklanırlar. CI bu şekilde çalışır ve çalışma yazılımını her zaman serbest bırakmanıza nasıl yardımcı olur.

Kısa Cevap: Hayır . Sadece günlük olarak yapılamaz.

Ancak, çevik ekibin her sprintte çalışan yazılım parçaları veya kullanıcı hikayeleri sunması gerekiyordu . Genellikle, statü toplantısı, ilerlemeyi ve engelleri görmek için günlük olarak yapılır.

Kalite yazılımı ile ilgili olarak , sürekli entegrasyon (CI) işlemleri, kalite kontrolünün küçük çabalara (girişler) uygulanmasını ve sık sık yapılandırıldığı gibi yapılmasını sağlayacaktır. Ayrıca quality of software, tüm gelişmeleri tamamladıktan sonra kalite kontrol uygulama geleneksel uygulamasının yerini alarak, bunu geliştirmek için harcanan zamanı azaltmayı ve azaltmayı hedeflemektedir.

Hayır, her gün yeni özellikler sağlama beklentisi olmamalıdır. Bir geliştiricinin özelliği ~ 6 saatlik geliştirme süresi içerisinde bitirebilmesi için tüm özellikler bu kadar küçük bir boyuta bölünemez.

Eğer scrum yapıyorsanız, en az 2 hafta süren sprintten yapmalısınız, özellikleri 0 ila 8 gün arasında değişecek kadar büyüktür. Ürün sahibine verilen söz, sprint sonunda üretime sokulabilecek yeni, test edilmiş ve doğrulanmış doğru çalışma kodunu teslim etmektir. (NOT: Aslında onu üretime sokmak zorunda değilsiniz ancak amaç, isterseniz olabilir)

İyi bir metodoloji günlük olarak en az bir günlük çalışan yazılım geliştirmeyi otomatikleştirdiğiniz bir CI (Sürekli Entegrasyon) sunucusu kurmanızı önerdi. Özelliği tamamladığınız anda kodunuzu kontrol etmeniz, böylece bir sonraki derleme döngüsünde ve daha sonra test için KG'nin ellerinde olabilir.

Unutmayın ki, sprint sonunda özelliklerin yapılmış ve test edilmiş olması! İnşa etmek için QA'yı sprintin son gününe kadar bekletmek zorunda kalmaz ve sonra tüm özellikleri test etmelerini istemezsiniz. Hepsini test etmek için zamanları olmayacak ve hiç bir hatayı düzeltmek için zamanınız olmayacak ...

Bir CI sunucusu kuramazsanız, uygulama, bir geliştirici bitmiş kodunu her kontrol ettiğinde ve bir özellik ile yapıldığını ve KG'yi teslim etmeye hazır olduğunu iddia ettiğinde, QA için manuel olarak yeni bir yapı oluşturmanız gerekir.

Bu aslında projenin büyüklüğüne bağlıdır; Proje büyükse, bunu başarmanın uygun bir yolu yoktur.

Sürekli entegrasyon araçlarından çıkan günlük (hatta daha sık) inşaatlar, çalışan yazılım anlamına gelmez; zar zor derlenebilir kod anlamına gelir.

Sürekli entegrasyon sayesinde çalışan yazılım olan günlük inşaatlar yapan birçok proje var. En azından teoride.

Bu mutlaka yeni özellikler içermediği anlamına gelir. Belki birkaç küçük hata düzeltildi, ya da hiçbir şey.

Teoride, QA'nıza günlük olarak daha fazla çalışma sağlayamazsanız, geliştirici sayısını artırmanız veya test edenlerin sayısını azaltmanız gerekir. Korkunç fikir!

Senin işin işleri halletmek.

KG'ye söyle, bittiğinde test edecek bir şey alacaklarını söyleyin. Onlara nedenini açıklaman gerek.

Sanırım "CI" fikri hakkında kafan karıştı. Bu mükemmel makaleyi Martin Fowler'ın CI'nin pratikte nasıl çalıştığı hakkında ziyaret etmek isteyebilirsiniz . Sorunuzu doğru yanıtlamanız gerekir.