Haberler’de çevik yazılım geliştirmeye ve Scrum’a giriş, 3. bölüm

[bencede]

1. 
   
   Haberler’de çevik yazılım geliştirmeye ve Scrum’a giriş, 3. bölüm
   

Agile konulu blog yazımızın üçüncü bölümü, sistemimizde yer alan süreçlerde kök salmış olaylar hakkındadır. Bunun çoğu, birçok şirkette çevik bir sistem oluşturanın en az yarısıdır. Burada ve orada kesinlikle normdan sapıyoruz.


Her şeyden önce: geliştiricilerin çok sayıda çevik olaydan korkması tamamen temelsiz değildir. Çünkü onlardan çok fazla var ve genel olarak çoğumuz muhtemelen şimdi toplantılarda geçişten önce olduğundan daha fazla zaman harcıyoruz. Ancak: Etkinliklerin kesinlikle var olma hakkı vardır ve gerçekten geliştiğiniz dönemde çok daha güçlü bir konsantrasyon sağlar.



Ancak benim görüşüme göre, Scrum veya benzeri bir şeyin tanıtımına, toplantı kültüründe bir değişiklik eşlik ETMELİDİR. Net hedefler, yapı, katı bir zaman çizelgesi ve uzaklaştığınızda anında harekete geçme artık her zamankinden daha önemli. Bu, özellikle başlangıçta biraz disiplin ve özenli bir Scrum Master gerektirir, ancak en azından bazı olaylarda/insanlarda ikinci doğa haline gelir.

Ayrıntılı olarak etkinliklerimiz


Sprintlerimiz iki hafta sürüyor. Sprint değişimimiz her zaman Salı gününe denk gelir. Sprintleri bölmek için gerçek takvim haftaları bize mantıklı gelmiyordu, çünkü sprint değişikliğinden önceki gün genellikle sunumlarla dolu kritik bir zamandır ve ardından Cuma gününe denk gelir.

Günlük Vuruş:

• günlük sabah toplantıları
• Ayakta dururken kısa bir özet yapın
• Takım, PO ve Çevik Koç
• 15 dakika

Günlük stand-up, muhtemelen çoğu BT ekibinin bir parçasıdır ve muhtemelen her yerde olduğu gibi bizim için de aynıdır. Sırayla, herkes kısa ve öz bir şekilde ne yaptıklarını ve ne yapacaklarını ve bir şeyin onları durdurup bozmadığını anlatıyor. Yurt dışında çalışan iş arkadaşları, “telepresence”larının bulunduğu gruba entegre olurlar. Bu genellikle ayaklı bir iPad’dir. Ayrıca zaman zaman oylama teknikleri (“üçlü el kaldırma” veya benzeri) kullanırız.

Uzak bir meslektaşı olan bir gazete


(Resim: Stephen Fisher)



Sprint incelemesi

• Sprint değişiminin açılışında iki haftada bir
• Her takımdan bir veya iki temsilci büyük bir ekranda gösterildi
• Oditoryumdaki tüm ekipler, OP’ler ve paydaşlar
• 3×15 dakika

Gözden geçirme, sprint sırasında takımlarda hazırlanır. Bu genellikle sprint değişikliğinden önceki gün olur. Seyirciler, sprint sonuçlarının sunulduğu ve soru sorabilecekleri veya geri bildirim sağlayabilecekleri üç grup halinde takımdan takıma geçer. Seyirciler paydaşlardan, OP’lerden ve diğer tüm ekiplerden oluşur. Yayınevinin her yerinden ilgili tarafları katılmaya davet ediyoruz. Mümkünse, televizyonda gerçek şeyleri iş başında göstermek için girişimlerde bulunulmalıdır. Çalışan bir RSS beslemesi, açılır menü veya entegrasyon testiyse, öyle olsun.

Sunum ekibi üyeleri, herkesin diğer ekiplerin sunumlarını da görebilmesi için düzenlenebilir.

I/Pulling sprint planlama

• incelemeden sonra iki haftada bir
• bir sonraki sprint için hikayeler ortak beyaz tahtaya çizilir
• tüm ekipler, PO’lar ve Çevik Koçlar
• 45 dakika

İlk olarak, mevcut sprintteki hikayelerin bir sonrakine beslenmesi gerekip gerekmediğini belirleriz. Şahsen benim için her zaman küçük bir yenilgi. Bununla birlikte, çevik çalışma için bu oyunlaştırma teşvikleri bile genellikle benim için iyi çalışıyor.

Daha sonra biriktirme listesindeki hikayeler arka arkaya okunur ve tekrar kısaca açıklanır. Bizim durumumuzda süreç, geliştirme ekibinden birinin kendi ekibi adına rapor vermesini içeriyor. Sizden veya başka bir ekipten herhangi bir itiraz gelmezse, hikaye ödüllendirilir ve bir sonraki hikaye okunur.

Bu, kimse cevap verene kadar devam eder. Bazı durumlarda, sinerji etkileri olduğu için sıralama tekrarlanır. Bazı öyküler, birbiri ardına grupça, hatta paralel olarak çalışılırsa daha hızlı ilerler.

Sprint planlama II/Görevin alt bölümü

• iki haftada bir sprint değişim gününde
• Gemideki ekip odalarında
• Geliştirme ekipleri katılıyor
• Zaman taahhüdü büyük ölçüde değişir

Görev dağılımında, ekipler tipik olarak birisinin üzerinde çalıştığı büyük bir ekranın önüne oturur ve çizilen hikayeleri bireysel görevlere ayırır, bu görevler daha sonra ekibin duyuru panosunda yapılacaklar sütununda yapışkan notlar olarak son bulur. Sık sık koda bakar ve onu sözlü olarak programlarız. İdeal olarak, görevler yapıştırılmadan önce tekrar ayrıntılı olarak açıklanır, böylece tüm ekip üyeleri görev hakkında kabaca bir fikir sahibi olur. Faaliyetlerin genellikle tahtada bir sırası vardır. Sprintte artık görev için tüm gereksinimlerin karşılanıp karşılanmadığına dikkat etmeniz gerekmez.

Görev bölümü güzel bir sanattır. Bir hikayeyi kesmek için doğru noktaları bulmak çok zor olabilir. Bazen bu adım sıkıcıdır ve başınızı duman eder.

geriye dönük

• sprint değişim günü civarında iki haftada bir
• Geçmiş sprint tartışması
• Geliştirme ekibi, PO, Çevik Koç
• 1 saat civarında

Bizim için retrospektif, Scrum Master’ın terapist olduğu çevik terapi turudur. Geçmişe dönük incelememizde, ruh halinin genel bir resmiyle başlamak adettendir. Herkes kendini bir diyagramda bir mıknatısla işaretler ve mevcut durumu hakkında birkaç kelime söyler.

Çeşitli teknikler ve (yine çok sayıda yapışkan kağıt) ile ekip ve OP daha sonra sinir bozucu olan şeyleri ortaya çıkarır. Elbette olumlu şeylerden de bahsedilebilir ve bahsedilecektir. Daha sonra, takip edilmesi için her zaman kaydedilen veya duvardaki bir posterde verilen ölçümler türetilmeye çalışılır. Çevik Koçumuz tüm retrospektiflere katıldığı için, belirli ekipler arası sorunlar ortaya çıktığında ekipler arası eylemler başlatabilir.

Burada da çok insan olabilir ve her zaman biraz incelik gerekir çünkü bazen sorunlar ekip üyelerini de etkiler. Temel olarak, retrospektif, sistemin gelişmeye devam etmesini sağlayabilir.

birikmiş işlerin tamamlanması

• duruma bağlı olarak bir ila iki haftada bir
• Biriktirme listesinde veya daha önceki aşamalarda hikaye tasarımı
• Geliştirme ekibi, PO, Çevik Koç
• 1 saat civarında

Çevik çalışmayı organize ederken, hikayelerin önceden belirlenmiş tüm gereklilikleri karşılaması önemlidir. Ekipler bunu “Hazırın Tanımı”nda belirledi. Birikmiş iş listesini iyileştirmenin temel amacı, gelen hikayelere hazırlık yapmaktır. Ancak bizde OP’ler, ekibin yardımıyla daha da uzak projeleri hikayelere bölmek için de kullanıyor. Bu, görevleri bölmek kadar karmaşık olabilir.

Hipotez

• Duruma göre 1-2 haftada bir
• Hikaye puanları olmayan hikayeler, bir çaba tahmini alır
• Tüm ekipler, tüm PO’lar, Çevik Koçlar
• yaklaşık 1.5 saat

Tahmin etme (veya Scrum öğretiminde tahmin etme), İngilizce bir terim almadığı için bizim tarafımızdan esas olarak (Frank) Schätzing olarak adlandırılır. Bu benim en sevdiğim olay.

Henüz tahmini olmayan hikayeler okunur ve anlatılır. Bir geliştirici olarak, bunu genellikle ilk kez duyarsınız. Takdir edilmeyen hikayeler genellikle biraz daha ileridedir. Ardından, sistemimizde üç soru veya yorum sorulabilir. Bu genellikle kullanılan teknikler, uygulamanın ayrıntıları veya hikayenin genel özü hakkında çılgın tartışmalara yol açar. Kesinlikle çıraklık olarak değil ama ben şahsen gübre kaosunu ve konuşmayı seviyorum. Sinirler yatıştıktan sonra, herkes bir dizi hikaye puanı için oy verir. Ölçüm için ikinin kuvvetlerini (2, 4, 8, 16, 32, vb.) kullanıyoruz. Tabii ki soru, yorum veya fikir ayrılığı olmadığı ve oylamanın derhal medeni bir şekilde yapıldığı da oluyor. Tahmin, yalnızca hikayelerin sayısallaştırılmasını sağlamakla kalmaz, aynı zamanda yaklaşan projeler hakkında farkındalığı yayar ve alışverişi teşvik eder.

Şimdilik evimizin olaylarının konusu bu olmalı. Büyük moda destanının bir sonraki ve son bölümünde, bir sonuca varmak ve yolculuğumuzdan edindiğim bilgileri ve ipuçlarını paylaşmak istiyorum.


(sfi)



Haberin Sonu