agile methodology beginner s guide agile method
Çevik Metodoloji için Eksiksiz Bir Kılavuz: (20'den Fazla Ayrıntılı Çevik Scrum Metodolojisi Öğreticisi)
Bu, yazılım geliştiricilerinin ve test uzmanlarının çok ünlü olanları anlamaları ve üzerinde çalışmaya başlamaları için bir kılavuzdur. Yazılım geliştirme ve test için çevik SCRUM metodolojisi . Çevik Scrum sürecinde kullanılan temel ama önemli terminolojilerin yanı sıra tüm sürecin gerçek bir örneğini öğrenin.
Size kolaylık sağlamak için bu serideki tüm Çevik Öğreticileri listeledik. Umarım size çok yardımcı olurlar.
İşlenmiş konular: Çevik Nedir, Scrum Nedir, Yazılım Geliştirme ve Testte Çevik Metodoloji, Çevik Test, Çevik Scrum Süreci, Scrum Ekibi ve Scrum Master ile Scrum Metodolojisi.
Ne öğreneceksin:
Çevik Metodoloji Eğitimleri Listesi
Öğretici 1: Çevik Scrum Metodolojileri (Bu Eğitim)
Öğretici # 2: Çevik Manifesto
Öğretici 3: Scrum Takımı ve rolleri ve sorumlulukları
Eğitim 4: Scrum Eserleri
Öğretici 5: Scrum Etkinlikleri
Öğretici # 6: Scrum'da Hata Önceliklendirmesi
Eğitim 7: Kendi Kendine Yeterli Scrum Takımları
Eğitim # 8: Üç Amigo Prensibi
Eğitim 9: SAFe - Ölçekli çevik çerçeve
Öğretici # 10: Çevik Scrum Testi
DAHA FAZLA Önerilen Çevik Scrum Öğreticisi:
Öğretici # 11: En Çevik Tahmin Teknikleri
Eğitim # 12: Çevik Şelale Hibrit Modeli
Eğitim # 13: Kanban, Scrum, Çevik
Eğitim # 14: JIRA Çevik Eğitimi
Öğretici # 15: Çevik Retrospektif Toplantılar
Öğretici # 16: SCRUM'da İş Analistlerinin Rolü
Öğretici # 17: Scrum'da QA'nın Rolü
Araçlar ve Görüşme Soruları:
Eğitim # 18: Çevik Test Araçları
Eğitim # 19: En İyi Çevik Proje Yönetim Araçları
Eğitim 20: En Çevik Mülakat Soruları
Öğretici # 21: En İyi Scrum Mülakat Soruları
Serideki ilk öğretici ile başlayalım - Çevik Scrum Giriş.
Çevik Gelişime Giriş
Yazılım Geliştirmede Çevik:
Çevik, dünyanın en yaygın kullanılan ve tanınan yazılım geliştirme çerçevelerinden biridir.
Kuruluşların çoğu bunu bir şekilde benimsemiştir, ancak benimseme programlarının olgunlaşması için hala uzun bir yol vardır. Bu eğitim dizisinin tek amacı, teknolojiyi ve teknoloji dışı profesyonelleri Çevik Dünyaya yerleştirmektir.
Agile kullanmanın arkasındaki felsefeyi, avantajlarını ve nasıl uygulanacağını anlayana kadar sizi adım adım çevik yolculuğa çıkaracağız. Bu seri, okuyucuların Çevik ve Scrum öğrenimini çalışmalarına uygulayabilmelerini sağlamayı ve donatmayı amaçlamaktadır.
Bu özel eğitim, Agile'a neden ihtiyaç olduğunu ve nasıl yaratıldığını size açıklamaya adanmıştır. Buradaki temel, Yazılım Geliştirme Endüstrilerinde Çevik Benimseme kavramını anlamanızı sağlamaktır.
Agile Tarihi
Agile, güzel bir günde, farklı geliştirme metodolojilerine sahip 17 kişinin bir araya gelerek, daha hızlı geliştirme süresine yol açabilecek ve daha az dokümantasyon ağırlığına yol açabilecek olası bir alternatif çözüm olup olmadığını beyin fırtınası yapmak için bir araya geldiğinde doğdu.
O zamanlar, yazılım geliştirme o kadar uzun sürüyordu ki, projeler teslim edilmeye hazır olduğunda, iş ilerlemiş ve gereksinimler değişmişti. Dolayısıyla bir proje, tanımlanmış hedeflerini karşılayabilse bile iş ihtiyaçlarını karşılayamamıştır.
Böylece, farklı yazılım mühendisliği tekniklerinin bu şampiyonları bir araya geldi ve toplantılarının sonucu, bu dizinin bir sonraki dersinde ayrıntılı olarak tartışacağımız 'çevik manifesto' olarak adlandırdıkları şeydi.
Ancak o gün doğan çevik, bugün organizasyonlarda gördüğümüz şey değil. Uzmanların üzerinde anlaştığı metodoloji 'hafif' ve hızlı olarak tanımlandı. Ancak bu toplantının ana kazancı, bir ürünün daha hızlı teslimatının ve sürekli geri bildirimin, yazılım geliştirmede başarıya ulaşmanın anahtarı olduğu düşüncesiydi.
Mevcut şelale teknikleri çok külfetliydi ve nihai ürün teslim edilmeye hazır olana kadar geri bildirim için hiçbir koşul yoktu. Bu, rota düzeltmesi için bir kapsam olmadığı ve tüm ürün hazır olana kadar müşterinin ilerleme hakkında hiçbir görüşü olmadığı anlamına geliyordu. Ve bu uzmanların kaçınmak istediği şey buydu.
Daha sonraki bir aşamada yeniden çalışma maliyetinden kaçınmak için sürekli geri bildirim için kapsamı olan bir çözüm istediler.
Çevik Zorluklar
O zamanki mevcut şelale teknikleri çok külfetliydi ve nihai ürün teslim edilmeye hazır olana kadar geri bildirim için hiçbir koşul yoktu. Buna şelale geliştirme modeli deniyordu çünkü ekipler önce bir adımı tamamen tamamladılar ve ancak bundan sonra bir sonraki adıma geçtiler.
Bu, rota düzeltmesi için bir kapsam olmadığı ve tüm ürün hazır olana kadar müşterinin ilerleme hakkında hiçbir görüşü olmadığı anlamına geliyordu. Ve bu uzmanların kaçınmak istediği şey buydu. Daha sonraki bir aşamada yeniden çalışma maliyetinden kaçınmak için sürekli geri bildirim için kapsamı olan bir çözüm istediler.
İşte bu yüzden Agile, sürekli geri bildirim ve teslimat hızı kadar, uyarlanabilir ve sürekli iyileştirme ile de ilgilidir.
Çevik Sözler nelerdir?
Çevik, yalnızca yazılım geliştirmede set uygulamaları uygulamakla ilgili değildir. Ayrıca, Ekibin zihniyetinde, onları daha iyi yazılım geliştirmeye, birlikte çalışmaya ve sonunda mutlu bir Müşteri haline getirmeye yönlendiren bir değişikliği de beraberinde getirir.
Çevik değerler ve ilkeler, ekibin odak noktasını değiştirmesine ve daha iyi yazılım geliştirme düşüncesini değiştirmesine olanak tanır.
Agile Tam Olarak Nedir?
Çevik bir kurallar dizisi değildir. Çevik, bir dizi yönerge değildir. Çevik bir metodoloji bile değil. Aksine, Çevik, planlar ve süreçler üzerinde esnekliği, uyarlanabilirliği, iletişimi ve çalışma yazılımını teşvik eden bir dizi ilkedir. Çevik manifesto denen şeyde çok kısa ve öz bir şekilde ele alınmıştır.
Çevik yazılım geliştirme, ekibin karmaşık projeler geliştirmede birlikte daha verimli ve etkili bir şekilde çalışmasını sağlar. Kolaylıkla benimsenen ve harika sonuçlar veren yinelemeli ve artımlı teknikleri kullanan uygulamalardan oluşur.
Agile'ı eyleme dönüştürürken, çeşitli Çevik tabanlı yöntemlere ve metodolojilere sahibiz. Bu yöntemler ve metodolojiler, yazılım tasarımı ve mimarisi, geliştirme ve testten proje yönetimi ve teslimatlarına kadar bir yazılım geliştirme endüstrisinin tüm ihtiyaçlarını karşılar.
Sadece bu değil, Çevik yöntemler ve metodolojiler, her teslimatın ayrılmaz bir parçası olarak süreç iyileştirme için kapsam da açar.
Çevik, kendi kendine yeten ve işlevler arası bir ekibin yinelemeler yoluyla sürekli teslimat yapmaya çalıştığı ve son kullanıcılardan geri bildirim alarak süreç boyunca geliştiği bir yazılım geliştirme yaklaşımıdır.
Agile Nasıl Uygulanır?
Çeşitli endüstrilerde uygulanmakta olan çeşitli Çevik Metodolojiler vardır.
Ancak, hepsi arasında en popüler metodolojiler şunlardır:
- Scrum
- Kanban
- Aşırı Programlama
Tüm bu metodolojiler, yalın yazılım geliştirmeye odaklanır ve daha iyi yazılımı etkili ve verimli bir şekilde oluşturmaya yardımcı olur.
Hepsi bu Agile Giriş ile. Bölüm, bir ekibin Çevik modda ve zihniyette çalışması için benimsenecek temel değerleri ve ilkeleri anlamanıza yardımcı olacak şekilde yapılandırılmıştır.
Çevik Metodoloji
Çevik Modellere Giriş:
android için en iyi mp3 çalar indirici
Hepimizin bildiği gibi, Agile bir yazılım geliştirme metodolojisidir.
Agile'nin kurucularının Agile manifestosunda bahsettiği değerleri ve ilkeleri de öğrendik. İlk tartışmalarımızda, çevik ve geleneksel şelale modelleri arasındaki farkları da gözden geçirdik.
Bu eğitimde, çevik metodolojinin avantajları ve dezavantajları hakkında bilgi sahibi olacağız.
Scrum nedir göreceğiz? ve Agile'dan farkı nedir. Ardından, farklı kuruluşlar tarafından kullanılan çeşitli çevik metodolojileri ve bunları kullanarak Agile'ı nasıl uygulayabileceğimizi anlayacağız.
Ayrıca, bu metodolojilerin farkını ve avantajlarını / dezavantajlarını da takdir edebileceksiniz.
Çevik Metodolojinin Avantajları
Aşağıda, Çevik Metodolojinin çeşitli avantajları verilmiştir:
- Müşteriler, her yinelemenin / sprintin sonunda projenin ilerleyişini sürekli olarak görür ve hisseder.
- Her sprint, müşteriye, kendisinin sağladığı tanıma göre beklentilerini karşılayan çalışan bir yazılım sağlar.
- Geliştirme ekipleri, değişen gereksinimlere oldukça duyarlıdır ve geliştirmenin ileri aşamalarında bile değişiklikleri barındırabilir.
- Müşterileri dahil eden sürekli iki yönlü iletişim vardır, bu nedenle tüm paydaşlar - iş ve teknik - projenin ilerleyişini net bir şekilde görebilir.
- Ürünün tasarımı verimlidir ve iş gereksinimlerini karşılar.
Çevik Metodolojinin Dezavantajları
Çevik metodolojinin çeşitli avantajları olmasına rağmen, içinde de bazı dezavantajlar vardır.
Onlar:
# 1) Kapsamlı dokümantasyon tercih edilmez, bu da Agile ekiplerinin bunu yanlış bir şekilde yorumlamasına neden olabilir, çünkü Agile dokümantasyon gerektirmez. Böylece, belgelerde titizlik kaybolur. Devam etmek için yeterli bilgi olup olmadığını sürekli kendinize sorarak bundan kaçınılmalıdır.
#iki) Bazen projelerin başında gereksinimler çok net değildir. Ekipler ilerleyebilir ve müşterilerin vizyonunun yeniden düzenlendiğini görebilir ve bu tür durumlarda ekiplerin birçok değişikliği dahil etmesi gerekir ve nihai sonucu da ölçmek zordur.
Çevik Metodoloji Türleri
Dünya genelinde uygulamada birçok Agile metodolojisi vardır. En popüler dördü hakkında ayrıntılı olarak daha fazla bilgi edineceğiz.
# 1) Scrum
Scrum, kolaylıkla en popüler çevik çerçeve olarak düşünülebilir. 'Scrum' terimi, çoğu uygulayıcı tarafından 'Agile' ile eş anlamlı olarak kabul edilir. Ancak bu bir yanılgıdır. Scrum, Agile'ı uygulayabileceğiniz çerçevelerden sadece biridir.
Scrum kelimesi spor ragbisinden gelir. Oyuncuların birbirine kenetlenmiş bir konumda rakiplere karşı iterek bir araya toplandıkları yer. Her oyuncunun pozisyonunda tanımlanmış bir rolü vardır ve durumun talebine göre hem hücum hem de savunma oynayabilir.
Benzer şekilde, BT'deki skrum, üç özel ve açıkça tanımlanmış role sahip, kendi kendini yöneten, güçlendirilmiş geliştirme ekiplerine inanır. Bu roller şunları içerir - Ürün Sahibi (PO), Scrum Master (SM) ve programcılar ve test uzmanlarından oluşan geliştirme ekibi . Sprint adı verilen yinelemeli zaman kutulu sürelerde birlikte çalışırlar.
İlk adım, PO tarafından ürün birikiminin oluşturulmasıdır. Scrum ekibi tarafından yapılacak işlerin bir listesi. Ardından scrum ekibi en öncelikli öğeleri seçer ve bunları sprint adı verilen zaman kutusu içinde bitirmeye çalışır.
Tüm bunları hatırlamanın daha kolay bir yolu, 3-3-5 çerçevesini ezberlemektir. Bir scrum projesinin 3 rolü, 3 eseri ve 5 etkinliği olduğu anlamına gelir.
Bunlar -
Roller: PO, Scrum ustası ve geliştirme ekibi.
Eserler: Ürün İş Listesi, Sprint İş ListesiveÜrün artışı.
Etkinlikler: Sprint, Sprint planlama, Günlük Scrum, Sprint incelemesi ve Sprint retrospektifi.
Sonraki eğitimlerimizde bunların her biri hakkında daha ayrıntılı bilgi edineceğiz.
# 2) Kanban
Kanban, kart anlamına gelen Japonca bir terimdir. Bu kartlar, yazılım üzerinde yapılacak işin ayrıntılarını içerir. Amaç görselleştirmedir. Her ekip üyesi, bu görsel yardımcılar aracılığıyla yapılacak işin farkındadır.
Ekipler, sürekli teslimat için bu Kanban kartlarını kullanır. Scrum gibi, Kanban da ekiplerin etkili bir şekilde çalışmasına yardımcı olmak ve kendi kendini yöneten ve işbirliğine dayalı ekipleri desteklemek içindir.
Ancak bu ikisi arasında da farklılıklar var - bir scrum sprint sırasında olduğu gibi, bir takım tarafından üzerinde çalışılan öğeler sabittir ve sprint'e öğe ekleyemiyoruz, oysa Kanban'da, kullanılabilir kapasite varsa öğeler ekleyebiliriz. Bu, özellikle gereksinimler sık sık değiştiğinde yararlıdır.
Benzer şekilde, diğer bir fark, scrum bir PO, scrum master ve geliştirme ekiplerinin rollerini tanımlarken, Kanban'da bu tür önceden tanımlanmış roller bulunmamasıdır.
Diğer bir fark ise, scrum, ürün biriktirme listelerine öncelik verilmesini önerirken, Kanban'ın böyle bir gereksinimi yoktur ve tamamen isteğe bağlıdır. Böylece Kanban daha az organizasyon gerektirir ve değer katmayan faaliyetlerden kaçınır ve değişikliklere karşı duyarlılık gerektiren süreçler için uygundur.
# 3) Yalın
Yalın, atık azaltmaya odaklanan bir felsefedir. Bunu nasıl yapıyor?
Yalın olarak, bir süreci katma değerli faaliyetler, değer katmayan faaliyetler ve katma değer içermeyen temel faaliyetler olarak bölersiniz. Değer katmayan faaliyet olarak sınıflandırılabilecek herhangi bir faaliyet israftır ve bu israfı süreç içerisinde ortadan kaldırarak daha zayıf hale getirmeye çalışmalıyız.
Daha yalın bir süreç, daha hızlı teslimat ve ekip hedeflerine ulaşmaya yardımcı olmayan görevlerde daha az çaba harcanması anlamına gelir. Bu, yazılım geliştirme döngüsündeki her adımı optimize etmeye yardımcı olur. Yalın ilkelerin yalın üretimden yazılım geliştirmeye uyarlanmasının nedeni budur.
Yalın yazılım geliştirme, aşağıda gösterilen yedi yalın ilkeyi uygulayarak herhangi bir BT projesinde kullanılabilir:
İsimlerinden de anlaşılacağı gibi bunlar oldukça açıklayıcıdır. İsrafı ortadan kaldırmak ilk ve en önemli yalın ilkedir ve bunu nasıl yapacağımızı gördük, faaliyetleri sadece değer ve katma değer olmayan olarak sınıflandırıyoruz.
Değer katmayan bir etkinlik, kodun herhangi bir parçası olabilir, bu da onu daha az sağlam hale getirebilir, gereken çabayı artırabilir ve haklı bir iş değeri katmazken çok fazla zaman alabilir. Ayrıca belirsiz kullanıcı hikayeleri veya kötü testler veya büyük resimde gerekli olmayan özellikler eklenebilir.
Öğrenmeyi güçlendiren ikinci ilkenin anlaşılması yine kolaydır, çünkü bir takım, ürünleri hızla değişen bir ortamda hızlı sürelerle ortaya çıkan yeni teknolojilerle sunmak için çeşitli becerilere ihtiyaç duyar.
Geç kararlar vermek, yeniden çalışmayı azalttığı durumlarda, örneğin herhangi bir değişiklik olması beklenen durumlarda, daha sonra geciktirmek için ödüllendirici olabilir, böylece ekip iş ihtiyaçları değiştikçe işi yeniden yapmak zorunda kalmaz.
Ancak burada her zaman bir değiş tokuş vardır, çünkü takımlar bunu dördüncü daha hızlı teslimat ilkesiyle dengelemeye ihtiyaç duyar. Kararların geciktirilmesi, genel teslimatı etkilememeli ve işin hızını düşürmemelidir. Bir göz her zaman tam resmin üzerinde olmalıdır.
Güçlendirilmiş takımlara sahip olmak da günümüzde çok yaygındır ve bu Agile'ın bile önerdiği bir şeydir. Yetkili ekipler daha sorumludur ve kararları daha hızlı alabilir. Güçlendirilmiş bir ekipte sahiplenme duygusu daha iyi sonuçlara yol açar. Bir takımı güçlendirmek için, kendilerini organize etmelerine ve kendi başlarına kararlar almalarına izin verilmelidir.
Böylece, yalın ve çevikliğin tek bir kesin farkla pek çok ortak noktası olduğunu görüyoruz - yalın takımlar bir ürünü iyileştirmeye yardımcı olabilirken, Agile takımları aslında ürünü geliştirenlerdir.
# 4) Ekstrem Programlama (XP)
Aşırı programlama, en popüler başka bir çevik tekniktir. Extremeeprogramming.org'a göre, ilk XP projesi 6 Mart 1996'da başlatıldı. Ayrıca, XP'nin yazılım projesi geliştirmeyi 5 farklı şekilde etkilediğinden bahsediyorlar - iletişim, basitlik, geri bildirim, saygı ve cesaret. Bunlara XP'nin değerleri denir.
Bunların dışında her şey iletişimle başlar. XP ekipleri, iş ekipleri ve diğer programcılar ile düzenli olarak işbirliği yapar ve ilk günden itibaren kod oluşturmaya başlar. Buradaki odak noktası, diğer görsel yardımcıların yardımıyla mümkün olduğunca yüz yüze iletişimdir.
Aşırı programcılar ayrıca basit bir kod oluşturur ve ilk günden itibaren onun hakkında geri bildirim almaya başlar. Odak noktası aşırıya kaçmamak veya paylaşılmayan gereksinimleri tahmin etmektir. Bu, tasarımı basit tutar ve gereksinimleri karşılayacak minimum ürünü üretir.
Geri bildirim, ekibin daha kaliteli bir iş geliştirmesine ve üretmesine yardımcı olur. Bu, birbirlerinden öğrenirken ve görüşlerini nasıl paylaşacaklarını öğrenirken birbirlerine saygı duymalarına yardımcı olur.
Bu aynı zamanda, herkesin en iyi fikirlerini bir araya getirdiklerini ve başkalarından gelen geri bildirimlerle iyi bir ürün ürettiklerini bildikleri için onlara cesaret verir. Bu nedenle, değişiklikleri dahil etmekten veya çalışmalarıyla ilgili daha fazla geri bildirim almaktan korkmazlar.
Bu, özellikle gereksinimlerin sık sık değişeceği projelerde kullanışlıdır. Sürekli geri bildirim, ekiplerin bu değişiklikleri cesaretle dahil etmelerine yardımcı olacaktır.
Böylelikle Scrum, XP, Kanban ve Lean gibi farklı çevik metodolojilerin yanı sıra avantaj ve dezavantajlarını gördük.
Şimdi, aralarında kolaylıkla ayrım yapabilir ve aralarındaki daha ince farklılıkları takdir edebiliriz. Ayrıca bu metodolojilerin her birinin temellerini öğrendik ve gerektiğinde bunları projelerimize nasıl uygulayacağımızı gördük.
Sonraki bölümde, Scrum hakkındaki her şeyi anlayalım.
Scrum Metodolojisi
SCRUM, Yinelemeli model ve artımlı modelin bir kombinasyonu olan çevik metodolojide bir süreçtir.
Gelenekselin en büyük dezavantajlarından biri Şelale Modeli şuydu - ilk aşama tamamlanana kadar, uygulama diğer aşamaya geçmiyor. Ve şans eseri, döngünün sonraki aşamasında bazı değişiklikler olursa, bu değişiklikleri uygulamak çok zor hale gelir, çünkü bu, önceki aşamaları yeniden gözden geçirmeyi ve değişiklikleri yeniden yapmayı içerecektir.
SCRUM'un temel özelliklerinden bazıları şunlardır:
- Kendi kendine organize olmuş ve odaklanmış ekip.
- Çok büyük gereksinim belgeleri yok, bunun yerine çok kesin ve özlü hikayeler var.
- Çapraz işlevli ekipler tek bir birim olarak birlikte çalışır.
- Özellikleri anlamak için kullanıcı temsilcisi ile yakın iletişim kurun.
- En fazla bir aylık kesin bir zaman çizelgesine sahiptir.
- Scrum, bir seferde tüm 'şeyi' yapmak yerine, belirli bir aralıkta her şeyi biraz yapar.
- Herhangi bir taahhütte bulunmadan önce kaynak kapasitesi ve kullanılabilirliği dikkate alınır.
Bu metodolojiyi iyi anlamak için SCRUM'daki temel terminolojileri anlamak önemlidir.
Ayrıca oku => Çevik Scrum Süreci Kullanılarak Kısa Sürede Yüksek Değerli Yazılım Özellikleri Nasıl Sağlanır
Önemli SCRUM Terminolojileri
1) Scrum Takımı
Scrum ekibi, + veya - iki üyesi olan 7 kişilik bir ekiptir. Bu üyeler, yetkinliklerin bir karışımıdır ve ürün sahibi ve bir scrum ustası ile birlikte geliştiriciler, test uzmanları, veritabanı çalışanları, destek personeli vb.
Tüm bu üyeler, söz konusu özellikleri geliştirmek ve uygulamak için özyinelemeli ve belirli bir aralık için yakın işbirliği içinde birlikte çalışır. SCRUM takım oturma düzeni etkileşimlerinde çok önemli bir rol oynar, asla kabinlerde veya kabinlerde oturmazlar, büyük bir masa.
2) Sprint
Sprint, işin tamamlanması ve incelemeye veya üretim dağıtımı için hazır hale getirilmesi gereken önceden tanımlanmış bir aralık veya zaman çerçevesidir. Bu zaman dilimi genellikle 2 hafta ile 1 ay arasındadır.
sql server senaryo tabanlı mülakat soruları
Günlük yaşamımızda 1 aylık Sprint döngüsünü takip ettiğimizi söylediğimizde, bu sadece görevler üzerinde bir ay çalıştığımız ve o ayın sonuna kadar incelemeye hazırladığımız anlamına geliyor.
3) Ürün Sahibi
Ürün sahibi, geliştirilecek uygulamanın kilit paydaşı veya baş kullanıcısıdır. Ürün sahibi, müşteri tarafını temsil eden kişidir. Nihai yetkiye sahiptir ve her zaman ekip için hazır olmalıdır.
Açıklığa kavuşturulması gereken herhangi bir şüphesi olduğunda ulaşılabilir olmalıdır. Ürün sahibinin sprint ortasında veya sprint zaten başladığında yeni bir gereksinimi anlaması ve atamaması önemlidir.
4) Scrum Master
Scrum Master, scrum ekibinin kolaylaştırıcısıdır. Scrum ekibinin üretken ve ilerici olmasını sağlar. Herhangi bir engel olması durumunda, scrum ustası bunları takip eder ve ekip için çözer. SCRUM Master, PO ile ekip arasındaki arabulucudur.
PO'ya Sprint'in ilerleyişi hakkında bilgi verir. Ekip için herhangi bir engel veya endişe varsa, PO ile görüşür ve bunları çözer. Takımın Günlük Beklemede olduğu gibi, PO ile SCRUM Master'ın bir stand-up'ı her gün gerçekleşir.
Önerilen okuma => Agile Test Dünyasında Nasıl İyi Bir Takım Mentoru, Koçu ve Gerçek Bir Takım Savunucusu Olunur?
5) İş Analisti (BA)
Bir İş Analisti, SCRUM'da çok önemli bir rol oynar. Bu kişi, gereksinimin son halini almasından ve gereksinim belgelerinde taslak haline getirilmesinden sorumludur (kullanıcı öykülerinin oluşturulduğu temel alınarak).
Kullanıcı Hikayeleri / Kabul kriterlerinde herhangi bir belirsizlik varsa, teknik (SCRUM) ekip tarafından yaklaşılan ve daha sonra PO'ya götüren veya mümkünse kendi başına çözen kişidir. Büyük ölçekli projelerde, 1'den fazla BA olabilir, ancak küçük ölçekli projelerde SCRUM Master, BA olarak da hareket ediyor olabilir.
Proje başlangıcı başladığında lisans diplomasına sahip olmak her zaman iyi bir uygulamadır.
6) Kullanıcı Hikayesi
Kullanıcı hikayeleri, uygulanması gereken gereksinimler veya özellikten başka bir şey değildir.
Dolandırıcılık ortamında, bu kadar büyük gereksinim belgelerine sahip değiliz, bunun yerine gereksinimler tek bir paragrafta tanımlanıyor ve genellikle şu biçime sahip:
Olarak
İstiyorum
Başarmak
Örneğin :
Yönetici olarak, kullanıcının izinsiz erişimi kısıtlamak için arka arkaya 3 kez yanlış şifre girmesi durumunda şifre kilidinin olmasını istiyorum.
Kullanıcı hikayelerinin uyulması gereken bazı özellikleri vardır. Kullanıcı hikayeleri kısa, gerçekçi, tahmin edilebilir, eksiksiz, pazarlığa açık ve test edilebilir olmalıdır. Sprint'in ortasında bir kullanıcı hikayesi asla değiştirilmez veya değiştirilmez.
PO'nun Kullanıcı Hikayelerini uygun bir Kabul Kriterleri seti ile doğru şekilde hazırladığından emin olmak SCRUM Master ve BA'nın (geçerliyse) sorumluluğundadır ”. Sprint yayınını etkileyecek herhangi bir değişiklik yapılacaksa, bu tür hikayeler sprintten çıkarılır veya mevcut saatlere göre yapılır.
Her kullanıcı hikayesinin, ekip tarafından iyi tanımlanması ve anlaşılması gereken bir kabul kriteri vardır.
Kabul kriterleri, destekleyici belgeleri sağlayan kullanıcı hikayesinin ayrıntılarını verir. Kullanıcı hikayesini daha da iyileştirmeye yardımcı olur. Takımdan herhangi biri kabul kriterlerini yazabilir. Test ekibi, test durumlarını / koşullarını bu kabul kriterlerine dayandırır.
7) Destanlar
Destanlar belirsiz kullanıcı hikayeleridir veya bunların tanımlanmamış ve gelecekteki sprintler için saklanan kullanıcı hikayeleri olduğunu söyleyebiliriz.
Sadece onu yaşamla ilişkilendirmeye çalışın, bir tatile gittiğinizi hayal edin. Önümüzdeki hafta gidecekseniz, otel rezervasyonlarınız, gezileriniz, gezginlerin kontrol etmeleri vb. Gibi her şey yerinde olacak. Peki ya gelecek yıl için tatil planınız? XYZ yerine gidebileceğiniz konusunda yalnızca belirsiz bir fikriniz var, ancak ayrıntılı bir planınız yok.
Bir Destan, tıpkı gelecek yılki tatil planınız gibi, sadece gitmek isteyebileceğinizi bildiğiniz, ancak nereye, ne zaman, kiminle, tüm bu ayrıntılar şu anda hiçbir fikriniz yok.
Benzer şekilde ileride uygulanması gereken, detayları henüz bilinmeyen özellikler vardır. Çoğunlukla bir özellik bir Destan ile başlar ve daha sonra uygulanabilecek hikayelere bölünür.
8) Ürün İş Listesi
Ürün biriktirme listesi, tüm kullanıcı hikayelerinin saklandığı bir tür kova veya kaynaktır. Bu, Ürün Sahibi tarafından sağlanır. Ürün biriktirme listesi, ürün sahibinin iş ihtiyaçlarına göre önceliklendiren bir istek listesi olarak düşünülebilir.
Planlama toplantısı sırasında (bir sonraki bölüme bakın), ürün birikiminden bir kullanıcı hikayesi alınır, ardından ekip beyin fırtınası yapar, onu anlar ve geliştirir ve ürün sahibinin müdahalesi ile hangi kullanıcı hikayelerinin alınacağına toplu olarak karar verir.
9) Sprint İş Listesi
Önceliğe bağlı olarak, kullanıcı hikayeleri Ürün İş Listesinden birer birer alınır. Scrum takımı bunun üzerine beyin fırtınası yapar ve fizibiliteyi belirler ve belirli bir sprint üzerinde çalışacak hikayelere karar verir. Scrum ekibinin belirli bir sprint üzerinde çalıştığı tüm kullanıcı hikayelerinin toplu listesi Sprint iş yığını olarak bilinir.
10) Hikaye Puanları
Hikaye noktaları, bir kullanıcı hikayesinin karmaşıklığının nicel bir göstergesidir. Hikaye noktasına göre bir hikaye için tahmin ve çabalar belirlenir.
Bir hikaye noktası görecelidir ve mutlak değildir. Tahmininizin ve çabalarımızın doğru olduğundan emin olmak için, kullanıcı hikayelerinin büyük olmadığını kontrol etmek önemlidir. Kullanıcı hikayesi ne kadar kesin ve küçükse, tahmin o kadar doğru olur.
Her bir kullanıcı hikayesi, Fibonacci serisine (1, 2, 3, 5, 8, 13 ve 21) dayalı bir hikaye noktasına atanır. Sayı ne kadar yüksekse, hikaye de karmaşıktır.
Kesin olmak
- 1/2/3 hikaye puanı verirseniz bu, hikayenin küçük ve düşük karmaşıklıkta olduğu anlamına gelir.
- 5/8 puan verirseniz, orta karmaşık ve
- 13 ve 21 oldukça karmaşıktır.
Burada karmaşıklık hem geliştirme hem de test çabasından oluşur.
Bir hikaye noktasına karar vermek için, beyin fırtınası saldırı ekibi içinde gerçekleşir ve ekip toplu olarak bir hikaye noktasına karar verir.
Geliştirme ekibinin belirli bir hikayeye 3 hikaye puanı vermesi olabilir, çünkü onlar için 3 satır kod değişikliği olabilir, ancak test ekibi 8 hikaye puanı verir çünkü bu kod değişikliğinin daha büyük modülleri etkileyeceğini düşünürler. test çabası daha büyük olacaktır. Hangi hikaye noktası veriyorsan ver, onu haklı çıkarmalısın.
Yani bu durumda beyin fırtınası gerçekleşir ve ekip toplu olarak bir hikaye noktasında hemfikir olur.
Bir hikaye noktasına karar verirken aşağıdaki faktörleri aklınızda bulundurun:
- Hikayenin diğer uygulama / modül ile olan bağımlılığı.
- Kaynağın beceri seti.
- Hikayenin karmaşıklığı.
- Tarihsel öğrenme.
- Kullanıcı hikayesinin kabul kriterleri.
Belirli bir hikayenin farkında değilseniz, onu boyutlandırmayın.
Bir hikaye = veya> 8 puan olduğunda, 2 veya daha fazla hikayeye bölünür.
11) Yakma tablosu
Yakma grafiği, scrum görevlerinin tahmini v / s gerçek çabasını gösteren bir grafiktir.
Hikayelerin taahhüt edilen hikaye noktalarının tamamlanmasına doğru ilerleyip ilerlemediğini kontrol etmek için belirli bir sprint için günlük görevlerin izlendiği bir izleme mekanizmasıdır.
Misal : Bunu anlamak için aşağıdaki şekle bakın:
Varsaymıştım:
- 2 hafta Sprint (10 gün)
- Sprint üzerinde çalışan fiili 2 kaynak.
'Hikaye' -> Bu sütun, sprint için alınan kullanıcı hikayelerini gösterir.
'Görev' -> Bu sütun, kullanıcı hikayesiyle ilişkili görevlerin listesini gösterir.
'Çaba' -> Bu sütun çabayı gösterir. Şimdi, bu ölçü görevi tamamlamak için gereken toplam çabadır. Herhangi bir birey tarafından gösterilen çabayı tasvir etmez.
'1. Gün - 10. Gün' -> Bu sütun (lar) hikayeyi tamamlamak için kalan saatleri gösterir. Lütfen saatin halihazırda yapılmış saat DEĞİL, ancak kalan saatler olduğuna bakın.
'Tahmini çaba' -> Çaba toplamıdır. 'Başlangıç' için, yalnızca tek tek tüm görevin toplamıdır: TOPLA (C5: C15)
1 günde tamamlanması gereken toplam çaba 70/10 = 7'dir. Yani 1. günün sonunda efor 70 - 7 = 63'e düşmelidir. Benzer şekilde, tüm çabalar için hesaplanır. tahmini eforun 0 olması gereken günden 10. güne kadar (16. sıra)
'Gerçek Çaba Kaldı' -> Adından da anlaşılacağı gibi, aslında hikayeyi tamamlamak için geriye kalan çaba. Gerçek çabaların tahmin edilenden daha fazla artması veya azalması da olabilir.
Bu burndown grafiğini oluşturmak için dahili işlevleri ve Excel'deki Grafiği kullanabilirsiniz.
Burn Down Grafiği adımları şöyle olacaktır:
- Tüm öyküleri girin (Sütun A5 - A15).
- Tüm Görevleri girin (Sütun B5 - B15).
- Günleri girin (1. Gün - 10. Gün).
- Başlangıç çabalarını girin (C5 - C15 görevlerini toplayın).
- Her gün için 'Tahmini Çabaları' hesaplamak için formülü uygulayın (1. Günden 10. Güne). Formülü D15 (C16- $ C $ 16/10) olarak girin ve tüm günler boyunca sürükleyin.
- Her gün için gerçek çabaları girin. Kalan fiili çabayı özetlemek için D17 (TOPLA (D5: D15)) 'de formülü girin ve diğer tüm günler için sürükleyin.
- Bunu seçin ve aşağıdaki gibi grafiği oluşturun:
12) Hız
Bir scrum takımının bir sprintte arşivlediği toplam hikaye noktası sayısına Velocity denir. Scrum takımı hızına göre değerlendirilir veya referans alınır. Bunu söyledikten sonra, buradaki amacın maksimum hikaye puanlarına ulaşmak DEĞİL, saldırı ekibinin konfor seviyesine saygı gösteren kaliteli bir teslimata sahip olmak olduğu unutulmamalıdır.
Örneğin : Belirli bir sprint için: Toplam kullanıcı hikayesi sayısı, aşağıda gösterildiği gibi hikaye puanlarına sahip 8'dir.
Yani burada hız, hikaye puanlarının toplamı olacak = 30
Bitti'nin Tanımı:
Bir Sprint, tüm hikayeler tamamlandığında Bitti olarak işaretlenir, tüm geliştirme, araştırma, QA görevleri 'Tamamlandı' olarak işaretlenir, tüm hatalar sabit-kapalıdır, diğer hatalar daha sonra yapılabilecekler (tamamen ilişkili olmayanlar veya daha az önemli olanlar gibi) çıkarılır ve biriktirme listesine eklenir, kod incelemesi ve birim testi tamamlanır, tahmini saatler görevlere konulan gerçek saatleri karşılamıştır ve en önemlisi PO ve paydaşlara başarılı bir demo verilmiştir.
SCRUM Metodolojisinde Yapılan Faaliyetler
# 1) Planlama Toplantısı
Sprint'in başlangıç noktası bir planlama toplantısıdır. Tüm scrum ekibinin toplandığı toplantıdır, SCRUM Master, ürün birikiminden gelen önceliğe göre bir kullanıcı hikayesi seçer ve ekip bunun üzerine beyin fırtınası yapar.
Scrum ekibi, tartışmaya dayanarak hikayenin karmaşıklığına karar verir ve onu Fibonacci serisine göre boyutlandırır. Ekip, kullanıcı hikayesinin uygulanmasını tamamlamak için yapılacak çabalarla birlikte (saat cinsinden) görevleri tanımlar.
Çoğu zaman, planlama toplantısından önce bir “Planlama Öncesi toplantı” yapılır. Bu tıpkı scrum takımının resmi planlama toplantısına oturmadan önce yaptığı ev ödevi gibidir. Ekip, planlama toplantısında tartışmak istedikleri bağımlılıkları veya diğer faktörleri yazmaya çalışır.
# 2) Sprint Görevlerinin Yürütülmesi
Adından da anlaşılacağı gibi bunlar, scrum ekibi tarafından görevlerini yerine getirmek ve kullanıcı hikayesini 'Bitti' durumuna getirmek için yapılan gerçek çalışmadır.
# 3) Günlük Standup
Sprint döngüsü sırasında, scrum takımı her gün 15 dakikadan fazla olmamak üzere toplanır (bir stand-up çağrısı olabilir, günün başlangıcında yapılması önerilir) ve 3 noktayı belirtin:
- Takım üyesi dün ne yaptı?
- Takım üyesi bugün ne yapmayı planlıyordu?
- Herhangi bir engel (barikat) var mı?
Bu toplantıyı kolaylaştıran, Scrum ustasıdır. Herhangi bir ekip üyesinin herhangi bir zorlukla karşılaşması durumunda, saldırı ustası sorunu çözmek için takip eder. Stand up'ta, yönetim kurulu da gözden geçirilir ve kendi içinde ekibin ilerlemesini gösterir.
# 4) Toplantıyı Gözden Geçirme
Her sprint döngüsünün sonunda, SCRUM ekibi tekrar toplanır ve uygulanan kullanıcı hikayelerini ürün sahibine gösterir. Ürün sahibi, hikayeleri kabul kriterlerine göre çapraz doğrulayabilir. Bu toplantıya başkanlık etmek yine Scrum ustasının sorumluluğundadır.
Ayrıca SCRUM aracında, Sprint kapatılır ve görevler tamamlandı olarak işaretlenir.
# 5) Geriye Dönük Toplantı
Geriye dönük toplantı, gözden geçirme toplantısından sonra gerçekleşir.
SCRUM ekibi aşağıdaki noktaları toplar, tartışır ve belgeler:
- Sprint sırasında neler iyi gitti (En iyi uygulamalar)?
- Sprint'te neler iyi gitmedi?
- Dersler öğrenildi
- Aksiyon öğeleri.
Scrum takımı en iyi uygulamayı izlemeye devam etmeli, 'en iyi olmayan uygulamaları' görmezden gelmeli ve sonuçta ortaya çıkan sprintler sırasında öğrenilen dersleri uygulamalıdır. Geriye dönük toplantı, SCRUM sürecinin sürekli iyileştirilmesini uygulamaya yardımcı olur.
Süreç nasıl yapılır? Bir örnek!
SCRUM'un teknik jargonlarını okuduktan sonra. tüm süreci bir örnekle göstermeme izin verin.
Misal:
Aşama 1 : 1 ürün sahibi, 1 Scrum ustası, 2 testçi, 4 geliştirici ve 1 DBA'dan oluşan 9 kişilik bir SCRUM ekibimiz olsun.
Adım 2 : Sprint'in 4 haftalık bir döngüyü takip etmesi kararlaştırılır. Dolayısıyla, 5 Haziran'dan 4'e kadar 1 aylık Sprintimiz varinciTemmuz ayının.
Aşama 3 : Ürün Sahibi, ürün iş yığınında öncelikli kullanıcı öyküleri listesine sahiptir.
4. Adım: Takım 4'te buluşmaya karar veririnci'Ön Planlama' toplantısı için Haziran.
- Ürün sahibi, ürün birikiminden 1 hikaye alır, onu açıklar ve üzerinde beyin fırtınası yapması için ekibe bırakır.
- Tüm ekip tartışır ve kullanıcı hikayesini net bir şekilde anlamak için doğrudan ürün sahibiyle iletişim kurar.
- Benzer şekilde, çeşitli diğer kullanıcı hikayeleri alınır. Mümkünse, ekip devam edip hikayeleri boyutlandırabilir.
Tüm tartışmalardan sonra, bireysel ekip üyeleri iş istasyonlarına geri döner ve
- Her hikaye için bireysel görevlerini belirleyin.
- Çalışacakları tam saat sayısını hesaplayın. Üyenin bu saatleri nasıl tamamladığını kontrol edelim.
Toplam çalışma saati sayısı = 9
Ara için eksi 1 saat, toplantılar için eksi 1 saat, e-postalar, tartışmalar, sorun giderme vb. İçin eksi 1 saat.
Yani fiili çalışma saatleri = 6.
Sprint sırasında toplam iş günü sayısı = 21 gün.
Mevcut toplam saat sayısı = 21 * 6 = 126.
Üye 2 gün = 12 saat izinde (Bu her üye için değişiklik gösterir, bazıları izin alabilir ve bazıları izin vermeyebilir.)
Gerçek saat sayısı = 126 - 12 = 114 saat.
Bu, üyenin bu sprint için 114 saat boyunca müsait olacağı anlamına gelir. Böylece bireysel sprint görevini toplam 114 saate ulaşılacak şekilde ayıracak.
Adım 5 : 5 üzerindeinciHaziran ayı itibariyle tüm Scrum takımı “Planlama Toplantısı” için toplanıyor.
- Ürün iş yığınındaki kullanıcı hikayesinin son kararı yapılır ve hikaye Sprint İş Listesine taşınır.
- Her hikaye için, her ekip üyesi tanımlanmış görevlerini açıklar, gerekirse bu görevler hakkında tartışabilir, boyutlandırabilir veya yeniden boyutlandırabilir (Fibonacci serisini hatırlayın !!).
- Scrum ustası veya takım, bir araçta her hikaye için saatleriyle birlikte bireysel görevlerine girer.
- Tüm hikayeler tamamlandıktan sonra, Scrum ustası ilk Hızı not eder ve Sprint'i resmi olarak başlatır.
6. Adım : Sprint başladığında, atanan görevlere bağlı olarak her ekip üyesi bu görevler üzerinde çalışmaya başlar.
7. Adım : Ekip her gün 15 dakika toplanır ve 3 şeyi tartışır:
- Dün ne yaptılar?
- Bugün ne yapmayı planlıyorlar?
- Herhangi bir engel (barikat) var mı?
8. Adım : Scrum master, 'Burn down chart' yardımıyla ilerlemeyi günlük olarak izler.
9. Adım : Herhangi bir engel durumunda, Scrum ustası bunları çözmek için takip eder.
Adım 10 : 4 üzerindeinciTemmuz, ekip gözden geçirme toplantısı için tekrar toplanır. Bir üye, uygulanan kullanıcı hikayesini ürün sahibine gösterir.
Adım 11 : 5 üzerindeinciTemmuz, Ekip Retrospektif için tekrar toplanır ve burada
- Ne iyi gitti?
- Ne iyi gitmedi?
- Aksiyon öğeleri.
Adım 1/2 : 6 üzerindeinciTemmuz ayında Takım, bir sonraki sprint için ön planlama toplantısı için tekrar toplanır ve döngü devam eder.
SCRUM Etkinlik Araçları
Dolandırıcılık faaliyetlerini izlemek için kapsamlı olarak kullanılabilecek birkaç araç vardır.
Bunlardan bazıları şunları içerir:
Yaklaşan eğitimde, etkili Çevik Takımları harekete geçiren bir kavram olan Çevik Manifesto'ya ışık tutacağız.
Yazarlar Hakkında: Bu seri aşağıdaki STH ekip üyeleri tarafından yazılmıştır: Shruti Shrivastava - BFSI, E-ticaret ve B2B alanlarında 9 yıllık deneyime sahip Profesyonel bir Scrum Ustası. Shruti, otomasyon testi ve önde gelen saldırı ekiplerinde uzmandır.Anshul Kumar Srivastava - BFSI ve Telekom sektörlerinde 7 yıllık deneyime sahip, sonuç odaklı bir Ürün Yönetimi uzmanı ve Çevik uygulayıcı.
Önerilen Kaynaklar
- Çevik Scrum Çevrimiçi Testi: Çevik Scrum Bilginizi Test Edin
- Kanban vs Scrum vs Agile: Farklılıkları Bulmak İçin Ayrıntılı Bir Karşılaştırma
- Çevik Scrum Süreci Kullanılarak Kısa Sürede Yüksek Değerli Yazılım Özellikleri Nasıl Sağlanır
- Çevik Manifesto: Çevik Değerleri ve İlkeleri Anlamak
- SAFe Çevik Eğitimi: Ölçekli Çevik Çerçeve Nedir?
- 30'dan Fazla En İyi Scrum Mülakat Soruları ve Cevapları (2021 LİSTESİ)
- Agile Vs Şelalesi: Projeniz İçin En İyi Metodoloji Hangisi?
- En İyi 31 Çevik Mülakat Soruları ve Cevapları