Sprintler arasında ne olur?

Scrum modelini gevşek bir şekilde takip eden bir proje üzerinde çalışıyorum. İki haftalık sprintler yapıyoruz. Açıkça görmediğim (ve danışacak bir kitabım yok) bir şey tam olarak sprintler arasında olması gereken şeydir: ürünün inşa edildiği ve teslim edildiği bir "sarma" işlemi olmalı, ancak:

• bu genellikle ne kadar sürer?
• tüm ekip dahil olmalı mı?
• geliştiricilerin bir sonraki sprint öğeleri üzerinde çalışmaya başlamadan önce kesinlikle bitmesi gerekiyor mu?
• inceleme ve test yapılırken bu olur mu?

Yaklaşık 1 FTE ekleyen üç geliştirici vardır. Yani sprintler gerçekten çok kısa.

Scrum modelini gevşek bir şekilde takip eden bir proje üzerinde çalışıyorum.

Açıklamak gerekirse: Yöneticileriniz muhtemelen Scrum'dan bahsetti, ancak yaptığınız şey Scrum değil.

Bu genellikle ne kadar sürer?

Sprint inceleme toplantısı + Sprint geriye dönük toplantısı geçerli sprint'i sonlandırır. Kısa sprintlerde 30 dakika - 1 saat birlikte bir şey almalıdırlar. Bir sonraki iş günü Sprint planlama toplantısı 1 ve 2'yi gerçekleştirerek yeni bir sprint başlar. Takım büyüklüğü ve sprint uzunluğuna bağlı olarak bu toplantının süresi 2 - 4 saat sürebilir.

Tüm ekip dahil olmalı mı?

Tüm ekip önceki cevapta belirtilen toplantılara katılmalıdır.

Geliştiricilerin bir sonraki sprint öğeleri üzerinde çalışmaya başlamadan önce kesinlikle bitmesi gerekiyor mu?

Evet, çünkü gözden geçirme toplantısı tamamlanana kadar müşterinin önceki sprint sonucunu kabul edip etmediğini bilmiyorsunuz ve toplantı planlamada hangi kullanıcı hikayelerinin yapılacağını bilmiyorsunuz.

Kod incelemesi ve testi gerçekleştiğinde bu olur mu?

Hayır. Kod incelemesi ve testi sprint'in bir parçasıdır. Geliştiriciler, çalışma kodunu karşılayan gereksinimleri sağlamak için gereken her şeyi yapmalıdır. Bu, kod incelemelerini içerebilir ve her zaman kodun çalıştığını ve yapması gerekenleri yaptığını doğrulayan bir tür otomatik testler içermelidir, aksi takdirde kullanıcı hikayesi tamamlanmış olarak kabul edilemez.

Ana zihinsel değişim KG ile. Birçok geliştirici, QA'nın kodun çalıştığını ve yapması gerekeni doğruladığını düşünmek için orada olduğunu düşünüyor. Kesinlikle hayır. Bu geliştirici işi.

KG ürün geliştirmeye katılmalıdır. Sprintteki ana sorumlulukları, ürün sahibiyle iletişim ve kullanıcı hikayesinin gerçekten yapıldığını ve uygulamanın tüm yeni gereksinimleri geçtiğini doğrulayacak kabul kriterleri (tamamının tanımı) için otomatik kabul testlerinin oluşturulması olmalıdır. Küçük ekiplerde bu, geliştiricilerin de sorumluluğu olabilir.

KG, ürünü tutarlı tutmak ve eksik özellikleri keşfetmek, kullanıcı arayüzünde kullanıcı deneyimini doğrulamak için bazı manuel testler de yapmalıdır.

Benim tecrübelerime göre, çevikliğe hareket eden şirketlerin çoğu başarısız oluyor.

Deneyimlerime göre, hafta sonu dışında sprintler arasında zaman yoktur. Sprint ortasına doğru, ürün sahibi ile birlikte çalıştığım ekipler, gereksinimlere göre bazı hikaye bakımları veya ön boyutlandırmalar yapmak için çalışıyorlar. İş birikimini tam tutmak ürün sahibinin sorumluluğundadır - bu hikayeler ekibin üzerinde çalışacağı konulardır ve ürün sahibinin önceliklerle ilgili bazı girdileri vardır. Geçerli sürat bittiğinde, bir sonraki sürat için öyküler ve görevler hazırlamak için yaptığımız işi kullanarak bir sonraki sürat başlayacaktır.

Bazı ek yükler (çok sayıda toplantı, soru-cevap ve gereksinim değerlendirmesi) var, ancak genel olarak işe yarıyor - çok az kesinti süresi ile sürekli ilerleme kaydediyoruz. Sprintler genellikle iki veya üç hafta sürmüştür. KG genellikle hikayeler tamamlandıktan sonra gerçekleşir. Ancak KG ekibinin yapabilecekleri başka görevleri olabilir. Hikaye bakımıyla ilgili olarak, görevler ekibin üst düzey üyelerine veya tüm ekibe düşebilir. Takımın büyüklüğüne ve üzerinde anlaşmaya varılan sürece bağlı olarak değişebilir. Kod incelemeleri genellikle KG oluştuğunda veya zaman sıkıştırılırsa sprint sonunda gerçekleşir. Ve hikayeleri bitirmek için yeterli zaman yoksa, pratikte bu hikayeler bir sonraki sprint'e itilir. Uygun boyutlandırma ve tahmin burada çok önemlidir.

... ve tahmin ne zaman? planlama?

Hikayeler, sprintler arasında hiç zaman olmaması gerçekten kolay olmalıdır.

Ne tür bir testten bahsettiğinizi bilmiyorum, ancak geliştiriciler birim ve entegrasyon testlerini yapacaklar, başka bir şey değil.

Sprintler arasında bazen 2 veya 3 gün olan bir projede çalışıyordum ve doğru geliyor. Şimdi zamanın olmadığı ve tamamen bulanık olduğu bir proje üzerinde çalışıyorum. Sprint'in son kez üretim konuşlandırmamız var ve bu benim son sprint günümün biraz zamanını alıyor.