Sprint ve scrum için en iyi yöntemler

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Scrum, ekiplerin zaman kutulu sprint'ler aracılığıyla artımlı olarak değer sağlamasına yardımcı olan çevik bir çerçevedir. Bu makale sprint planlaması, günlük Scrum toplantıları, sprint incelemeleri, geçmişe dönük değerlendirmeler, hata önceliklendirme ve Azure DevOps'taki Scrum Yöneticisi rolü için en iyi yöntemleri kapsar.

sprint planlama toplantıları

Sprint planlaması, ürün sahibiyle ekip arasında odağı belirlemek ve yaklaşan sprint için çalışmak üzere bir anlaşma içerir. Planlama toplantısını 4 saat veya daha kısa sürede sınırlayın.

Toplantının ilk bölümünde, ürün sahibi sprint'e dahil edilebilecek kullanıcı hikayelerini ele alır, bilgileri paylaşır ve soruları yanıtlar. Bu konuşmalar veri kaynakları, kullanıcı arabirimi düzeni, yanıt süresi beklentileri ve güvenlik veya kullanılabilirlik konuları gibi ayrıntıları ortaya koyabilir. Bu ayrıntıları iş listesi öğesi formunda kaydedin. Toplantının bu bölümünde, ekibin ne oluşturması gerektiği açıklanır.

Planladıkça bekleme listenize eklenmesi gereken diğer gereksinimleri keşfedebilirsiniz. Backlog'u iyi tanımlı ve öncelik sırasına göre düzenli tutun. Sprint hedefi belirlemek, ekibin her sprint için en önemli şeylere odaklanmasını sağlar.

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

Daha fazla bilgi için bakınız:

Sprint hedeflerini ayarlama

Scrum ekipleri sprint etkinliklerine odaklanmak için sprint hedeflerini kullanır. Bu hedefi genellikle sprint planlama toplantısı sırasında ayarlar. Hedef, sprint'in sonuna kadar ekibin gerçekleştirmek istediği şeyi özetler. Hedefi açıkça belirterek, ekip içinde paylaşılan bir anlayış oluşturur ve önceliklerle ilgili çakışmalar ortaya çıktığında kararlara yol göstermesine yardımcı olursunuz.

Siperlerden ipuçları: Sprint hedeflerini belirlemek

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, ilgisiz kapsam öğelerinin rastgele seçilmesi değil, ekibin gerçekleştirmesi gerekenleri yakalayan kısa bir ifadedir. Normalde ürün sahibi, sonraki sprint için öğeleri seçmeden önce sprint hedefini tanımlar. 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, önerilen çözümün çalıştığını kanıtlamak için basit bir kullanıcı hikayesine odaklanır.
  • Bu sprint, web sitesinin yönetim bölümünü düzgün bir şekilde güvenli hale getiren güvenlik özellikleri uygular.
  • Bu sprint, ekibin ödeme toplamaya başlayabilmesi için en önemli ödeme ağ geçitlerini tümleştirir.

Sprint hedeflerinin ayarlanması, ekibin odaklanmış kalmasına yardımcı olur, sprint içindeki görevlerin önceliğini belirlemeyi kolaylaştırır ve ilgili paydaşların sayısını sınırlar.

Sprint gözden geçirmesi sırasında en önemli soru sprint hedefine ulaşıp ulaşmadığınızdır. Kaç hikaye tamamladığınız ikinci gelir. Amaç gerçekleştirildiğinde, tüm hikayeler tamamlanmamış olsa bile sprint başarılı sayılır.

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

Hataların düzeltilmesi, diğer çalışmalarla bir dengeyi temsil eder. Her hatanın proje kapsamı, bütçe ve zamanlamayla 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 ile önem derecesini atamayı değerlendirmek için ölçütler oluşturun. Yüksek değerli özelliklerle (veya gecikme fırsat maliyetiyle) veya diğer proje riskleriyle ilişkili hatalara daha yüksek öncelik ve ciddiyet verilmelidir. Ö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.
  • Geliştirme döngünüzdeki yeriniz temelinde ölçütleri ayarlayın. Başlangıçta, önceliklendirme yaptığınız hataların çoğunu düzeltebilirsiniz. Döngünün ilerleyen bölümlerinde düzelttiğiniz hata sayısını azaltmak için çıtayı yükseltin.
  • Bir hatayı önceliklendirmeden sonra, bir düzeltmeyi araştırmak ve uygulamak için bir geliştiriciye atayın.

Teknik borcunuzu yönetin

Ekibinizin sürekli iyileştirme etkinlikleri kapsamında hata çubuğunuzu ve teknik borcunuzu yönetin. Aşağıdaki kaynaklar yararlı yönergeler sunar:

Sahadan ipuçları: Bug yönetimi

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

Bilinen hata borçlarını her sprintte ele alın.

Ekip, her sprint'te hata kapsamı içinde kalan hataları inceler ve bilinen değeri sıfıra veya sıfıra yakın bir değere ayarlamak için kapasiteyi ayırır. Bu süreç bir gün, bir hafta veya tüm sprint sürebilir fark etmeksizin, ekip öncelikle hataları düzeltir. Sprint sırasında sonradan tespit edilen hatalar ilk taahhüde dahil değildir. Yüksek öncelikli olmadıkları sürece, bir sonraki sprint için hata birikimine eklenirler.

Birçok ekip, yönetimin ekibin taahhütleri yerine getirme becerisini değerli bulduğu taahhüt odaklı kuruluşlarda çalışmaktadır. Bilinen bir hata kümesine karşı kapasite planlaması sprint planlamasını daha belirleyici hale getirir ve taahhütleri karşılama şansını artırır. Sprint sırasında bulunan yeni hatalar ilk taahhüdün bir parçası değildir ve sonraki sprint'e giderilebilir.

Kuruluş genelinde hata borcunu yönetme

Borcu sürekli ortadan kaldırdıkları bir kültüre geçiş yapılan kuruluşlar genellikle şu soruyla karşı karşıya kalır: Ekiplere tam olarak ne yapacaklarını söylemeden hata sayısını nasıl azalttırabilirsiniz? Liderlik ekibin değişmesini istiyor, ancak nasıl yapılacağını belirlemek için takıma özerklik sağlıyor. 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. 10 kişilik bir ekibin hata kapsamı 30'dan fazla hataya sahip olmamalıdır. Ekip sınırını aşarsa, üst sınırın altına inene kadar yeni özellikler üzerinde çalışmayı durdurur. Ekibin her zaman üst sınırın altında kalması beklenir, ancak bunu nasıl yapacağına karar verir. Hata sınırı, ekiplerin hata borcunu çok uzun süre taşımamasını ve ilk etapta hatalara neden olan hatalardan ders çıkarmasını sağlar.

Hata sınırı yalnızca hata birikim listesindeki hataları kapsar. Bir özelliğin geliştirildiği sprint içinde bulunan ve düzeltilen hatalar borç değil, geri alınan iş olarak kabul edilir.

Hatalar teknik borçlara katkıda bulunurken, tüm borcu temsil etmezler. Kötü yazılım tasarımı, kötü yazılmış kod veya kısa vadeli düzeltmeler teknik borçlara da katkıda bulunur. Bu sorunlardan kaynaklanan ek geliştirme çalışmaları.

Teknik borcu çözmek için çalışmayı, Ürün Backlog Öğeleri (PBI'ler), kullanıcı hikayeleri veya hatalar olarak izleyin. Tahakkuk eden ve teknik borcun giderilmesindeki ilerlemeyi izlemek için, iş öğesini ve izlemek istediğiniz ayrıntıları kategorilere ayırmayı göz önünde bulundurun. İ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şturur ve bakımını yapar. Scrum takımlarına Scrum yöntemlerinin doğru kullanımı konusunda yol gösterir, koçluk eder, öğretir ve yardımcı olurlar. Scrum Masters, ekiplerin engelleri aşmasına ve önemli üretkenlik artışlarını artırmasına 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 benimseme ve takip etme konusunda ekibi destekleyin. Örneğin, günlük Scrum toplantısının 45 dakika süren açık bir tartışma olmasına izin vermeyin.
  • Sprint başladıktan sonra ürün sahibi veya ekip üyelerinin iş eklemesine karşı önlem alın.
  • İleriye dönük ilerlemeyi engelleyen engelleme sorunlarını temizleyin. Bu çalışma için yeni bir bilgisayar kurulumunu onaylama veya ekip içindeki bir anlaşmazlığı çözme gibi küçük görevlerin tamamlanması gerekebilir.
  • Ekibin ortaya çıkan çakışmaları ve sorunları çözmesine yardımcı olun ve süreçten ders alın.
  • Gizli sorunları ortaya çıkaran sorular sorun ve iletişimin tüm ekip tarafından doğru bir şekilde anlaşıldığını onaylayın.
  • Olası sorunları büyük sorunlar haline gelmeden önce belirleyin ve çözün. Küçük ve yönetilebilir bir ekip sorununu çözmek 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 göstermek için verileri toplayın, analiz edin ve iş paydaşlarına sunun. Örneğin, ekibiniz daha az hata oluştururken ortaya çıkardığı değeri artırdıysa, bu iyileştirmeyi düzenli iletişimler aracılığıyla görünür hale getirin.

İyi Scrum Master'ları mükemmel iletişim, müzakere ve çakışma çözümü becerileri geliştirir. İnsanların söylediği ve yazdığı sözcüklerin yanı sıra vücut dili, yüz ifadeleri, ses hızı ve diğer saldırgan olmayan iletişim gibi mesajları nasıl teslim ettiklerini etkin bir şekilde dinlerler.

Günlük Scrum toplantıları

Günlük Scrum toplantıları, bir ekibin bundan sonra yapması gerekenlere odaklanmasına yardımcı olur. Scrum Yöneticisi, toplantının yapısını zorlar ve zamanında başlamasını ve 15 dakika veya daha kısa sürede bitmesini sağlar.

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

  • Herkes ayağa kalksın. Ayakta kalma, toplantının odaklanmış ve kısa tutulmasına yardımcı olur.
  • Toplantı her gün aynı saatte ve konumda başlar ve biter.
  • 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'da neleri başaracağım?
    • Hangi engelleyici sorunlar veya engeller çalışmamı etkileyebilir?

Uyarı

Scrum toplantılarının odak noktası, bir ekip üyesinden diğerine geçmesi gereken çalışmanın durumudur.

Ekip üyeleri sorularını hızlı ve kısa bir şekilde yanıtlar. İyi yanıtlar, hangi işlerin tamamlandığını, hangilerinin planlandığını ve engellerin kaldırılması için herhangi bir yardıma ihtiyaç olup olmadığını belirtir. "Sınıfta çalıştım" gibi belirsiz yanıtlardan kaçının; hangi iş öğesini ve nelerin kaldığını belirtin.

Rapor çıkışları sırasında kimse kesintiye uğraymıyor. Toplantı sonrası için ayrıntılı tartışmaları kaydedin. Birçok ekip bir "park yeri" kullanır; izleme gerektiren konuların toplantı sırasında listelendiği ve daha sonra ele alındığı bir beyaz tahta veya flipchart.

Sprint gözden geçirme toplantıları

Sprint'in son gününde sprint gözden geçirme toplantıları gerçekleştirin. Ekibiniz sprint'te tamamlanan 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 istedikleri değişiklikleri belirleyebilir.

Bu toplantıyı temel alarak bazı kullanıcı hikayelerini tamamlanmış olarak kabul edin. Ürün bekleme listesinde eksik kullanıcı hikayelerini bulundurun ve yeni kullanıcı hikayeleri ekleyin. Bir sonraki sprint planlama toplantısında her iki hikaye kümesini de sıralayıp tahmin edin veya yeniden tahmin edin.

Bu toplantıdan ve geçmişe dönük değerlendirmeden sonra takımınız bir sonraki sprint'i planlıyor. İş gereksinimleri hızla değiştiğinden, ürün sahibi, müşteriler ve paydaşlarla ürün kapsamı önceliklerini gözden geçirmek için bu toplantıyı kullanın.

Sprint değerlendirme toplantısı

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 geriye dönük değerlendirmesi 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 değiştirilmesi gerekebileceğini keşfedecek.

Tartışmalara bağlı olarak, ekibiniz etkinliği, üretkenliği, kaliteyi ve memnuniyeti 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.

Uyarı

Ekibinizin geçmişe dönük değerlendirmesini desteklemek için Market Retrospektifler uzantısını yüklemeyi göz önünde bulundurun. Bu uzantı proje kilometre taşları hakkında geri bildirim toplamaya, geri bildirimleri düzenlemeye ve önceliklendirmeye ve ekibinizin zaman içinde geliştirmesine yardımcı olmak için eyleme dönüştürülebilir görevler oluşturmaya yardımcı olur.

Sprint geriye dönük değerlendirmeleri sırasında şu alanları ele alın:

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

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

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

    Örneğin, 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. Bu ekip üyesi, diğer üyeler yardımcı olamadığında fazladan saatler çalıştı. Bundan sonra ekip, zaman içinde bu sorunu düzeltmeye yardımcı olmak için eXtreme Programlama uygulamaya karar verdi.

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

Ekibinizin bir iyileştirme uygulamak için de çalışma yapması gerekebilir. Örneğin, çok fazla başarısız derlemeden olumsuz etkilenen bir ekip Continuous Integration uygulamaya karar verdi. Üretimde açmadan önce bir deneme sürümü ayarlar. Bu çalışmayı temsil etmek için bir ani artış oluşturdular ve bunu ürün kapsamına göre düzenlediler.

İlgili içerik

  • Last updated on