scrum artifacts product backlog
Scrum Yapılarına Giriş:
Bu dizinin önceki makalelerinde, çevik ve farklı çevik metodolojiler . Ayrıca çeşitli metodolojilerin kendilerine göre nasıl farklı olduğunu da öğrendik.
Son eğitimimizde, Scrum'ın ayrıntılarına girdik ve burada Scrum rolleri Ürün Sahibi, Scrum Master ve scrum ekibi gibi ve bireysel sorumluluklarının neler olduğunu gördüler.
Bu eğiticide, Scrum ile devam ediyor ve farklı scrum yapılarıyla ilgili ayrıntılara giriyoruz.
Ne öğreneceksin:
Farklı Scrum Eserleri
3 tür saldırı eseri şunları içerir:
- Ürün biriktirme listesi
- Sprint iş yığını ve
- Ürün artışları
Şimdi bu terimlerin ne anlama geldiğini ve bu eserlerin nasıl yaratılacağını göreceğiz.
Ürün İş Listesi
Basit bir ifadeyle, bir ürün biriktirme listesi, üründe gerekli olan tüm şeylerin bir listesidir. Bu, ürünle ilgili her şey için scrum ekibi tarafından başvurulacak son belgedir. Ürün Sahibi'ne (PO) ait olan öğelerin sıralı bir listesidir.
PO, bu listenin oluşturulması, sürdürülmesi ve önceliklendirilmesinden sorumludur. PO'lar, sprint sırasında yapılması gereken en önemli gereksinimleri scrum takımlarına açıklamak için bu ürün iş yığınını kullanır.
Bu listedeki öğeler teknik bir dilde olabilir veya olmayabilir. Bir meslekten olmayan kişinin dili bile olabilir, ancak tüm ürün gereksinimlerini ve beraberindeki değişiklikleri içermelidir. Ayrıca, bir ürün birikimine sahip olmak, scrum ekibinin yalnızca bu eseri takip edeceği anlamına gelmez.
Kendi ayrıntılı yapılarını oluşturabilirler ancak bunlar ürün birikimiyle çelişmez veya onların yerini almaz. Daha ziyade, ürün biriktirme gereksinimleriyle uyumlu olacaklardır.
Aşağıda, tipik bir ürün birikiminin nasıl görünebileceğine dair bir Örnek verilmiştir:
| Hikaye | Tahmin | Öncelik |
|---|---|---|
| Giriş yapmak istiyorum | 4 | 1 |
| Çıkış yapmak istiyorum | iki | iki |
| Şifreyi değiştirmek istiyorum | 1 | 3 |
| Adresi güncellemek istiyorum | 3 | 4 |
| Yeni bir ev telefonu numarası eklemek istiyorum | 1 | 5 |
Bu bizi soruya getiriyor iyi bir ürün birikimi nasıl oluşturulur?
Bir ürün biriktirme listesi ideal olarak aşağıdaki kuralları izlemelidir:
(i) Önceliklendirilmelidir - Ürün birikimindeki öğeler, önceliklerine göre sıralanmalıdır. Bu önceliğe PO ve scrum ekibi birlikte karar verebilir. Önceliklendirme faktörleri, hikaye noktasından, yaratma sürecindeki çabadan, karmaşıklıktan, müşteri önceliğinden vb. Herhangi bir fayda olabilir.
Ekibin önce neyin teslim edilmesi gerektiğini anlamasına yardımcı olur.
(ii) Tahmin edilmeli - Hikayeler, her ne olursa olsun, her zaman üzerinde anlaşılan tanıma göre tahmin edilmelidir. Bu, önceliklendirme için de kullanılabilir.
(iii) Yüksek seviye olmalı - Ürün birikimindeki hikayeler üst düzeydir ve ayrıntılara girmemelidir. Gereksinime göre ayrıntılı kullanıcı hikayelerinin oluşturulması, PO'ya değil scrum ekibine bağlıdır.
(iv) Dinamik olmalı - Ürün birikimi nihai bir statik belge değildir. PO, scrum ekibinden girdi aldıkça ve müşteri gereksinimleri gittikçe daha net hale geldikçe yeniden gözden geçirilmelidir. Bu nedenle, belge gereksinimleri başlangıçta dondurulmamaktadır çünkü proje ilerledikçe beklenen eklemeler / silmeler / değişiklikler vardır.
Son nokta, en alakalı olanıdır. Bir ürün birikiminin amacı, etkin bir gereksinim kaynağı olmaktır. Başlangıçta oluşturulmamalı ve daha sonra bir depolama konumunda tutulmamalıdır.
Bunun yerine, değişiklikler gelmeye devam ettikçe tekrar tekrar paylaşılması amaçlanıyor. İlerleme kaydedildikçe yeni gereksinimler ortaya çıkabilir ve bu da biriktirme listesi öğelerinin önceliğini değiştirebilir. Yeni bir gereksinimin, biriktirme listesindeki başka bir maddeye bağlı olduğu durumlar olacaktır, bu nedenle öğe önceliğinin yeniden karıştırılması gerekebilir.
Veya PO ve scrum ekibi tarafından karar verilen faktörlere göre öncelik yüksek olmasa da müşteri bunu diğerlerinden önce görmek istediği için önce uygulanması gerekebilecek kritik bir kullanıcı hikayesi olabilir.
Bu nedenle, ürün birikimi, PO'nun sahip olduğu iş gereksinimlerinin sıralı bir listesidir ve proje ilerledikçe defalarca ziyaret edilir.
Sprint İş Listesi
Scrum takımlarının sprint adı verilen 2 ila 4 haftalık kısa yinelemeler halinde çalıştığını hatırlayabilirsiniz. Bu sprintler sırasında, scrum ekibi, bir sonraki yinelemenin bir parçası olarak teslim etmeyi planladıkları PO tarafından oluşturulan ürün birikiminden öğeleri tanımlar. Scrum ekibinin üzerinde çalışmayı seçtiği öğeler, sprint iş yığını'nın bir parçası haline gelir.
Böylece, ürünün bir sonraki yinelemesinde hangi işlevlerin orada olacağına karar verirler. Scrum ekibi, sprint iş yığınına neyin gireceğine karar veren kişidir, çünkü üzerinde çalışacak olanlar onlardır.
Bu nedenle, bu hikayelerin uygulanmasında ve ne kadarını sunabileceklerine karar vermede harcanan çabayı tahmin etmesi gerekenler onlardır.
Ekip, üzerinde çalışmak için yalnızca ürün iş yığınındaki öğeleri seçmekle kalmaz, aynı zamanda bu işlevselliği geliştirmeleri için ne kadar zaman alacağına dair bir tahmin de yapar. Ayrıca, sprint hedefine ulaşmak için gereken ayrıntılı görevleri oluşturarak üst düzey kullanıcı hikayelerine katkıda bulunurlar.
qa testi lideri mülakat soruları ve cevapları
Scrum ekibi, sprint sırasında gerektiğinde ve gerektiğinde sprint iş yığınını güncellemeye devam edebilir, ancak sprint iş yığınında değişiklik yapabilecek olan yalnızca scrum ekibidir.
Tipik bir Sprint İş Listesi aşağıda gösterildiği gibi görünecektir.
Ekip ideal olarak bunu günde bir kez güncelleyebilir ve saldırı ustası bu bilgiyi bir sprint kapanma tablosu oluşturmak için kullanabilir. Bu burndown şeması, takımın sprint için hala ne kadar iş kaldığını görmesine ve takımın çalışmalarını buna göre planlamasına yardımcı olacak. Hatta gerekirse görev ekleyebilir veya kaldırabilirler.
Bir sprint iş yığını oluştururken bazı en iyi uygulamalar şunlar olabilir:
# 1) Grup kararları verin - İş yığınına karar veren scrum ustası veya başka bir scrum ekibi üyesi olmamalıdır. Aksine, sprint iş yığınına hangi öğelerin dahil edileceğine ve bunlar için nasıl plan yapılacağına birlikte karar veren tüm ekip olmalıdır.
Bu çapraz işlevli ekibin her üyesi kendi becerilerini ortaya çıkarır ve mümkün olan en iyi birikimi oluşturmak için onların deneyimlerini kullanmamız çok önemlidir.
# 2) Görev atamayın - Agile literatüründe defalarca tekrarlandığı için ekip üyelerine asla görev atamayın. Bir saldırı ekibinin kendi kendine yeterli olması gerekir ve çalışmalarını kendi başlarına nasıl organize edeceklerini bilmeleri gerekir.
Bu nedenle, işi atamak yerine, ekibin kendileri için iş seçmesine ve nasıl ilerlemek istediklerine kendi aralarında karar vermelerine izin vermeliyiz.
# 3) Bitti'nin tanımı - Sadece paydaşlar tarafından üzerinde anlaşmaya varılmamalı, aynı zamanda sprint hedefleri ile ilgili herhangi bir karar almaları gerektiğinde her noktada ekibe açıkça görünür hale getirilmelidir. Bu, çalışan bir gönderilebilir ürünü teslim etmeden önce tam olarak ne yapılması gerektiğini hatırlatacak.
# 4) İş yığınını güncellemeye devam edin - Sprint geliştikçe takımın daha iyi bir anlayış kazanması ve dolayısıyla bu daha büyük anlayışı yansıtmak için sprint iş yığınını buna göre güncellemeleri zorunludur. Hiçbir zaman statik bir belge haline gelmemelidir.
# 5) Herhangi bir görev ekleyin - Görevin yalnızca kodlamayla ilgili olması gerekmez, aynı zamanda sevk edilebilir bir ürün teslim etmek de gerekli olabilir. Bu nedenle, iş yığınında da bu tür görevlerden bahsedin.
Ürün Artışları
Bu bizi ürün artışları olan son scrum yapısına getiriyor. Scrum kılavuzunda tanımlandığı gibi, bir Ürün Parçası tüm Ürün İş Listesi öğeleri sırasında tamamlandı Sprint ve önceki tüm Sprintlerin artışlarının değeri. Şimdiye kadar iyi bildiğimiz gibi, Scrum yinelemeli bir süreçtir.
Her yinelemenin sonucu, bu ürün artışıdır ve bu tür her ürün artışı, ekibin son ürünü sunmaya doğru bir adım daha yaklaşmasına yardımcı olur.
Bunun anlamı, sprintin sonucu ne olursa olsun bir artıştır. Açıktır ki, sonucun bir artış olarak kabul edilebilmesi için, önce önceden tanımlanmış yapılan tanımını karşılaması gerekir, yani nihai sonuç, 'sevkıyat yapabilen' kullanılabilir bir ürün olmalıdır.
Tanıma göre gerçekten 'yapıldığından' emin olmak için kontrol edilebilir, kullanılabilir ve test edilebilir ve Ürün Sahibi dilerse, yayınlanmak üzere de serbest bırakılabilir.
Bu ürün artışını sağlamak için en önemli şey, herkes tarafından anlaşılan ortak bir 'yapılan tanımı' anlayışına sahip olmaktır.
Scrum ekibi, yaptıklarının kabul edilip edilmeyeceğinden asla şüphe etmemelidir. Herhangi bir şüphe varsa, nasıl ilerleyecekleri konusunda onlara yol gösterecek kadar tamamlanmış tanımı yeterli olmalıdır. Scrum ekibi, yalnızca bu tanıma dayanarak, sprint için kaç ürün biriktirme listesi öğesinin seçileceğine karar verir.
Bu, sprintten beklenen minimumdur.
Sonuç
Bu eğitimden, daha kaliteli eserler yaratmamıza yardımcı olacak en iyi uygulamalardan bazılarının yanı sıra onlara sahip olan 3 scrum yapıtının ne olduğunu anladık. Bu serinin bir sonraki öğreticilerimizde, Scrum olaylarını tartışacağız ve bu olayları nasıl yürüteceğimizi göreceğiz.
Yaklaşan eğiticimizde 'Scrum Etkinlikler , 'Scrum Etkinliğinin her birini ayrıntılı olarak tartışacağız!
PREV Eğitimi | SONRAKİ Eğitici
Önerilen Kaynaklar
- Scrum Etkinlikleri: Time Boxing, Sprint Planlama, Günlük Stand-up ve Backlog İyileştirme
- Scrum Takım Rolleri ve Sorumlulukları: Scrum Master ve Ürün Sahibi
- JIRA Scrum Board Eğitimi: Sprint'i Yönetmek İçin Jira ile Scrum Kullanımı
- Çevik Scrum Çevrimiçi Testi: Çevik Scrum Bilginizi Test Edin
- SCRUM'da İş Analistlerinin Rolü ve QA Bu Rol için Neden En İyisidir?
- Scrum'da Hata Triaging: Bir Scrum Kurulumunda Nasıl Düzenlenir
- Web ve ürün uygulamaları için örnek hata raporları
- 2021 Yılında Ürün Yaşam Döngünüzü Yönetmek İçin En İyi 9 PLM Yazılımı