Atlassian her yeni yıl yenilenen bir amaç duygusu getiriyor ve yazılım dünyasında daha iyi yazılımlar sunmayı vaat ediyor. Atlassian'da, uygulamaya yeniden odaklanmak, sürprizleri en aza indirmek ve genel olarak daha yüksek kaliteli kodu garanti etmek için sprint planlamasının agile seremonisine büyük ölçüde güvenilmektedir. En yararlı bulunan dört sprint planlaması ilkesini inceleyelim.
Yol haritası, iki önemli çevik kavramın bağlamını belirler: Çevik program planlaması için temel oluşturan ve uzun vadeli işlerin sağlanmasına yardımcı olan epic'ler ve versiyon'lar . Yol haritasının güncel olduğundan, tüm takım tarafından görülebildiğinden ve sprint planlama toplantınızdan önce epic'lerin ve versiyon'ların Jira'da doğru şekilde listelendiğinden emin olun.
Sprint planlaması iki temel görevi içerir: İş yığınını düzenlemek ve gelecek sprintte hangi işin tamamlanacağına karar vermek. Atlassian'da, iş yığını düzenlemesinin en iyi şekilde , gerçek sprint planlama toplantısından önce ürün sahibi ve scrum master'ı ile ayrı bir toplantıda yapıldığını gördük. Tüm geliştirme ekibi için bu ön toplantıyı isteğe bağlı hale getiriyoruz.
İş yığınını düzenleme nedir?
Backlog temizliği, backlog birikiminin sağlıklı olmasını sağlar. Sağlıklı bir biriktirme listesi:
En önemli çalışma en üstte listelenecek şekilde her bir çalışma öğesine öncelik verir
Geliştirme ekibinin uygulamaya başlayabileceği biçimlendirilmiş user story'leri içerir
Her iş öğesi için güncel bir tahmin içerir
Takım Aktivitesi : Bazı takımlar tahmin yapmakta zorlanır. Story point'ler işi tahmin etmek için sağlam bir çerçeve sağlar. Ekibi sessiz tahmin adı verilen bir faaliyete dahil edin . Alıştırmaya başlamak için hikaye puan değerlerini (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) bir beyaz tahta üzerindeki sütunlara yerleştirin. Ardından, takımdan story point'leri en doğru olduğunu düşündükleri sütuna yerleştirmelerini isteyin. Hikayelerin çoğu bir numaraya yönelecektir ve hikayenin puan değeri konusunda anlaşmazlık varsa, bu noktada neden diye bir tartışma açmanın zamanı gelmiş demektir.
Sprint planlama toplantısının odak noktası, sprint hedefini - takımın sprint sırasında tamamlayabileceğine inandığı iş miktarını - belirlemek ve kararlaştırmaktır. Ürün sahibi ve geliştirme ekibinin hepsinin katılımda olması gerekir. Atlassian'da, toplantıda ele almayı planladığınız sprintin her haftası için en az bir saat öneriyoruz. Örneğin, iki haftalık bir sprint'i kapsayacak şekilde iki saatlik bir sprint planlama toplantısı ile başlayın. İdeal olarak, sprint planlamayı haftanın başlarında planlayın. Daha sonra ekibin bağlamı ve akışı hafta sonu daha az kesintiye uğrar.
İPUCU Toplantının başlangıcında, scrum master'ı, ekibin geçmişine bakıldığında ilgili tüm eylem öğelerini sunar. Daha sonra, ürün sahibi, herkesin aynı sayfada olması ve daha geniş bağlamın zihninde taze olması için ürün veya pazar güncellemeleri verir.
Bilgilendirmelerden sonra, gerçek planlama görüşmesine başlamak ürün sahibinin sorumluluğundadır. Başlamak için, ürün sahibi, müşteri için değeri en üst düzeye çıkaran "sprint tahmini" adı verilen, sprint için önerilen bir dizi hikaye derlemek için takımın ortalama hızını (bir sprintte tipik olarak tamamlanan iş miktarı) kullanır. Ürün sahibi ayrıca şu üç faktörü de göz önünde bulundurmalıdır:
Resmi tatiller, kişisel tatiller ve ekip çapında etkinlikler
İş yığınındaki haberlerin önceliği (ideal olarak, en üst sıradaki öğeleri önerirler)
Bu çalışma gövdesi ürünü nihai hedefine nasıl yaklaştıracak
İPUCU Ürün sahipleri, hızı hesaplamak için sprint işaretleyicisini kullanabilir.
Takım yeniyse ve sabit bir hıza sahip değilse, ürün sahibi bir sprint tahmini önermemelidir. Bunun yerine, bu tüm ekip alıştırması olmalıdır çünkü her üyeden katılımın olması önemlidir. Ekip ilk başta tahminle ilgili en iyi muhakemesini kullanacak ve birkaç deneme yanılma sprinti üzerinde çalışacaktır. Takımın hızı - Jira'daki hız çizelgesiyle güzel bir şekilde görselleştirilmiş - sayısal olarak belirlendiğinde, sprint tahminine rehberlik etmek için bu ölçüyü kullanın.
Ürün sahibi sprint tahmini için fikirlerini sunduktan sonra, takım bunu doğrulayabilir (ve / veya ayarlayabilir) ve sprint için bir eylem planı üzerinde anlaşabilir.
İPUCU Takım, her sprintte teknik borcu azaltmanın yollarını düşünmelidir. Takımın iş yığınındaki hataları vurgulayan hızlı bir filtre oluşturmak , ekip kod tabanının çeşitli alanlarında story point'ler üzerinde çalışmaya devam ederken sprint'e çekilecek önemli hataları vurgulamanın kolay bir yoludur. "tech debt (teknoloji borcu)" hızlı filtresi, görünümü hatalarla sınırlamak için JQL "type in (bug)" özelliğini kullanır. JQL sorgusunu gerektiğinde ek talep türlerini içerecek şekilde genişletin.
Sprint planlamadaki bir sonraki adım, hikayelerin üzerinden geçmek ve her hikayeyi tamamlamak için hangi çalışmanın gerekli olduğunu açıklamaktır. Ekip planlarken, birisinin her Jira talebi içindeki kilit noktaları yakaladığından emin olun. Ekip şu soruları dikkate almalıdır:
Hikayenin tanımı yazıldığından beri değişti mi? Ekibin dikkate alması gereken yeni bağlamsal bilgiler var mı?
Hikayenin tahmini hala geçerli mi? Tüm ekip tahmin üzerinde hemfikir mi? Değilse, scrum master ekibe yeniden tahmin yoluyla rehberlik etmelidir.
Bu hikayeyi tamamlamak için hangi görevler gerekiyor? Çalışmanın paralelleştirilmesine ve akışı optimize etmeye yardımcı olması için alt görevleri kullanın. Ekip, işi çözerken benzersiz hikayeler bulursa, bu görevleri tamamen bağımsız hikayelere dönüştürün.
Bu hikaye için test edici çıkarımlar nelerdir? Testi nasıl otomatikleştirebiliriz?
Herhangi bir uzman beceri seti gerekli mi? Ekibin geri kalanını engellemeden uzmanın zamanını nasıl optimize edebiliriz?
Bu hikaye, ürünün mimarisini nasıl etkiliyor? Takımın tasarım ve kod incelemesine dahil etmesi gereken belirli kişiler var mı?
Hikayeler arasında herhangi bir bağımlılık var mı? Bu bağımlılıklar göz önüne alındığında, sprint sırasında tüm işi tamamlayabilir miyiz?
İyi bir planlama, sprint başladığında çok sayıda kazanç sağlar. Buradaki odak noktası, ekip arasında sohbeti kolaylaştıran scrum master ile işin nasıl yapılacağını anlamaktır. Herkesin sesini duyması önemlidir, böylece plan yürürlüğe girdiğinde ekip bir sahiplenme duygusu hisseder.
İPUCU Sprint planlaması sırasında, takım sprint tahminini oluştururken hikayeleri sprintin içine ve dışına taşımak kolaydır. Sprint'in içine veya dışına taşımak için bir konuyu sağ tıklamanız yeterlidir.
Toplantının bu noktasında, takım sprint tahmininden memnun olmalıdır. Sprint planlamasının sonunda, odadaki herkesten takımın sprint sonunda neyi göndermeyi taahhüt ettiği konusunda sözlü onay almak iyi bir uygulamadır. Ayrıca, her ekip üyesinin başlamak için en az bir görevi olduğunu ve kimsenin işi kopyalamadığını belirleyin.
Takım katılımı ve morali doğal olarak sprintten sprint'e dalgalanacaktır. Bu varyasyonlar genellikle sprint planlaması sırasında ortaya çıkar. Morali etkileyen sorunları anlamak için ekibin geçmişini kullanın. Kültür ve geliştirme sorunlarına hızlı yanıt veren ekipler daha mutlu, daha üretken ve daha iyi kod yazmaktadır.