Scrum Kılavuzu | 35. Günlük Scrum

Günlük Scrum on beş dakikadan fazla sürmez ve gereksiz karmaşıklığı azaltmak için her zaman aynı yerde ve aynı zamanda yapılır. Ürün üzerinde birlikte çalışan tüm Geliştiriciler ve isteğe bağlı olarak Scrum Master katılır. Bu Scrum Etkinliğinin temel amacı, gün için odaklanacakları görevleri planlamaktır.

Günlük Scrum – içindekiler tablosu:

1. giriiş
2. Günlük Scrum formülü
3. Günlük Scrum ve 5W yöntemiyle ilgili sorunlar
4. Destekleyici sorular
5. 5 Neden
6. Özet

giriiş

Günlük Scrum, genel bir bakışı ayrı bir makalede bulunabilecek olan Scrum Olaylarının en kısa ve en sık görülenidir . Daily Scrum'a katılan Geliştiricilerin görevi, sonraki 24 saat için hızlı bir şekilde çalışma hedeflerini belirlemektir. Bu şekilde, her biri diğerlerinin ne üzerinde çalıştığını ve ortak bir Sprint Hedefi için nasıl çalıştıklarını bilir.

Günlük Scrum formülü

Tek bir doğru Günlük Scrum formülü yoktur. Her Geliştirme Takımı, kendisine uygun bir toplantı formatı geliştirir. Ancak, yürütmeyi kolaylaştırmak için genel bir çerçeve vardır .

İyi yönetilen bir Günlük Scrum, her katılımcının iki soruyu yanıtlamasına izin vermelidir:

• Bugün yapacağım en önemli görev nedir?
• Bu görevi gerçekleştirmenin önündeki engeller nelerdir?

Ancak onlara doğrudan sormak zorunlu bir formül değildir. Bunlar, toplantının eksenini tanımlayan örnek sorulardır. Daily Scrum, Geliştirme Takımındaki iletişimi iyileştirmeyi, görevlere öncelik vermeyi ve darboğaz riskini azaltmayı amaçlar.

Daily Scrum, diğer Agile yöntemlerindeki Daily Standup'a eşdeğer bir olaydır. Ve genellikle buna çok benzer şekilde çalışır – ancak resmi Scrum Kılavuzu, Geliştiricilerin bu kısa Etkinlik sırasında ayakta durmasını gerektirmez. Çoğu zaman, katılımcıları resmi olmayan bir grupta konuşurken sadece ayakta dururlar.

Günde 15 dakika günlük görevleri tartışmak için çok fazla gibi görünse de, uygulama böyle bir toplantının Geliştirme Ekibinin etkinliği için en iyisi olduğunu gösteriyor. Hedefler ve taahhütlerle ilgili sık ve düzenli güncellemelerle, tüm Geliştiriciler öncelikli görevlere odaklanır ve bireysel sonuçlar yerine sorunsuz ekip ilerlemesine öncelik verir.

Günlük Scrum ve 5W yöntemiyle ilgili sorunlar

Daily Scrum ile ilgili sorunlardan biri, Geliştiricilerin toplantı süresini uzatmasıdır. Durum buysa, Günlük Scrum için merkezi olmayan ancak Takım için önemli olan sorunlu konuları – fiziksel veya sanal – bir tahtaya yazma politikasını tanıtmak iyi bir fikirdir. Bu sayede gün içinde yapılan informal tartışmalarda tartışılmaya bırakılan sorunlara geri dönülebilecektir. Ayrıca, gerekirse, ayrı bir makalede daha ayrıntılı olarak açıklayacağımız Sprint Retrospektifi sırasında.

Günlük Scrum'lar sırasında sıklıkla ortaya çıkan bir diğer sorun, onları önceki günün çalışmalarını özetlemek için toplantılara dönüştürmektir. Geliştiriciler daha sonra elde edilen sonuçları tartışmaya odaklanır. Bu iyi bir uygulama değil. Kabul etmek gerekir ki, Geliştiricilerin Sprint Hedefine giden işin durumu konusundaki mevcut yönelimi çok önemlidir. Ancak, Günlük Scrum'ı zaten tamamlanmış görevlere adamak verimliliği artırmaz.

Destekleyici sorular

Takım Günlük Scrum'dan yararlanmıyorsa, Scrum Master, aşağıdaki soruların yanıtları için toplantıyı gözlemleyerek Geliştiricilerin sorunları belirlemesine yardımcı olabilir:

5 Neden

Sorunun ilk tanımlanmasından sonra, sorunun nedenini belirlemek için etkili bir teknik, Sakichi Toyoda tarafından 5 Whys veya 5W olarak da adlandırılan 5 Why yöntemi olabilir. Birkaç “Neden?” Sorusunu sormayı içerir. ardı ardına sorular. Bu, sorunun daha derindeki nedenini teşhis etmeyi ve böylece daha kolay çözmeyi mümkün kılar.

Örneğin, tablodaki son maddeyi ele alalım: problem Geliştirme Takımı tarafından problem çözme taahhüdü alanında ortaya çıkar. Beş soru aşağıdaki gibi görünebilir:

1 x NEDEN?

S: Geliştiriciler neden ortaya çıkan sorunları çözmek için farklı yollar sunmuyor?

C: Çünkü Geliştirici Harry her zaman bir çözüm öneren ilk kişidir.

2 x NEDEN?

S: Neden Geliştirici Harry her zaman bir çözüm öneren ilk kişi oluyor?

C: Çünkü başka kimse konuşmuyor.

3 x NEDEN?

S: Neden başka kimse konuşmuyor?

C: Çünkü diğer Geliştiricilerin daha iyi çözümler arama arzusu yoktur.

4 x NEDEN?

S: Neden diğer Geliştiriciler daha iyi çözümler aramak istemiyor?

C: Çünkü çözümler bulmak odaklanmayı gerektiriyor ve Harry'nin çözümünü yeterince iyi olarak düşünmek daha kolay.

5 x NEDEN?

S: Neden Harry'nin çözümünün yeterince iyi olduğunu düşündüler?

C: Alternatif teklif ettikleri için ödüllendirilmediklerinden, toplantının başında bugün için planlarını tartıştılar ve başlamayı düşünüyorlar.

Bu durumda, günlük Scrum'ın sırasını değiştirerek ve bu konudan başlayarak sorunları çözme taahhüdünün olmaması sorunu çözülebilir. Veya en iyi çözümü ödüllendirmek için bir sistem geliştirmek, örneğin belirli bir Sprint'te Takım tarafından kabul edilen en fazla sayıda çözümün yazarına sembolik bir ödül vermek.

Özet

Günlük Scrum, Geliştirme Takımının günlük çalışmasının önemli bir parçasıdır. Ancak, her Takım bu toplantı için en uygun formülü kendisi bulmalıdır. İyi yürütülen bir Günlük Scrum, Sprint Hedefine ulaşmak için devam eden alt hedeflerin belirlenmesine izin verir. Ayrıca, iletişim sorunlarını hızlı bir şekilde teşhis etmeyi ve Geliştiriciler arasındaki işbirliğini geliştirmeyi mümkün kılar.

İçeriğimizi beğendiyseniz, Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest'teki meşgul arılar topluluğumuza katılın.

Yazar: Caroline Becker

Bir Proje Yöneticisi olarak Caroline, en iyi iş akışlarını tasarlamak ve süreçleri optimize etmek için yeni yöntemler bulma konusunda uzmandır. Organizasyonel becerileri ve zaman baskısı altında çalışabilme yeteneği, onu karmaşık projeleri gerçeğe dönüştürmek için en iyi kişi yapıyor.

Tüm gönderileri görüntüle

Scrum Kılavuzu:

1. Temel terimler, roller ve kavramlar sözlüğü
2. Scrum nedir?
3. Scrum değerleri
4. Şirketinizde Scrum nasıl uygulanır?
5. Scrum Takımı - nedir ve nasıl çalışır?
6. Ürün Sahibi kimdir?
7. Ürün Sahibinin En Sık Yapılan Hataları
8. Scrum Master kimdir?
9. İyi bir Scrum Master'ın Özellikleri
10. Scrum Master'ın en yaygın hataları
11. Scrum Master hangi istatistikleri ve metrikleri izlemelidir?
12. Ürün Sahibi ve Scrum Master Arasındaki İşbirliği
13. Scrum'da Geliştirme Takımı
14. Geliştiricilerin en yaygın hataları
15. Scrum eserleri
16. Scrum'ı Ölçeklendirme
17. Sprint İş Listesi
18. Ürün İş Listesi nedir?
19. Kullanıcı Hikayeleri nedir?
20. INVEST ile en iyi Kullanıcı Hikayesini Oluşturmak
21. En yaygın Kullanıcı Hikayesi hataları
22. Kullanıcı Hikayesi Kabul Kriterleri
23. Scrum'da Tahmin ve Öykü Puanları
24. Poker Planlama
25. Takım Tahmin Oyunu
26. Artış Tanımlama
27. Scrum etkinlikleri
28. Scrum'da Sprint nedir?
29. Scrum Takımı Taahhütleri - Ürün Hedefi, Sprint Hedefi ve Tamamlamanın Tanımı
30. Burndown Grafiği nedir?
31. İş bitim grafiği nasıl oluşturulur ve yorumlanır?
32. İş bitim grafiğinin avantajları ve dezavantajları
33. Scrum ve Scrumban'da Kanban panoları
34. Scrum'da Hız - Geliştirme Takımının Hızı
35. Günlük Scrum
36. Sprint Planlama
37. Sprint İncelemesi
38. Sprint Retrospektifi nedir?
39. Sprint Retrospektifi sırasında yaygın hatalar
40. Ürün İş Listesi beslemesi