Scrum'da, sprint sonunda çekişme / iş yükü nasıl ele alınır?

Ekibim Scrum'ı birkaç sprint önce kullanmaya başladı. Projemiz, fiziksel cihazlarla (robotlar ve sensörler düşünün) arabirim oluşturmayı içerir ve tipik Ürün birikimimiz genellikle tüm sisteme kontrol cihazı eklemeyi temsil eder.

Buradaki örneğe yakın görevi böldük . Her cihaz entegrasyon özelliği, kod, testler, entegrasyon testleri, emsal gözden geçirmesi vb. Sprintlerimiz genellikle 2 hafta sürer ve ekibin 4-6 üyesi vardır.

Sprintlerin sonunda 2 problemle karşılaşıyoruz:

• Birincisi sprint sonunda herkesi meşgul etmek .
• İkincisi (ilgili) sistemdeki çekişmedir. Hemen hemen sprint'in son günlerinde bütünleşiyoruz. Sadece bir entegrasyon sistemimiz var, bu yüzden insanların sisteme erişemedikleri için görevlerinde çalışmaya devam etmeleri genellikle engelleniyor. Sprint'in sonu olduğu için sprint biriktirme listesinde yapılacak fazla iş kalmamıştır. Bu insanlar ne üzerinde çalışmalı? Geçerli işler yapılmadığından, ürün biriktirme listesinin en üstündeki öğeleri alma, ürün sahibinden iyi bir şekilde alınmıyor. Teknik borç üzerinde çalışmak projeye bir bütün olarak yardımcı olacaktır, ancak sprint'in tamamlanmasına yardımcı olmayacaktır.

Bu sorunlardan kaçınmak için her iki sprint'i yapılandırmaya yönelik en iyi uygulamalar var mı? Ürün sahipleri ile pazarlık yapmak için ipuçları?

bazı açılardan bir sprint sonunda yavaş olmanız iyi bir şey, yani iyi tahmin edeceğiniz ve meşgul olduğunuz kadar fazla taahhütte bulunmadığınız anlamına gelir, üzerinde çalıştığım scrum takımlarına her zaman bir sonraki işler için araştırma görevleri ekledik sürat.

Bu, yaklaşmakta olan şeyler için kavramların kanıtı olabilir veya mevcut kodu nerede yeniden faktör olarak inceleyeceğinizi, kodunuzda daha iyi test kapsamı elde etmek için çalışabilir vb.

Entegrasyon sisteminizi düzeltmelisiniz, böylece takımınız sprint sonunda büyük bir patlama beklemek yerine her görev tamamlanır tamamlanmaz çalışmalarını entegre edebilir.

Birkaç gün içinde bitecek kadar kısa kullanıcı hikayeleriyle çalışmanızı tavsiye ederim. Burada bitirilmiş kod tam, test ve entegre anlamına gelir .

Bireysel üyeleri değil, kendi başına teslim etmenin tüm ekibin sorumluluğunun olduğunu hatırlamak, dört ila altı üyenin hepsinin BİRLİKTE her görevde çalışmasını sağlamaktır - her birini süreç boyunca itin ve bir sonrakine geçin. Bu başlangıçta verimsiz gelebilir, ancak gördüğünüz darboğazlar o kadar kötü ise, geçerli bir seçenek olabilir.

Ayrıca, kısıtlamalar teorisine (Goldratt'ın Hedefi ) bakmak ve bu entegrasyon darboğazlarının neden ve nerede olduğunu en iyi nasıl analiz edebileceğinizi görmek isteyebilirsiniz.

Bunu Kanban yaklaşımını benimseyerek ele aldık.

İzleme yazılımımızda (Jira) minimum ve maksimum kuyruklarımız var.

'Gerektiği gibi' tımar ediyoruz. Haftada bir kez olabilir, 3 kez olabilir, sınırlara ve yapılan işe bağlıdır.

Bu, ürün sahibini kuyruğunuzu yapacak çok şeyle odaklamaya odaklamanıza yardımcı olur ve bireysel biletlerin mikro yönetimini azaltabilir. Her zamanki gibi değişikliğin zaman alacağını unutmayın.

Hala iki haftada bir demo yapıyoruz ve haftalık olarak yayınlıyoruz.

Vay canına, eğer robot demeseydin, şu anda ekibimde olduğunu sanırım. Biz kesinaynı sorun kümesi. Manifestoya farklı derecelerde aslına uygunluk ve değişen başarı derecelerine sahip sayısız çevik proje üzerinde çalıştığım analiz, sorunumuz sprintlerin çok kısa olması. Birkaç soruna neden olan iki haftalık sprintler yapıyoruz. Birincisi, planlamada aşırı dikkatli olmamız ve sık sık sonunda ölü günlerle sonuçlanmamızdır. İkincisi, iki haftada bir 1-2 gün süren inceleme, retrospektif ve planlamanın büyük kulak misafiri. Bir diğeri, dediğin gibi, son dakikada entegre olması ve incelemeden önce sık sık başarısız saatler. İlk ve en başarılı çevik projemin dört haftalık sprintleri vardı, topladığım endüstri standartlarına göre oldukça büyük, ama bizim için harika çalıştı.

DÜZENLEME: Bir nimet olan ilk projeden bir şey daha hatırladım. Her zaman tamamen öncelikli bir ürün birikimimiz vardı ve sprint görevleri tamamlandıysa ve başka sprint görevleri mevcut değilse geliştiricilere görevleri alma özgürlüğü verdik.

İkinci sorun muhtemelen sorun olmayan # 1'i düzeltmeye çalışmanın bir sonucudur. Meşgul olmayan insanlara akranlarına yardım etmelisiniz; Sprint olmayan görevler üzerinde çalışmak yerine, sınırlı entegrasyon üzerinde çekişmeye neden olur.

Ayrıca, sprint'in sonuna değil, sürekli olarak entegre olmalısınız.

Daha yeni başlıyorsunuz. Takımlara, geriye dönük süreçleriyle bu sorunu kendi başlarına çözme şansı verin.

İkinci olarak, ürün sahibiniz kendilerini en iyi nasıl organize edeceklerini ve optimize edeceklerini bilmek için ekibe güvenmelidir. Buna karşılık ekip, müşterinin neye en iyi ihtiyacı olduğunu öğrenmek için PO'ya güvenir.

Bunlar, yeni çevik ekiplerle çok sık karşılaşılan zorluklardır. Bir ekibin kendi silolarını parçalayıp büyümeye başladığında görmek harika.