Scrum'daki Süreçler

Sprint planlama

Sprint planlama, Scrum sprintinin ilk aşamasıdır. Sprint sırasında iş yapmanın kapsamını ve yollarını belirler. Scrum ekibinin tamamı planlamaya dahil olur.

Sprint, belirli bir iş parçasının tamamlanması gereken, açıkça tanımlanmış bir zaman periyodudur. Bir sprint başlamadan önce planlama gerektirir. Öncelikle sprintin süresini ve hedefini belirlemeniz gerekiyor.

Planlama atölyesinde, görevlerin listesi ve sprint'in hedefi üzerinde anlaşmaya varılır. Her üyenin başarıya odaklanması için ekibi doğru çalışma motivasyonuyla şarj etmek önemlidir.

Sprint kötü planlanmışsa, bu, ekibin başarısız olmasına neden olabilir. Geliştiriciler, görevlerin gerçekçi olmadığı ortaya çıktığı için kendilerine yüklenen beklentilerle baş edemeyecekler.

Bir sprint planlarken dikkate alınması gereken sorular:

• Müşteri veya yazılım sahibi, sprint'in hedefini duyururken, ona nasıl ulaşılacağını açıklar. Scrum ekibi, bu hedefe ulaşmak için gelecekteki bir sprintte hangi görevlerin tamamlanabileceğini öğrenir.
• Geliştiriciler, yazılım müşterisi ile kararlaştırılan bir çalışma planını kendi aralarında dağıtırlar.
• Ürünün müşterisi (sahibi) her zaman sprint planının hazırlanmasında yer alır. Bir hedef belirler ve programlama ekibinin bir sprintte ulaşılıp ulaşılamayacağını bulması gerekir.
• Plan, bilgilerin plana eklenebileceği bir ürün biriktirme listesi kullanmalıdır.
• Ekip üyeleri, sonuca ulaşmak için neye ihtiyaç duyduklarını net bir şekilde anlayarak planlama toplantısını sonlandırmalıdır. Sprint biriktirme listesinde gelecekteki eylemlerin sırasını görüntüleyebilirsiniz.

Planlama haftada iki saati geçmemelidir. Scrum Master herkese zaman sınırları olduğunu açıklamalıdır. Tüm işle ilgili sorunlar hızlı bir şekilde çözülürse, toplantı normalden daha erken sona erebilir. Böyle bir toplantı için minimum süre yoktur.

Görev değerlendirmesi

İşin karmaşıklığını değerlendirmek, aşırıya kaçmanıza gerek yok. Planlama süreci, geliştirmenin karmaşıklığının kesin değil, en azından yaklaşık bir değerlendirmesine ihtiyaç duyar. Takım sadece sprintin hedefini anlamamalı, aynı zamanda hedefi takımlarının yetenekleriyle karşılaştırmalıdır.

Karmaşıklığı değerlendirmek için, herkes için normal giysi bedenlerini (L, XL, XXL) kullanabilirsiniz. Tabii ki, bu bir doğruluk garantisi vermiyor, ama yine de.

Karmaşıklık değerlendirmesinin daha doğru olabilmesi için karşılıklı anlayışa ihtiyaç vardır. Ekip üyeleri fikirlerini açıkça paylaşmalı ve ürün sahibine soru sormaktan çekinmemelidir.

İş tamamlandıktan sonra ekibe yönelik eleştiri, bir sonraki sprinti planlarken tahminlerin daha az iyimser olmasına yol açabilir. Bu, ekibin hatayı tekrarlamaktan kaçınmasına ve gelecekte olumsuz değerlendirilmekten korunmasına yardımcı olacaktır.

Puan, puan ve saat cinsinden zorluk değerlendirmesi

Tipik olarak, geliştirme ekipleri işlerinin karmaşıklığını zaman içinde tahmin eder. Ancak bazı Çevik ekipler, zorluğu puan veya puan olarak derecelendirmeyi seçer. Bu, bir biriktirme listesi öğesini veya atanmış başka bir görevi uygulamak için gereken toplam maliyetin daha iyi bir göstergesidir.

Puanlar işin karmaşıklığına ve hacmine göre verilir. Ayrıca olası riskler de dikkate alınır. Bu yöntemi kullanarak puanlama, çalışmayı etkili bir şekilde küçük adımlara ayırmaya yardımcı olur.

Planlama yaparken puanlama yöntemini (puanları) düzenli olarak kullanan ekipler, işi tamamlamak için ne kadar zamana ihtiyaç duyacaklarını daha iyi ve daha doğru bir şekilde anlarlar. Ek olarak, başka avantajlar da var.

• Kesin olarak görünse de, zaman tahmini, projeyle doğrudan ilgili olmayan işleri hesaba katmaz. İşle ilgili sorunları bir haberci aracılığıyla tartışmak, toplantılar yapmak - tüm bunlar ekip üyeleri için de zaman alır.
• Duygular tarih seçimini etkileyebilir. Çalışmayı değerlendirirken puanlama bu faktörü ortadan kaldırır.
• İşin karmaşıklığının değerlendirilmesi ve buna bağlı olarak görevleri tamamlama hızı ekiplerin her biri için farklı olabilir. Yapılan puanlarla çalışma herhangi bir hız göstergesi olarak kabul edilemez. Yani takım üzerinde psikolojik bir baskı yok.
• İşçilik maliyetlerini ve karmaşıklığı doğru bir şekilde dağıtarak, katılımcılar arasında gerçekleştirilen iş için noktaları hızlı ve çatışmasız bir şekilde bölebilirsiniz.
• Bir görevi tamamlamak için alınan puanların sayısı, harcanan zamana değil, karmaşıklığına bağlıdır. Bu nedenle programcılar, ne kadar süreceğini değil, verimliliklerini artırmayı düşüneceklerdir.

Karmaşıklık tahmininin dezavantajı, genellikle yanlış kullanılmasıdır. Örneğin, bu yöntem çalışanları değerlendirmek için kullanılamaz.

Ekipler, kendilerine atanan iş miktarını daha iyi anlamak ve doğru şekilde önceliklendirmek için bir puanlama sistemi kullanmalıdır.

Günlük Scrum Toplantısı

Çalıştaylar önemlidir: Atölyelerde ekip üyeleri fikirlerini paylaşır, iletişim kurar ve sonraki eylemler üzerinde anlaşırlar. Takım ruhunu yükseltmek ve güncel haberleri duyurmak için günlük scrum toplantılarına da ihtiyaç vardır.

Stand-up, kilit proje katılımcılarının kısa bir toplantısıdır: yazılım sahibi, programcılar ve scrum ustası. Stand-up'ın yapısı üç sorudan oluşmaktadır.

• Dün ne yapabildik?
• Bugün ne üzerinde çalışıyoruz?
• Sonuçlara ulaşmamızı engelleyen nedir?

Bu soruları sormak gelişimi teşvik eder ve ekip içindeki sorunları tanımlamaya yardımcı olur. Her katılımcı ortak bir hedefe ulaşmak için nasıl yardımcı olduğunu ilettiğinde, bu, ekip içinde karşılıklı anlayışı geliştirir.

Stand-up'ların nasıl yapılacağına dair tek bir şablon olmadığını hatırlamak önemlidir. Her takım, takım özelliklerine göre kendi modeline göre toplantılar yapar.

Şimdi de mükemmel bir stand-up için neler gerektiğini tartışalım ve etkili stand-up örnekleriyle tanışalım.

Öncelikle herkese uygun bir zaman seçmelisiniz. Genellikle aynı ofisteki ekipler için stand-up'lar iş gününün başında - sabah 9 ile 10 arasında yapılır. Bu size günlük programınızı daha iyi planlamak için zaman verir. Ekip üyeleri farklı bölgelerde çalışıyorsa, herkese uygun bir zaman seçilir. Örneğin, bazı ekip üyeleri Kaliforniya ve Sidney'de yaşıyorsa stand-up Kaliforniya saatiyle 15:30'da başlar. Tabii ki yemekten sonra ayakta durmak herkes için uygun değil ama okyanusun diğer tarafındaki meslektaşlarınızla iletişim halinde olmanızı mümkün kılıyor.

Stand-up üretkenliğini takip edin. Toplantıyı çok uzun tutmayın - dikkat konsantrasyonu en iyi seviyede kalmalıdır. Mümkünse, stand-up'ları 15 dakikadan uzun tutmayın.

Topu kullan. Sırayla birbirine atılabilir. Böylece herkes tartışmaya dahil olacak. Bu oyun gruptaki dikkati korumaya yardımcı olur. Takım retrospektifini kullanın. Stand-up'lar birçok Agile metodolojisinde kullanılmaktadır, bu retrospektiflerde stand-up'ların etkinliğini tartışmamızı engellemez. Biri her gün buluşur, diğer takımlar - haftada birkaç kez. Takımın stand-up'tan faydalanması zorsa, bunun nedenlerini bulun ve bir şeyleri değiştirin.

Sprint incelemesi

Bahar incelemesi, sprintin son aşamasında gerçekleştirilir. Ürün artışını kontrol etmek ve birikmiş iş listesini uyarlamak gerekir. Sprint sonuçlarının gözden geçirilmesine tüm scrum ekibi ve tüm paydaşlar katılır. Toplantı, proje katılımcılarının etkileşimini geliştirmek için rahat bir formatta yapılır.

Sprint Sonuçları İncelemesi aşağıdaki unsurları içerir:

• Yazılım sahibi, biriktirme listesinden nelerin tamamlanıp nelerin tamamlanmadığını gösterir.
• Programcılar neyin iyi gittiğini, zorlukların nerede ortaya çıktığını ve bunların nasıl ortadan kaldırıldığını tartışırlar.
• Geliştirme ekibi, sprint sırasındaki çalışmalarının sonuçlarını ve aldıkları ürün artışını gösterir.
• Ürün Sahibi, mevcut biriktirme listesi hakkındaki düşüncelerini paylaşır. Ayrıca bir sonraki hedef için bir tahmin ve uygulanması için son tarih verir.
• Herkes, pazar değerlendirmesi ve kullanıcı ilgi alanlarına göre bundan sonra yapılacak en iyi şeyin ne olduğunu tartışır.
• Zamanlama, bütçe ve birikmiş iş listesine ekleme beklentileri hakkında görüş alışverişinde bulunulur.

Sonuç, sonraki sprintler için yeni hedeflerle güncellenmiş bir biriktirme listesidir. Durum gerektiriyorsa birikim değiştirilebilir.

Sprint Retrospektifi

Sprint Retrospektifi, iş akışınızı nasıl geliştireceğinizi tartışan bir atölye çalışmasıdır. Ayrıca bir sonraki sprint için bir iyileştirme planı oluşturur. Toplantı genellikle sprint gözden geçirmesinden sonra yapılır ve üç saatten fazla sürmez. Toplantıyı yöneten Scrum Master'dır.

Sprint Retrospektifinin ana hedefleri şunları içerir:

• Sprint analizi (katılımcıların çalışmaları, sonuçlar ve problemler).
• Sonraki sprintlerde iş akışını iyileştirmek için olası çözümleri tartışın.
• Projenin uygulanması sırasında ekip üyeleri tarafından iyileştirmelerin uygulanması için bir planın oluşturulması.

Scrum Master, ekip üyelerini geliştirme verimliliğinin nasıl artırılacağı konusunda önerilerde bulunmaya davet eder. Ekip önerileri tartışır ve bunların uygulanması için belirli yollar ve teknikler önerir.

Sprint Retrospective'in sonunda, takım bir sonraki Sprint'te uygulamak için birkaç iyileştirme önerisini vurgulamalıdır. Öneriler herhangi bir zamanda uygulanabilir, ancak Sprint Retrospective olası adaptasyonlarına takımın bakış açısından daha derinlemesine bakma fırsatı sunar.

Scrum metodolojisi tartışmamızı burada bitiriyoruz. Bununla ilgili daha fazla bilgiyi tematik belgelerde veya ilk iş yerinizde öğrenebilirsiniz.