Scrum ve en iyi yöntemler

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Sprint planlama toplantıları

Sprint planlamasının büyük bir kısmı, ürün sahibiyle ekip arasında odağı belirlemek ve yaklaşan sprint'te ele almak için çalışmak için bir anlaşma içerir. Planlama toplantısını 4 saat veya daha kısa bir süreyle kısıtlayarak zaman kutusuna almak yararlı olur.

Toplantının ilk bölümünde ürün sahibiniz, sprint'e dahil edilebilecek kullanıcı hikayelerini tartışmak için ekibinizle bir araya geldi. Ürün sahibiniz, ekibinizin bu hikayeler hakkında sahip olduğu tüm soruları paylaşır ve yanıtlar. Bu konuşmada veri kaynakları ve kullanıcı arabirimi düzeni gibi ayrıntılar ortaya çıkabilir. Ya da yanıt süresi beklentilerini ve güvenlik ve kullanılabilirlik konusunda dikkat edilmesi gerekenleri ortaya koyabilir. Ekibinizin bu ayrıntıları kapsam öğeleri formunda yakalaması gerekir. Toplantının bu bölümünde, ekibiniz ne oluşturması gerektiğini öğrenir.

Sprint'lerinizi planladığınızda, yakalamanız ve kapsamınıza eklemeniz gereken diğer gereksinimleri keşfedebilirsiniz. İyi tanımlanmış ve öncelik sırasına uygun olduğundan emin olun.

Ayrıca planlama çalışmalarınızın bir parçası olarak sprint hedefi belirlemek, ekibin her sprint için en önemli şeylere odaklanmasını sağlayabilir.

Sprint'inizi planladıktan sonra planı önemli paydaşlarla paylaşmak isteyebilirsiniz.

Bu kaynaklardan daha fazla bilgi edinebilirsiniz:

• Scrum nedir?
• Sprint planlama teknik incelemesi
• Scrum Kılavuzu
• Ürün kapsamı teknik incelemesini oluşturma ve yönetme

Sprint hedeflerini ayarlama

Scrum ekipleri sprint etkinliklerine odaklanmak için sprint hedeflerini kullanır. Genellikle sprint planlama toplantılarında bu hedefi belirlerler. Hedef, sprint'in sonuna kadar ekibin gerçekleştirmek istediği şeyi özetler. Hedefi açıkça belirterek, temel amacın ekibi içinde paylaşılan bir anlayış oluşturursunuz. Sprint hedefi, önceliklerle ilgili çakışmalar ortaya çıktığında takıma yol göstermesine de yardımcı olabilir.

Siperlerden İpuçları: Sprint hedeflerini tanımlama

Sprint hedefi, ürün sahibinin ve ekibin bu sprint'i gerçekleştirmek için nihai hedef olarak neleri değerlendirdiğini tanımlar. Bu, gerçekten ilişkisi olmayan rastgele bir kapsam öğesi seçimi değil, ekibin gerçekleştirmeye çalışması gerekenleri yakalayan kısa bir metin parçasıdır. Normalde ürün sahibi, sonraki sprint için birçok öğe seçmeden önce sprint hedefiyle gelir. Bu sprint öğelerinin tümü bu ortak hedefe uygun olmalıdır.

Sprint hedefleri özellik odaklı olabilir, ancak dağıtım otomasyonu veya test otomasyonu gibi büyük bir işlem bileşenine de sahip olabilir.

Örneğin:

• Bu sprint basit bir kullanıcı hikayesine odaklanacağız. Önerilen çözümün çalıştığını kanıtlamak için bunu kullanacağız.
• Bu sprint, web sitesinin yönetim bölümünü düzgün bir şekilde güvenli hale getiren güvenlik özelliklerini uygulama etrafında döner.
• Bu sprint, para toplamaya başlayabilmemiz için en önemli ödeme ağ geçitlerini tümleştirmeyle ilgili.

Sprint hedeflerini ayarlamak, takımın odaklanmasına yardımcı olur. Bir sprint içindeki görevlerin önceliğini tanımlamayı kolaylaştırır ve büyük olasılıkla ilgili proje katılımcılarının ve son kullanıcıların sayısını sınırlamaya yardımcı olur.

Sprint incelemesi sırasında kendinize sormanız gereken en önemli soru sprint hedefine ulaşıp ulaşmadığınızdır. Kaç hikaye tamamladığınız ikinci olur. Hedefe ulaşmak, tüm öyküler tamamlanmamış olsa bile sprint başarılı olur.

Katkıda bulunan Jesse Houwing, Visual Studio devops Ranger ve Avanade Hollanda'da çalışan üst düzey bir danışman.

Başarılı önceliklendirme toplantıları için İpuçları

Hataların düzeltilmesi, diğer çalışmalarla bir dengeyi temsil eder. Her hatayı düzeltmenin proje kapsamını, bütçesini ve zamanlamasını karşılamayla ilgili diğer önceliklere karşı ne kadar önemli olduğunu belirlemek için önceliklendirme toplantınızı kullanın.

• Hangi hataların düzeltileceğini ve öncelik ve önem derecesinin nasıl atanacaklarını değerlendirmek için ekibin ölçütlerini belirleyin. Önemli değer özellikleriyle (veya önemli bir gecikme fırsatı maliyetiyle) veya diğer proje riskleriyle ilişkili hatalar daha yüksek öncelik ve önem derecesine atanmalıdır. Önceliklendirme ölçütlerinizi diğer ekip belgeleriyle depolayın ve gerektiğinde güncelleştirin.
• Hangi hataların düzeltileceğini ve Durum, Öncelik, Önem Derecesi ve diğer alanların nasıl ayarlandığını belirlemek için önceliklendirme ölçütlerinizi kullanın.
• Önceliklendirme ölçütlerinizi geliştirme döngünüzdeki yeriniz temelinde ayarlayın. Erken saatlerde, önceliklendirme yaptığınız hataların çoğunu düzeltmeye karar vekleyebilirsiniz. Ancak, döngünün ilerleyen bölümlerinde düzeltmeniz gereken hata sayısını azaltmak için önceliklendirme ölçütlerini yükseltebilirsiniz.
• Bir hatayı önceliklendirildikten sonra bir geliştiriciye atayın. Geliştirici daha sonra bir düzeltmenin nasıl uygulandığını araştırabilir ve belirleyebilir.

Teknik borcunuzu yönetin

Ekibinizin genel sürekli iyileştirme etkinliklerinin bir parçası olarak hata çubuğunuzu ve teknik borcunuzu yönetmeyi göz önünde bulundurun. İlginizi çekebilecek şu kaynakları bulabilirsiniz:

• İyi ve Kötü Teknik Borç (ve TDD nasıl yardımcı olur) Henrik Kniberg
• Sven Johann & Eberhard Wolff tarafından gönderilen Teknik Borcu Yönetme

Siperlerden İpuçları: Hata yönetimi

Çevik Hata Yönetimi: Oxymoron Değil
Tarafından Gregg Boer, Baş Program Yöneticisi, Microsoft Visual Studio Cloud Services

Bilinen tüm hata borçlarını her sprint ile giderin

Ekip, her sprint'te hata kapsamında kalan hataları arar ve bilinen hata kümesini sıfıra veya sıfıra yakın bir değere indirebilmek için kapasiteyi ayırır. Bu bir gün, bir hafta veya sprint'in tamamı olsun, önce hataları düzeltir. Sprint içinde daha sonra bulunan hatalar bu ilk taahhüdün bir parçası olarak kabul edilmez. Yüksek öncelikli olmadığı sürece, bir sonraki sprint için hata kapsamına konurlar.

Birçok ekip taahhüt tabanlı bir kuruluşta çalışır. Yönetim genellikle bir ekibin taahhütlerini yerine getirebilme becerisine yüksek değer verir. Bilinen bir hata kümesine karşı kapasite planlaması yapmak sprint planlamasını daha belirleyici hale getirerek taahhütleri yerine getirme şansını artırır. Sprint sırasında bulunan tüm yeni hatalar ilk taahhüdün bir parçası değildir ve sonraki sprint'e giderilebilir.

Kuruluş genelinde hata borcunu yönetme

Borcun sürekli ortadan kaldırıldığı bir kültüre geçiş yapılan bir kuruluş şu soruyu ele alır: Ekiplerin tam olarak ne yapacaklarını söylemeden hata sayısını azaltmasını nasıl sağlarsınız? Liderlik ekibin değişmesini istiyor, ancak takıma nasıl değiştiklerini belirlemesi için özerklik veriyor. Bir seçenek, hata üst sınırı kullanmaktır.

Örneğin, mühendis başına üç hatadan oluşan bir hata üst sınırı düşünün. Bu nedenle, 10 kişiden oluşan bir ekibin hata kapsamı 30'dan fazla hataya sahip olmamalıdır. Ekip üst sınırı aşıyorsa yeni özellikler üzerinde çalışmayı durdurması ve hata sınırını aşması beklenir. Bir ekibin her zaman üst sınırın altında olması beklenir, ancak bunu nasıl yapmak istediğine takım karar verir. Hata sınırı, ekiplerin hata borcunu çok uzun süre taşımamasını sağlar. Ekip, hataların ilk etapta enjekte edilmesine neden olan hatalardan ders alabilir.

Hata üst sınırının hata kapsamındaki hataları temsil ettiğini unutmayın. Bir özelliğin geliştirildiği sprint içinde bulunan ve düzeltilen hataları içermez. Bu hatalar borç değil, geri alınmış iş olarak kabul edilir.

Hatalar teknik borçlara katkıda bulunurken, tüm borcu temsil etmeyebilir.

Kötü yazılım tasarımı, kötü yazılmış kod veya kısa vadeli düzeltmelerin tümü teknik borçlara katkıda bulunabilir. Teknik borç, tüm bu sorunlardan kaynaklanan ek geliştirme çalışmalarını yansıtır.

Teknik borcu PBI'ler, kullanıcı hikayeleri veya hatalar olarak ele almak için çalışmayı izleyin. Bir ekibin teknik borçlarla ilgili ilerleme durumunu izlemek için, iş öğesini ve izlemek istediğiniz ayrıntıları nasıl kategorilere ayırabileceğinizi göz önünde bulundurmanız gerekir. İstediğiniz bir kategoride gruplandırmak için herhangi bir iş öğesine etiket ekleyebilirsiniz.

Scrum Yöneticisinin Rolü

Scrum Masters, Scrum süreçlerini kullanarak sağlıklı ekipler oluşturmaya ve sürdürmeye yardımcı olur. Scrum ekiplerine Scrum yöntemlerinin uygun şekilde çalıştırılmasında rehberlik, koçluk, öğretme ve yardımcı olurlar. Scrum Masters, ekiplerin engelleri aşmasına ve ekibi önemli üretkenlik artışlarına yönlendirmesine yardımcı olmak için değişiklik aracıları olarak da görev alır.

Scrum Masters'ın temel sorumlulukları şunlardır:

• Scrum süreçlerini benimsemesi ve izlemesi için ekibi destekleyin. Örneğin, günlük Scrum toplantısının 45 dakika süren açık bir tartışma olmasına izin vermemelisiniz.

• Sprint başladıktan sonra ürün sahibine veya ekip üyelerinin iş eklemesine karşı koruma sağlayın.

• Ekibin ileriye doğru ilerlemesini engelleyen engelleme sorunlarını temizleyin. Bu çalışma, yeni bir derleme bilgisayarı için satın alma siparişi onaylama veya ekibiniz içindeki bir çakışmayı çözme gibi küçük görevleri tamamlamanızı gerektirebilir.

• Ortaya çıkan çakışmaları ve sorunları çözmek için ekibin çalışmasına yardımcı olun ve süreçle ilgili bilgi edinin.

• Gizli sorunları ortaya koyan sorular sorun ve insanların iletişimde olduklarının tüm ekip tarafından iyi anlaşıldığını onaylayın.

• Ekibi önemli sorunlara dönüşen olası sorunlardan tanımlayın ve koruma altına alın. Bir hatayı keşfedildikten hemen sonra düzeltmek daha ucuz olduğu gibi, küçük ve yönetilebilir olduğunda bir ekip sorununu düzeltmek de daha kolay ve daha az kesintiye neden olur.

• Sprint gözden geçirme toplantısı sırasında ekibin eksik kullanıcı hikayeleri sunmasını engelleyin.

• Ekibin nasıl geliştiğini ve büyüdüğünü göstermek için iş paydaşlarına veri toplayın, analiz edin ve sunun. Örneğin, ekibiniz daha az hata oluştururken teslim edilen değer miktarını artırdıysa, değeri iş paydaşlarına yapılan düzenli iletişimlerle görünür hale getirin.

İyi Scrum Ustaları mükemmel iletişim, müzakere ve çakışma çözümü becerilerine sahiptir veya geliştirir. İnsanların söylediği ve yazdığı sözcükleri etkin bir şekilde dinlerler. Ayrıca vücut dilleri, yüz ifadeleri, ses hızı ve diğer saldırgan olmayan iletişimler gibi mesajlarını nasıl teslim ettiklerini de dinlerler.

Bir hatayı keşfedildikten hemen sonra düzeltmek daha ucuz olduğu gibi, büyük bir soruna dönüşmeden önce küçük ve yönetilebilir olduğunda bir ekip sorununu düzeltmek de daha kolay ve daha az kesintiye neden olur.

Günlük Scrum toplantıları

Günlük Scrum toplantıları, bir ekibin ertesi gün yapması gerekenlere odaklanmasına yardımcı olur. Odaklanmış kalmak, ekibin sprint taahhütlerini karşılama becerisini en üst düzeye çıkarmalarına yardımcı olur. Scrum Master'ınız toplantının yapısını zorunlu kılmalı ve zamanında başlayıp 15 dakika veya daha kısa sürede tamamlandığından emin olmalıdır.

Başarılı Scrum toplantılarının üç yönü şunlardır:

• Herkes ayağa kalksın. Ayakta durmak, toplantıların odaklanmış ve kısa tutulmasına yardımcı olur.
• Zamanında başlayıp biter ve her gün aynı konumda aynı anda gerçekleşirler
• Herkes katılır, her ekip üyesi üç Scrum sorusuna yanıt verir:
  • En son Scrum'dan bu yana neleri başardım?
  • Bir sonraki Scrum'a geçmeden önce neler yapabilirim?
  • Hangi engelleyici sorunlar veya engeller çalışmamı etkileyebilir?

Ekip üyeleri sorularını hızlı ve kısa bir şekilde yanıtlamaya çalışmalıdır. Örneğin:

"Dün sınıfı veritabanından çektiğimiz yeni veri öğesini yansıtacak şekilde güncelleştirdim ve arabiriminde görünmesini aldım. Bu görev tamamlandı. Bugün, yeni veri öğesinin saklı yordam ve tablodaki diğer veri öğeleriyle doğru hesaplandığından emin olmak istiyorum. Bu görevi bugün başaracağıma inanıyorum. Hesaplamalarımı gözden geçirecek birine ihtiyacım var. Engelleyici veya engelleyici bir sorun yok."

Bu yanıt, ekip üyesinin neleri başardığını, ekip üyesinin neyi gerçekleştirmeyi planladığını ve ekip üyesinin koda bakmak için biraz yardım istediğini bildirir.

Bu sonraki örnekle karşıtlık:

"Dün, ders üzerinde çalıştım ve işe yarıyor. Bugün, arayüz üzerinde çalışıyorum. Engelleme sorunu yok."

Ekip üyesi, hangi sınıf üzerinde çalıştığı veya tamamlayacakları arabirim bileşenleri hakkında yeterli ayrıntı sağlamaz. Aslında, başaran kelime hiç ortaya çıkmadı.

Rapor çıkışı sırasında kimsenin araya girmemiş olması önemlidir. Her kişinin üç soruyu yanıtlamak için yeterli zamanı olmalıdır.

Toplantıdan sonra, insanlar masalarına döndükçe veya önemli miktarda konuşma gerekiyorsa, bir takip toplantısında daha ayrıntılı ve takip tartışmaları yapılmalıdır.

Birçok ekip "sanal otopark" yöntemini kullanarak tartışmaları geciktirir. Bir ekip üyesinin daha fazla tartışmaya ihtiyacı olduğunu düşündüğü konular ortaya çıktıkçe, sessizce beyaz tahtaya veya flipchart'a yürüyebilir ve konuyu park alanında listeleyebilir. Toplantının sonunda ekip, listelenen öğeleri nasıl işleyeceklerini belirler.

Sprint gözden geçirme toplantıları

Sprint gözden geçirme toplantılarınızı sprint'in son gününde gerçekleştirin. Ekibiniz sprint'te tamamlandığı her ürün kapsamı öğesini gösterir. Ürün sahibi, müşteriler ve paydaşlar, beklentilerini karşılayan ve yeni gereksinimleri tanımlayan kullanıcı hikayelerini kabul eder. Müşteriler genellikle tanıtımları gördükten sonra ihtiyaçlarını daha iyi anlar ve görmek istedikleri değişiklikleri belirleyebilir.

Bu toplantıya bağlı olarak, bazı kullanıcı hikayeleri tamamlanmış olarak kabul edilir. Tamamlanmamış kullanıcı hikayeleri ürün kapsamı içinde kalır. Kapsamına yeni kullanıcı hikayeleri eklenir. Her iki hikaye kümesi de bir sonraki sprint planlama toplantısında sıralanır ve tahmini veya yeniden tahmin edilir.

Bu toplantıdan ve geçmişe dönük toplantıdan sonra ekibiniz bir sonraki sprint'i planlıyor. İş gereksinimleri hızla değiştiğinden, ürün kapsamı önceliklerini yeniden gözden geçirmek için ürün sahibiniz, müşterileriniz ve paydaşlarınızla bu toplantıdan yararlanabilirsiniz.

Sprint geçmişe dönük toplantılar

Geçmişe dönük değerlendirmeler, iyi ve düzenli aralıklarla yürütülürken sürekli iyileştirmeyi destekler.

Sprint geçmişe dönük toplantısı genellikle sprint gözden geçirme toplantısından sonra sprint'in son gününde gerçekleşir. Bu toplantıda, ekibiniz Scrum'un yürütülmesini ve nelerin incelenmesi gerekebileceğini keşfeder.

Tartışmalara bağlı olarak, ekibiniz kendi verimliliğini, üretkenliğini, kalitesini ve memnuniyetini geliştirmek için bir veya daha fazla süreci değiştirebilir. Bu toplantı ve sonuçta elde edilen iyileştirmeler, kendi kendine düzenlemenin çevik ilkesi için kritik öneme sahiptir.

Takım sprint geriye dönük değerlendirmeleriniz sırasında bu alanları ele almak için bakın:

• Ekibinizin genel verimliliğini, üretkenliğini ve kalitesini etkileyen sorunlar.

• Ekibinizin genel memnuniyetini ve proje akışını etkileyen öğeler.

• Tamamlanmamış kapsam öğelerine ne oldu? Ekip gelecekte bu sorunları önlemek için hangi eylemleri gerçekleştirebilir?

  Örneğin, ekipte yalnızca bir kişinin gerçekleştirebileceği birkaç görevi olan bir ekibi düşünün. Yalıtılmış uzmanlık, sprint'in başarısını tehdit eden kritik bir yol oluşturdu. Tek tek ekip üyesi fazladan saatler koyarken, diğer ekip üyeleri yardımcı olmak için daha fazlasını yapamadıkları için hayal kırıklığına uğradı. Bundan sonra ekip, zaman içinde bu sorunu düzeltmeye yardımcı olmak için eXtreme Programlama'yı uygulamaya karar verdi.

Ekip olarak, sprint sırasında sorunların oluşmasını en aza indirmek için bir veya daha fazla işlemi uyarlamak isteyip istemediğinizi belirlemek için çalışın.

Ekibinizin bir geliştirme gerçekleştirmek için bazı çalışmalar yapması gerekebilir. Örneğin, çok fazla başarısız derlemeden olumsuz etkilendiğini bulan bir ekip sürekli tümleştirme uygulamaya karar verdi. Süreci kesintiye uğratmak istemedikleri için, üretim derlemelerinde açmadan önce deneme sürümünü ayarlamaları birkaç saat sürdü. Bu çalışmayı temsil etmek için bir ani artış oluşturmuş ve ürün kapsamı geri kalanına karşı çalışacak şekilde düzenlenmiştir.

İlgili makaleler

• Sprint etkinliklerinin sonu
• Scrum nedir?
• Çevik Geçmişe Dönük Değerlendirmeler: İyi Ekipleri Harika Hale Getirme