Scrum ile Çalışmak

Kullanıcı hikayesi

Kullanıcı hikayeleri, geliştirilmekte olan yazılımların gereksinimlerini belirtmenin etkili bir yoludur. Bu tür hikayeler, yazılımın kullanıcısı adına kısa tavsiyeler içerir.

Scrum metodolojisinde hedef belirlemek genellikle müşterinin veya yazılım sahibinin ayrıcalığı olduğundan, geliştirme sürecini etkilemenin ana yolu olarak kabul edilirler. Her Kullanıcı Öyküsünün metin miktarında ve sunumun karmaşıklığında bir sınırlaması vardır. Tarih, çoğunlukla, kendi içinde hacmi sınırlayan küçük bir sayfaya yazılır.

Kullanıcı hikayeleri sayesinde müşterinin isteklerini belgeleyebilir ve pazar taleplerine hızlı bir şekilde cevap verebilirsiniz.

Kullanıcı Öyküsü, bir kabul testi prosedürü içermediğinden gereksinimlerin basitleştirilmiş bir ölçüsü olarak düşünülmelidir. Kullanıcı hikayesinin derlenmesi, kabul prosedürüne uygun olmalıdır. Bu, Kullanıcı Hikayesinin amacına ulaşmasını sağlayacaktır.

Öykü yapısı şuna benzer: "Bir <kullanıcı türü> kullanıcısı olarak, <sonuç> almak için <eylem> gerçekleştirmek istiyorum" (Bir ürün sahibi olarak istiyorum...). Böyle bir yapı sadece basit değil, aynı zamanda herkes tarafından anlaşılabilir.

Kullanıcı Hikayelerini kullanmanın faydaları:

• Hikayeler küçüktür ve oluşturulması kolaydır.
• Tüm paydaşların proje ve desteği üzerindeki çalışmaları tartışmasına yardımcı olun.
• Sürekli bakım gerektirmez.
• Yalnızca kullanıldığında geçerlidir.
• Müşteri ile etkileşimi geliştirin.
• Onlar sayesinde projeyi küçük aşamalara ayırabilirsiniz.
• Eksik anlaşılan gereksinimlere sahip projeler üzerinde çalışmayı kolaylaştırın.
• Görev değerlendirmesini basitleştirin.

Kullanıcı Hikayelerinin Dezavantajları:

• Önceden anlaşma olmadan, prosedürler bir anlaşma için temel olarak kullanılmasını zorlaştırabilir.
• Kullanımları, tüm proje boyunca müşteri ile yakın temas gerektirir ve bu da bazen iş akışını zorlaştırır.
• Büyük projelerde ölçeklendirme yaparken dezavantajları vardır.
• Doğrudan geliştiricilerin profesyonel düzeyiyle ilgilidir.
• Bir tartışma başlatmak için kullanılır, ancak bir tartışmayı bitirmeyebilir ve sistem dokümantasyonu için kullanılmaz.

birikmiş iş

Ürün biriktirme listesi, öncelik sırasına göre derlenmiş bir liste biçimindeki mevcut görevlerdir. Liste, projenin yol haritası (yol haritası) ve burada belirtilen noktalar temelinde oluşturulur. En önemli görevler genellikle listenin başında yer alır. Bu, hangi işin önce yapılması gerektiğini anlamak için gereklidir.

Geliştirme ekibi, birikmiş işleri tamamlama hızını müşterinin isteklerine bakılmaksızın, ancak niteliklerine ve geçmiş sprintlerden edindikleri deneyime göre seçer. Programcıları "ayarlamak" son derece istenmeyen bir durumdur. Ekibin kendisi, kendi düşüncelerine ve yeteneklerine göre birikmiş iş listesinden görevler seçer. Yürütme, kesinti (Kanban) veya birkaç yineleme (Scrum) olmadan gerçekleşir.

İki önemli biriktirme durumu

Bir ürün biriktirme listesinin özü, bir yol haritası, teklifler ve yürütme koşullarından oluşur. Destanlar, koşulları ve Kullanıcı Hikayesini içerir. Tipik bir yol haritası örneğine yakından bakalım.

“Teams in Space” web sitesinin oluşturulması, yol haritasındaki ilk öneridir. Destanlara (şekilde yeşil, mavi ve turkuaz renklerle gösterilmiştir) ve her destan için bir Kullanıcı Hikayesine bölünmesi gerekir .

Yazılım müşterisi, birkaç Kullanıcı Hikayesinden bir liste oluşturur. Gerekirse, geliştiricilerin önce en önemli destanlardan biriyle (solda) ilgilenmesi veya indirimli bilet rezervasyonunun nasıl çalıştığını kontrol etmesi için hikayelerin yürütülme sırasını değiştirebilir. Bunu yapmak için destanlardan hikayeler uygulamanız gerekir (sağda). Her iki seçenek de aşağıda görülebilir.

Müşteri hangi faktörlere göre öncelik vermeli?

• Kullanıcılarla alaka düzeyi.
• Geri bildirimin varlığı.
• Geliştirmenin karmaşıklığı.
• Görevler arasındaki ilişki ("B"yi tamamlamak için önce "A" yapmanız gerekir).

Çalışmadaki öncelikler müşteri tarafından belirlenir ancak diğer taraflar bu konuda görüş bildirebilir. İş listesinin başarısı, diğer şeylerin yanı sıra müşterilerin ve programcıların görüşlerine bağlıdır. Birlikte daha iyi sonuçlar elde edebilir ve bitmiş ürünün zamanında teslim edilmesini sağlayabilirler.

Birikmiş iş listesi nasıl tutulur?

Biriktirme listesi zaten oluşturulmuşsa, bundan sonra, daha sonraki çalışmalar sırasında periyodik olarak değiştirmeniz gerekir. Yazılım müşterisi, her yeni yineleme planlamasından önce biriktirme listesinin uygun şekilde derlendiğinden emin olmalıdır. Bu, son yinelemenin analizinden sonra öncelikleri netleştirmeye veya bir şeyleri değiştirmeye yardımcı olacaktır. Çevik'te birikmiş iş listesini ayarlamak bazen "düzenleme" veya "iyileştirme" veya "bekleme listesi bakımı" olarak adlandırılır.

Biriktirme listesi zaten nispeten büyükse, müşterinin görevleri kısa vadeli ve uzun vadeli yürütmeye göre gruplandırması gerekir. Kısa süreli görevler bu statüye getirilmeden önce dikkatle incelenmelidir. Bir Kullanıcı Hikayesi oluşturmanız, ekip içindeki tüm nüansları öğrenmeniz gerekecek.

Uzun vadeli görevlere gelince, geliştiricilerin onlara değerlendirmelerini vermeleri çok arzu edilir. Bu, önceliklendirmeyi kolaylaştıracaktır. Belki bir şeyler değişecektir, ancak ekip görevleri daha iyi anlayacak ve işi daha hızlı bitirecektir.

Biriktirme listesi, müşteri ile programlama ekibi arasında önemli bir bileşendir. Müşteri, müşteri geri bildirimlerine, tahminlerine veya yeni gereksinimlere göre öncelikleri her zaman değiştirebilir.

Çalışma sırasında doğrudan değişiklik yapmaktan kaçınılması önerilir. Bunun iş akışı ve programcıların duygusal durumu üzerinde kötü bir etkisi vardır.

Sprint

Sprint, önceden kararlaştırılan miktarda işin tamamlanması gereken kısa bir dönemdir. Sprintler, Scrum ve Agile metodolojilerine dayalıdır. Doğru sprintleri seçmek, çevik bir ekibin kaliteli yazılımlar geliştirmesine yardımcı olur.

"Scrum'u kullanarak, belirli bir süreye sahip birkaç yinelemede bir ürün geliştirebilirsiniz - sprintler. Atlassian'da Jira Lideri Megan Cook, büyük projeleri daha küçük görevlere ayırmaya yardımcı oluyor" diyor.

Scrum sprintleri nasıl planlar ve yürütür?

Scrum metodolojisinin yazarlarına göre, gelecekteki sprint'i planlamak için herkesin ayrı bir toplantıda buluşması gerekiyor. Bu etkinlikte ekip üyeleri iki ana soruya yanıt bulmalıdır: Bu sprintte ne yapılmalı ve bunu en iyi nasıl yapmalı?

Yazılım müşterisi, Scrum ustası ve programcılar, iş görevleri listesinin belirlenmesine dahil olurlar. Müşteri, sprintin hedefini ve birikmiş iş listesindeki görevleri açıklar.

Daha sonra ekip, sprintteki görevlerin tamamlanacağına göre bir plan geliştirir. Seçilen iş öğeleriyle birlikte bu plana sprint iş listesi denir. Planlama toplantısından sonra ekip çalışmaya başlar. Geliştiriciler bekleyen iş listesinden görevleri seçer, iş tamamlandığında her görevin durumu "Devam Ediyor"dan "Bitti"ye değişir.

Sprint sırasında ekip, güncel sorunları ve ilerlemeyi tartışmak için günlük Scrum toplantıları (stand-up'lar) düzenler. Sprintin tamamlanmasını etkileyebilecek zorlukları belirlemek için bu tür toplantılara ihtiyaç vardır.

Sprint tamamlanırsa, takım çalışmalarının sonuçlarını sonuçların gözden geçirilmesinde gösterir (demo). Projenin her katılımcısı sonuçlarla tanışabilir. Bitmiş kod üretim ortamında birleştirilmeden önce alıştırma yapılmalıdır.

Retrospektif, sprint döngüsünü tamamlar. Üzerinde ekip, gelecekteki bir sprintte iyileştirilmesi gereken alanları tanımlar.

Nelere dikkat edilmeli ve ne yapılmamalı

Çoğu genç takım, iş akışlarına ilk kez sprintleri dahil etmekte zorlanırlar. Sorunlardan kaçınmak için öncelikli ilgi gerektiren eylemlerin listesini gözden geçirmenizi öneririz.

Ne yapmalıyız:

• Takımın sprintin amacını ve nasıl başarılı olacağını anladığını kontrol edin. Bu, herkesin birlikte başarılı bir sonuca doğru ilerlemesi için gereklidir.
• Açık ve anlaşılır bir birikime sahip olmalısınız. Biriktirme listesi doğru bir şekilde korunmadıysa bu, iş akışına zarar verebilecek bir sorun haline gelebilir.
• Yaz tatillerini ve diğer faktörleri göz önünde bulundurarak çalışma hızı tahmininizin doğru olduğundan emin olun.
• Sprint planlamasına aktif olarak katılın. Ekip üyelerini öyküler, hatalar ve ödevler için planı genişletmeye teşvik edin.
• Geliştiricilerin bağımlılık sorunlarını çözemeyeceği görevleri reddedin.
• Plan onaylandıktan sonra, proje yönetim programına (Jira kartları vb.) veri girmekten sorumlu olacak bir çalışan atayın.

Kaçınılması gerekenler:

• Çok sayıda hikayeyi aşırı kullanmayın, işin hızını ölçülü bir şekilde değerlendirin ve bir sprintte tamamlanması zor olacak görevleri vermeyin.
• İşinizin kalitesine dikkat edin. Kalite kontrol ve koddaki hataları düzeltmek için yeterli zamanınız olup olmadığını kontrol edin.
• Tüm ekip üyelerinin sprintin içeriğini açıkça anladığından emin olun. Hız peşinde koşmayın. Tüm ekip birlikte hareket etmelidir.
• Geliştiricilere fazladan iş yüklemeyin. Yakında başka bir sprint geliyor.
• Ekip, iş yükü veya son teslim tarihi hakkında endişelerini dile getirirse, onların görüşlerini dikkate almalısınız. Sorunlarla ilgilenin ve gerekirse düzeltin.

saldırı tahtası

Scrum Panosu, Scrum Takımının işlerinin nasıl yapıldığını gösteren bir araçtır. Böyle bir panodaki bilgileri kağıt üzerinde, duvarda veya elektronik biçimde (JIRA, Trello) görüntüleyebilirsiniz.

Bir Scrum panosunun en az üç sütunu vardır: Yapılacaklar, Devam Ediyor ve Bitti. İşte örnek bir tahta:

Scrum panosu, önceden planlama için onaylanan iş listesindeki tüm bilgileri içerir. Kural olarak, kartvizit kartları panoya yukarıdan aşağıya doğru öncelik sırasına göre sabitlenir. Bunları belirli çalışma türlerine ayırabilirsiniz (kod, tasarım ve diğerleri üzerinde çalışma).

İşin bir kısmı tamamlandıktan sonra, kart pano boyunca bir sonraki sütuna taşınır. Ekibin çalışmasındaki ilerlemenin görünürlüğünü göstermek için, Burndown Grafiğindeki "kalan çalışma" gün bazında yardımcı olur.

Bir flipchart tahtası da kullanabilirsiniz. Üzerine kağıt etiketler üzerine eserlerin isimleri yazılır ve panoya yapıştırılır. İş biter bitmez çıkartmalar başka bir sütuna taşınır.

açılış tablosu

Burndown tablosu, yapılan iş miktarını ve kalan iş miktarını gösterir. Her gün güncellenir ve ilgili tüm tarafların kullanımına sunulur. Sprint üzerindeki çalışmadaki ilerlemeyi göstermek için grafik gereklidir.

İki tür çizelge vardır:

• Bir sprintte işin ilerleyişini gösteren tükenmişlik tablosu.
• Ürünün piyasaya sürülmesine kadar işin ilerleyişini gösteren tükenmişlik tablosu (veriler birkaç sprintten özetlenmiştir).

Grafik örneği:

Bu örnekte psikoloji kullanılmıştır: grafik, tamamlanan görevlerin sayısını değil, kalan (yapılmayan) görevlerin sayısını gösterir.

Yani ekip 100 görevden 90'ını yaptıysa, her şeyin hazır olduğuna dair yanlış bir his olabilir. Ne de olsa, 90'dan 100'e ilerleme gerçekten hiçbir şeyi değiştirmiyor.

Kalan görevlerin sayısını görüntülerseniz, her seferinde nasıl daha az hale geldiklerini fark edemezsiniz. Bu, bilinçaltında proje katılımcılarını hedefe daha hızlı ulaşmaya teşvik eder - tahtada bitmemiş görevler olmamalıdır.