Bir haftalık sprint için sprint planlamasında 5 saatten fazla sürdüm. Çok fazla gibi görünüyor.

Takım üyelerinin çoğu kıdemli olmadığından, sprint planlamada işleri ayrıntılı olarak tartışıyoruz. Bunu yapmazsak, uygulama sırasında hatalara ve sprint sırasında yeniden tasarlamaya yol açar.

Bununla nasıl başa çıkabiliriz?

Bir haftada sadece 2 saat uzunluğuna sığdırmak için planlama sırasında ne kadar detay tartışmalıyım?

Haklısın - 1 haftalık Sprint Planlama'da 5 saat Sprint uzun bir süre gibi görünüyor. Scrum Guide zaman kutuları Sprint Planlama 1 ay boyunca 8 saate kadar Sprintler ve "daha kısa Sprintler için, olay genellikle daha kısa" diyor. Oranı düşünürseniz, iyi bir hedef 1 haftalık bir Sprint için 2 saatlik Sprint Planlama olabilir, ancak sabit bir zaman kutusu yoktur.

Peki, uzun bir Sprint Planlama'ya nasıl hitap edebilirsiniz?

Bir Scrum Master olarak şu adımları atacağım:

İlk olarak, Ürün İş Listesi'nin düzgün bir şekilde sipariş edildiğinden emin olmak için Ürün Sahibi ile birlikte çalışacağım. Scrum Ekibinin enerjilerini doğru işi tanımlama, arıtma ve hazırlama üzerine odaklayabilmesi için en önemli çalışmanın ve bağımlılıklarının Ürün İş Listesinin en üstünde olmasını sağlamak için etkili İş Listesi İyileştirme ve Sprint Planlama gereklidir.

İkincisi, ekibin İş Listesi Arıtımı için yeterli zaman harcadığından emin olurum. Scrum Rehberi, arıtma faaliyetlerinin genellikle bir Geliştirme Ekibi kapasitesinin% 10'undan fazlasını almadığını gösterir. Örnek olarak, standart 40 saatlik bir haftada çalışan 4 kişilik bir Geliştirme Ekibi, yaklaşık 16 saatlik İş Listesi İyileştirmesi planlamalıdır. Bu bireysel olarak, küçük gruplar halinde veya bir ekip olarak yapılabilir. Ekip için planlanmış bir İş Listesi İyileştirme oturumu yapmanın ve daha sonra herhangi bir araştırma, soruşturma ya da planlama yapmaya başlamanın en iyi sonucu verdiğini gördüm.

Üçüncüsü, ekibin Sprint Planlama'da her ayrıntıyı elde etmek zorunda olmadıklarını fark ettiğinden emin olun. Sprint Planlama'nın amacı Sprint Hedeflerini tamamlamak için bir plan hazırlamaktır. Sprint Planlama oturumunda büyük tasarım yapmaya çalışmayın. Farklı çalışmaların, bağımlılıklara ve hedeflere nasıl uyduğunu anlayın ve işi sağlamak için gereken tasarım, uygulama ve testleri yapmak için doğru kişilerle Sprint Planlama oturumlarının dışındaki zamanı kullanın.

Bunlardan daha fazla adım düşebilir, ancak bu iyi bir başlangıç ​​noktası olacaktır.

Seni duyuyorum. Harcayacak çok uzun! Umarım ekibiniz bunu retrospektiflerinizde tartışır. Karışık sonuçlarla birkaç deneme denedik:

1. Herkes tek bir bilet üzerinde üst düzey bir tasarım yapar ve revizyon için masanın etrafından sola veya sağa geçirir, ardından her bilet için planın grup incelemesi yapılır. Herkes bunu sevmedi, ama gençlerimizi denemeye zorladı. Takımlardaki bazı kişiler, diğerlerinin düşünceleri yapmasına izin vermekten oldukça mutlu ve sadece talimatları izliyorlar. Artı tarafta, deneyimiz herkesi bilgi boşluklarıyla yüzleşmeye zorladı, gençler için büyüme zorluğu sağladı. Olumsuz tarafta, herkes olay yerinde olmayı sevmez ve toplantıdaki zamanı mutlaka azaltmaz. Sonraki!

2. Eşleştirilmiş tasarımlar denendi. İki veya üç kişilik gruplar bir bileti görevlere ayıracaktı. Tüm ekip ortaya çıkan planları gözden geçirir. Çok daha hızlı gitti, ancak bazı mini baklalar bir kişinin aynı sorunu yaşarken diğeri tasarım üzerinde çalıştı.

3. Görev dökümünü atla. Hikaye puanlarımızın ortalamasına karar verdik, bu yüzden tüm ekibi her şeye dahil etmeye çalışırken zaman harcıyorduk. Sonuç olarak çok daha kısa planlama toplantıları yaptık, ancak tasarım işi bir bilet başladığında çiftlerimizin kendileri için yapması gereken bir şeydi. Gençler bir bilet çalışıyorsa, bu adımı atlatmak için yardıma ihtiyaçları olacağını düşünün. Bunu denerseniz, rahat edene kadar sprint'te daha az hikaye kabul etti. Ayrıca, takım arkadaşlarınızın bir şey bilmediklerinde yardım istemelerinin "güvenli" olduğundan emin olun.

Sonunda, takımın olgunluğuna gelir. İnsanlar birbirlerinin yeteneklerini ve tercihlerini anlamalı ve takım arkadaşlarının ihtiyaç duyduklarında girdi isteyeceklerine güvenmelidirler. Eğer yoksa, önce bunları düzeltin. Daha sonra verimsiz toplantılar sorununu çözmek kolaylaşır.

@ Thomas-Owens'dan aldığınız yanıtı seviyorum ama bir madde daha ekleyeceğim. Çevik uygulamanızın bir parçası olarak çift programlama yapmayı düşündünüz mü?

Çift programlama, (1) bazı genç programcılarınıza nasıl daha iyi kod yazacağını öğretmek ve (2) çift programlamayı öğretmek için her zaman sprint planlamasında her bir tasarım özelliğine sahip olmanıza gerek yoktur. Çift birlikte çalışırken, bu tasarım kararlarının bazıları, eklenen çift programlama avantajları ile "kendiliğinden" verilebilir.

Küçük programcılarınızın daha hızlı öğrenmesine yardımcı olabilirseniz ve Sprint Planlama'da ele almadığınız tasarım öğelerinin iki kişi tarafından kararlaştırılacağını biliyorsanız, harcadığınız zamanı azaltamazsınız. gelecekteki Sprint Planlama

Scrum meraklısı değilim ve sadece yaklaşık bir yıllık pratik deneyimim var. Bu yüzden aşağıdakiler bir tuz tanesi ile okunmalıdır.

Yazdıklarınızda birkaç kırmızı bayrak görüyorum:

5 saatlik sprint planlama

Bu bir haftalık bir sprint için çok uzun.

Sprint planlamanın amacı AFAIR

• ekibin mevcut önceliklerin ne olduğunu bilmesini sağlamak ve
• gelecek sürat için bir savaş planı geliştirmek.

Etkin bir şekilde bunu yapmak için, her bir yan anlamak zorundadır Product Backlog items.

İş Product Backlog itemsbirikimini anlamak için iyi durumda olmalıdır.

Somut planlama aşamasında, Product Backlog itemsdönüşür Sprint Backlog items.

Olası nedenlerden biri, bu öğelerin yeterince açıklığa kavuşturulmamış / rafine edilmemiş olmasıdır.

Başka bir olası neden, öğelerin çok karmaşık olması ve çok fazla yoruma yer bırakmasıdır.

Sprint planlamada çok ayrıntılı olarak tartışın

Yukarıda belirtildiği gibi, tartışma aşaması, maddeler daha somut olduğunda daha kısa olacaktır.

Öte yandan: Sprint planlama her katılımcıdan profesyonel davranış bekler. Bu, bisiklete binme tartışmalarından kaçınmayı içerir .

Belki işler açıktır, ancak biri bisiklet sürme tartışmasına başlar .

Daha fazla: Uygulama ayrıntıları hakkında tartışmalardan kaçının . Her fikir zaman içinde kodla bitse de, basit bir dizinin hile yapıp yapmayacağı ya da bağlantılı bir liste kullanarak daha iyi olacağı, sprint planlamanın tartışıldığı nokta değildir.

Ekip üyelerinin çoğu kıdemli olmadığından

Scrum'da kıdemli ve genç arasında bir ayrım yoktur . Her ikisi de sadece geliştiriciler. Ve bu, tartışmanızı maaş çeki yerine daha iyi argümanlar ile desteklenen uygulanabilir bir çözüme odaklanmış tutmanıza yardımcı olan iyi bir başlangıç ​​noktasıdır.

Sprint sırasında uygulama hataları ve yeniden tasarım

İhtiyaçların toplanmasında temel bir sorun var gibi görünüyor, bunu çok belirsiz bir ürün birikimi takip ediyor.

Yukarıda söylediğim gibi: Product Backlogİyi durumda olduğu sürece , noktayı kaçırmak zor olmalı.

Gibi bir durum düşünemiyorum:

»Kullanıcı olarak bir avuç müşteri görmek istiyorum!«

»Ah, 2 milyon müşterimizin her birini kastetmedin mi?«

OTOH: Bu bağlamda yeniden tasarım ne anlama geliyor? Bir geliştirici yavaş performans gösteren bir algoritma seçtiyse, bir sonraki hedef açıktır: daha iyi performans gösteren bir algoritma seçin. Ama bu bir "yeniden tasarım" değil, bu bir optimizasyon.

Ana sorularınıza:

Bununla nasıl başa çıkılır?

Bahsetmek önemsiz, ama yine de yapıyorum: Unutmayın, insanlarla uğraştığınızı unutmayın .

Ortak kavramları ( Rashomon'da olduğu gibi ) paylaşabilen bir grup farklı zihne sahip olmak çok zordur . Bununla etkili bir şekilde başa çıkmak için, iletişiminizde mümkün olduğunca fazla yedeklilik kullanın : örneğin, herkes ne yapacağını "bilmeli" olsa bile, öğenin bağlamını kapsamlı bir şekilde açıklayın. Belirli bir öğenin konusunu herkesin alıp almadığını, sorular sorun.

Planlama pokeri iyi bir gösterge oynuyorsanız , anlayışın yeterince iyi olup olmadığı, görevlerin düşük olduğu anlamına gelir. Düşük, düşük karmaşıklık, anlaşılması kolay ve kaçırılması zor anlamına gelir.

Yinelemenin bir yan etkisi, belirli görevlerin sayılarının artmasıdır (çünkü takımın yeteneklerini ve gizli karmaşıklıklarını anladığı için). Daha sonra öğeyi daha az karmaşıklığa sahip daha az karmaşık öğelere bölme şansı vardır.

Haftada 2 saat sürat koşması için planlama sırasında ne kadar detay tartışmalıyım?

Salomonik cevap: Mümkün olduğunca az ve gerektiği kadar, ama daha fazla değil.

tl; Dr.

• Yanlış anlamalardan kaçınmak için kolay bir dil seçin (yardımcı oluyorsa basit İngilizce kullanın veya ELI5)

• Gereksinim toplamayı iyileştirin

• İş Listesini Geliştirin

• Ekip üyelerinin bireysel yeteneklerine ve ekip olarak yeteneklerine olan güvenlerini artırın

• Bisiklet sürmekten kaçının

• Kişisel disiplini geliştirin

• Tartışmak için her öğe için sabit zaman kutuları kullanın

• scrum masterEtkili ılımlılık konumunu güçlendirmek .

2 haftalık sprintlerde toplam üç saat bakım yaparak planlama toplantı süresini çok azaltmayı başardık. Tımarlamayı dört seansa ayırıyoruz. Pazartesi günü 30 dakika, her hafta Çarşamba günü 1 saat bakım yapıyoruz. Sprintlerimiz Pazartesi günü başlar ve Cuma günü biter. Sonuç olarak, planlamaya girdi olarak katkıda bulunan bakım toplantılarından, onu kısaltan iyi bilgilere sahibiz. En iyi kaydımız, sprintlerimizden birinde 30 dakikalık bir planlama toplantısıydı. Çoğu zaman bir saatten bir saate ve 30 dakikadan fazla sürmez. Yine de zaman kutulu, ama planlama çok erken yapıldı.