agile vs waterfall which is best methodology
bir torrent dosyasını nasıl açarsın
Çevik ve Şelale Metodolojileri, Farklı SDLC Modelleri Türleri ve Şelale ile Çevik Geliştirme Modelleri Arasındaki Farklar ve Testler Hakkında Her Şeyi Öğrenin:
Her birinin artıları ve eksileri temelinde projeniz için en uygun modelin hangisi olduğuna karar vermek için bu bilgilendirici makaleyi okuyun.
Şelale Modeli ve Çevik Model, Yazılım Geliştirme Yaşam Döngüsü (SDLC) türleridir. Bunlar, yazılım endüstrisi tarafından yazılımı tasarlamak, geliştirmek ve test etmek için kullanılan süreçlerdir.
SDLC'yi takip ederek, müşteri beklentilerini karşılayabilir, projeyi verilen zaman dilimleri içinde tamamlayabilir ve maliyeti tahmin edebiliriz.
Ne öğreneceksin:
- Şelale ve Çevik Model İş Akışları
- Şelale Modeli
- Çevik İş Akışı
- Agile Vs Şelale Modelleri Arasındaki Fark
- Çevik Test ile Şelale Testi Arasındaki Farklar
- Sonuç
Şelale ve Çevik Model İş Akışları
Basit bir İngilizcede Agile, 'hızlı ve kolay hareket edebilme' anlamına gelir ve bu nedenle, konu söz konusu olduğunda Çevik geliştirme metodolojisi .
Çevik, görevleri sık gözden geçirmeler ve planların uyarlanmasıyla daha kısa çalışma bölümlerine ayırarak temsil edilen bir proje yönetimi yöntemidir.
Benzer şekilde, şelale kelimesi dikey bir su akışını veya bir dizi dik damladan su akışını ifade eder. Şelale modeli, ilerlemenin, gereksinim toplama, analiz, tasarım, geliştirme, test etme, dağıtım ve bakım aşamaları boyunca büyük ölçüde bir yönde aşağıya doğru aktığı doğrusal bir sıralı modeldir.
Aynı örnek, söz konusu proje yönetimi kavramı için de geçerlidir. şelale Modeli . Seri aşamalar ve sabit bir çalışma planı ile temsil edilen bir proje yönetimi yöntemidir.
(resim kaynak )
Waterfall iş akışını ve Çevik iş akışını tartışmadan önce, Yazılım Geliştirme Yaşam Döngüsü tanımına ve gereksinimlerine bir göz atalım.
Yazılım Geliştirme Yaşam Döngüsü Nedir?
Yazılımı sistematik olarak geliştirmek için adım adım bir prosedürdür. Bunun için, farklı şirketlerdeki farklı yazılım geliştirme yaşam döngüleri türlerinden seçim yapıyoruz. İhtiyaca göre uygun bir yaşam döngüsü seçilir.
Şelale modeli SDLC türlerinden biridir ve eski bir yazılım geliştirme sürecidir. Çevik model, en yeni ve en gelişmiş modeldir. Çevik, diğer yazılım geliştirme yaşam döngüsünden türetilmiştir.
Diğer SDLC, spiral modeli, V ve V modelini, Prototip modelini içerir. İş gereksiniminin gerekliliğine ve uyumluluğuna bağlı olarak, yazılım uygulamasını geliştirmek için en iyi modeli seçeceğiz.
(resim kaynak )
Yazılım geliştirme yaşam döngüsü neden gereklidir?
SDLC, projeyi yapılandırılmış bir şekilde yönetmek için gereklidir. Belli bir kontrol seviyesi sağlar ve ekip üyelerinin rol ve sorumluluklarını tanımlar. SDLC'deki her aşama için kapsam ve son tarih sağlar.
Kaliteli ürünü geliştirmek ve sunmak için tüm adımları takip etmek ekip üyeleri için bir kullanım kılavuzu gibidir. Ekip yönetiminin hedefleri ve gereksinimleri tanımlamasına ve değerlendirmesine yardımcı olur. Ayrıca görevlerin planlanmasına ve tahmin edilmesine yardımcı olur. Müşteri ile geliştirme ekibi arasındaki iletişim hattını kurar ve her biri için rol ve sorumlulukları oluşturur.
Yazılım Geliştirme Yaşam Döngüsü Türleri
Yazılım geliştirme sürecinde kullanılan SDLC türlerine kısa bir giriş görelim.
# 1) Şelale Modeli
Daha önce tartışıldığı gibi, şelale modeli, tanıtılan ilk yazılım geliştirme yaşam döngüsüdür. Yazılım geliştirmenin sıralı yoludur. Çok az şirket bu yaklaşımı takip ediyor. Proje çok basit olduğunda ve başka gereksinim değişikliği olmadığında, bu yaklaşımı takip edeceğiz.
Bu eğitimde şelale modeli hakkında daha fazla tartışacağız.
# 2) Çevik Model
Çevik bir iş akışı, şirketlerin çoğunda kullanılan yazılım geliştirme sürecine yönelik gelişmiş bir yaklaşımdır. Çevik, sprint tabanlı yazılım geliştirme yaşam döngüsü olarak tanımlanır.
İlerleyen bölümlerde, Çevik iş akışı hakkında daha fazla tartışabiliriz.
# 3) Spiral Model
Gereksinimi artımlı sırayla bölerek ve ekleyerek yazılımı oluşturmanın ve test etmenin yoludur. Bu model, gereksinimlerin değişmeye devam ettiği projelerde yardımcı olacaktır. Bu spiral model, yinelemeli geliştirme süreci ile sıralı doğrusal geliştirme sürecinin birleşimidir.
Bu yaklaşım, ürünün artımlı sürümlerinde bize izin verecektir. Burada, sürüm için yazılımın tüm modüllerinin tamamlanmasını beklemek gerekli değildir.
Doğrusal sıralı model, sistem düzeyinde başlayan ve analiz, tasarım, kodlama, test ve destek yoluyla ilerleyen sistematik sıralı bir yazılım geliştirme yaklaşımı olduğu anlamına gelir.
Yinelemeli model, başlangıçtaki, basitleştirilmiş bir uygulamaya odaklanan, daha sonra aşamalı olarak daha karmaşık hale gelen ve son sistem tamamlanana kadar daha geniş bir özelliğin ayarlandığı, bir yazılım geliştirme yaşam döngüsünün belirli bir uygulamasıdır.
# 4) Prototip Modeli
Bu model, yazılımı önce kukla modeli geliştirecek ve uygulanabilirse ve tüm iş gereksinimlerine ulaşacak şekilde yazılımın oluşturulması ve test edilmesi sürecini içerir.
Burada önce prototipi oluşturup test ettik, ardından gerçek modeli tam sistem özelliklerine göre oluşturduk. Yazılım prototipleme, yazılım uygulamalarının prototiplerini oluşturma faaliyetidir.
# 5) V ve V Modeli
Doğrulama ve doğrulama modelidir. Burada, yazılımı geliştirirken, SDLC'nin her aşamasında her şeyi doğrulamak ve onaylamak için kullandık. V modeli şelale modelinin bir uzantısı olarak kabul edilir.
Dolayısıyla, tüm SDLC türlerinin kendi özellikleri ve özellikleri vardır. Yazılım uygulamasını geliştirmek için proje gereksinimi, ihtiyaçları, fizibilitesi ve süresine bağlı olarak belirli yazılım geliştirme yaşam döngüsünü seçebiliriz.
Şimdi, Waterfall ve Agile yazılım geliştirme yaşam döngülerini ayrıntılı olarak tartışacağız.
Şelale Modeli
Şelale modelinde, her aşama başka bir aşamaya başlamadan önce tamamlanmalıdır. Aynı anda birden fazla aşamayı çalıştıramayız. Bu 1970 yılında Winston Royce tarafından tanıtıldı. Şelale modeli farklı aşamalara ayrılmıştır.
(resim kaynak )
Şelale Modeli aşağıdaki aşamaları içerir:
- Gereksinim toplama
- Fizibilite çalışması
- Tasarım
- Kodlama
- Test yapmak
- Bakım
# 1) Gereksinim Analizi
Burada, iş analisti gereksinim spesifikasyonunu alacaktır. Gereksinim, CRS (Müşteri Gereksinim Şartnamesi) formatında olacaktır. CRS, iş akışının nasıl ilerlemesi gerektiğini ve uygulamanın belirtilen gereksinime göre nasıl çalışması gerektiğini açıklar. İş analistleri CRS'yi SRS'ye (Yazılım Gereksinim Spesifikasyonu) dönüştürecektir.
Daha sonra iş analisti, gereksinim özelliklerini geliştirme ve test ekibiyle ayrıntılı olarak tartışır ve gereksinimi geliştirme ve test bakış açısından anlar. Bu, uygulama yazılımını gerçek gereksinimlere göre oluşturmak için gereksinimleri tartışma ve analiz etme aşamasıdır.
Burada her şey Yazılım gereksinimi belirtim belgesinde belgelenmelidir. Şelale modelinde, her aşamanın teslim edilebilir / sonuç / çıktıları, sonraki aşamalar için girdi kaynağıdır.
Hizmet tabanlı bir endüstride, bir İş Analisti gereksinimi getirebilir.
Ürün tabanlı bir şirkette, Ürün Analisti gereksinimi getirir.
# 2) Fizibilite Çalışması
Yönetim ekibi fizibilite çalışmasını yapacak. Bu, ekibin, bu gereksinim / uygulamanın çevremizde geliştirilip geliştirilemeyeceği, mevcut kaynağın yeterli olup olmadığı, maliyet ve diğer birçok faktörün uygulanabilir olup olmadığı gibi parametreleri analiz edeceği ve kontrol edebileceğimizi kontrol edeceği anlamına gelir. tüm iş akışı olsun ya da olmasın.
Bu toplantıda / analizde, Proje Yöneticisi, İş Analisti, Finans Müdürü, İK, Proje Lideri tartışmanın bir parçası olacak.
# 3) Sistem Tasarımı
Burada Proje Mimarı sistem tasarımını hazırlayacaktır. Donanımı, sistem gereksinimlerini belirleyecek ve uygulama mimarisini tasarlayacaktır. Sistem tasarımında 2 bölüm vardır: üst düzey tasarım ve alt düzey tasarım. Üst düzey tasarımda, uygulamanın farklı bloklarını tasarlıyoruz. Düşük seviyeli tasarımda, sözde kodu yazıyoruz.
# 4) Kodlama
Burada geliştiriciler, farklı yöntemler ve farklı mantıklar kullanarak uygulamanın her işlevinin ve kullanıcı arayüzünün tam kodlamasına başlar. Uygulamayı oluşturmak için Java, Python veya başka herhangi bir dil gibi herhangi bir programlama dilini kullanabilirler.
Uygulamanın belirli modülünün her bir işlevselliği için kodlama tamamlandıktan sonra, geliştirici birim testini yapacaktır. Kod düzgün çalışıyorsa, geliştirici kodu test ortamına dağıtacak ve yapıyı test için test edene verecektir.
# 5) Test Etme
Buradan test faaliyeti başlar. Bu aşamaya kadar Şelale modelinde hiçbir görevimiz olmayacak. Bu aşamada her türlü testi yapıyoruz. Bu test türleri arasında duman testi, fonksiyonel test, entegrasyon testi, sistem testi, kabul testi, Regresyon testi, geçici test, keşif testi ve tarayıcılar arası test bulunur.
Yapıyı aldıktan sonra uygulamayı test etmeye başlayacağız. İlk önce duman testi ile başlayacağız. Herhangi bir engelleyici sorunu gözlenmezse, ayrıntılı testlere devam edeceğiz.
Fonksiyonel testte, uygulamanın her bir bileşenini test etmeye başlayacağız. Burada metin alanları, düğmeler, bağlantılar, radyo düğmeleri, yükleme düğmeleri, açılır menüler ve gezinme bağlantıları gibi farklı bileşenleri kontrol ediyoruz.
Ardından, kullanıcı arayüzünü, görünümü ve hissi ve pozitif ve negatif girdi testini kontrol edeceğiz.
Ardından entegrasyon testine başlayacağız. Burada veri entegrasyonunu kontrol edeceğiz. Aynı verilerin farklı ilgili sayfalara yansıtılıp yansıtılmadığını, ilgili sayfalara e-posta bağlantısı navigasyonunu doğrulayacağız. 3. parti uygulamalar ile veri entegrasyonunu kontrol edecek ve uygulamadaki veritabanı değişikliklerini kontrol edeceğiz.
Ardından sistem testi yapacağız. Tüm uygulamayı tek bir birim olarak kontrol edeceğiz. İşlevselliği, sayfaların entegrasyonunu, alan doğrulamalarını, hata mesajlarını, onay mesajlarını ve daha fazlasını kontrol edeceğiz.
Uygulamayı test ederken sorunları hata izleme aracına kaydedeceğiz. Sorunlara göre hataya öncelik vereceğiz. Hatayı oluşturduktan sonra, sorunu çözmek için ilgili geliştiriciye atayacağız. Geliştiriciler, onları düzelttikten sonra onları test uzmanlarına atadıktan sonra hataları doğrulayacağız. İyi çalışıyorsa test cihazı hatayı kapatır, aksi takdirde test kullanıcıları sorunu düzeltmek için geliştiriciye geri atar. Böcek yaşam döngüsü böyle devam ediyor.
Ardından kabul testine geçiyoruz. Burada uygulamayı evreleme ve UAT (Kullanıcı Kabul Testi) gibi farklı ortamlarda test ediyoruz. Kodu Üretim ortamına taşımadan önce uygulamayı kapsamlı bir şekilde test etmek için en önemli aşama budur.
Kabul testi hatasız bir şekilde tamamlandıktan sonra, müşteri kodu Üretim sunucusuna dağıtmayı ve sürümü planlamayı planlayacaktır.
# 6) Bakım
Uygulama kodunu üretim sunucusuna dağıttıktan sonra, istemci uygulamasına destek / bakım sağlamalıyız. Bu bakım aşaması, gerçek zamanlı üretim sorunlarını gözlemlemek ve düzeltmek, bellek sorunlarını kontrol etmek, uygulamayı geliştirmek ve yeni gereksinim değişikliklerini geliştirmektir.
Şelale modelini hangi durumlarda tercih edebiliriz?
- Gerekli değişiklik olmadığında.
- Proje küçük ve basit olduğunda.
- Teknolojide karmaşıklık olmadığında.
- Daha fazla kaynak olduğunda.
Şelale Artıları:
- İleri geri planlama ve uygulama kolaydır .
- Şelale modelinin kullanımı basit ve anlaşılması kolaydır. Proje yöneticileri veya çalışanları için özel bir eğitim gerektirmez. Bir kolay öğrenme eğrisi .
- Doğada katı olmak, yönetimi kolay şelale döngüsü. Her aşamada sabit çıktılar ve bir inceleme süreci vardır.
- Daha az karmaşıklık Aşamalar çakışmadığından. Aşamalar birbiri ardına takip edilir. Diğer yazılım geliştirme metodolojilerine göre net bir yapı kullanır. Proje, ihtiyaç toplamadan başlayarak sabit sıralı adımlardan geçer ve nihayet bakıma iner.
- Aşamalı geliştirme nedeniyle, disiplin uygulanır ve zaman çizelgeleri kolaylıkla tutulabilir.
- İşler küçük projeler için iyi Sabit ve kristal netliğinde gereksinimlerimiz var.
- Süreçler ve sonuçlar iyi belgelenmiş .
- Görevleri düzenlemek kolaydır.
- Bu ilerlemeyi ölçmek kolay her aşamanın başlangıç ve bitiş noktaları önceden belirlenir.
- Proje boyunca ihtiyaçlarda neredeyse hiç değişiklik olmaz, dolayısıyla görevler sabit kalır geliştiriciler için. Ayrıca, herkes için kolaydır hızla öğrenmek için yeni geliştirici ve işe başlayın.
- Var finansal sürpriz yok . Gereksinimler belirlendikten sonra, nihai maliyet, geliştirmeye başlamadan önce hesaplanabilir.
- Bir sıralı finansman modeli .
- Onun detaylı tasarım beklenen nihai sonucu herkes için çok açık hale getirir.
- Gereksinim toplama aşamasında belgelenen işlevsel gereksinim özelliği, test senaryolarını ve test senaryolarını tasarlamak için test uzmanlarına yeterli ayrıntı verir. Bu nedenle, test süreci kolaylaşır şelale modelinde.
Şelale Eksileri:
- Geliştirmeye başlamadan önce tüm gereksinimlerin açıkça bilinmesi gerektiğinden, projeyi geciktirir .
- Kapsamlı araştırma gerektirir kullanıcı ihtiyaçlarına.
- Projenin ilk aşamasında, bir müşterinin gereksinimlerini işlevsel şartnameler biçiminde net bir şekilde tanımlaması ve kavramsallaştırması zordur. Dolayısıyla, son ürünü gördükten sonra fikirlerini değiştirmeleri için yüksek bir olasılık var. Bu değişiklik, bir iş planı veya pazar etkisi nedeniyle de meydana gelebilir. Bu modeldeki düşük esneklik, bu tür değişikliklere uyum sağlamak zor Özellikle ürünün büyük ölçüde yeniden tasarlanması gerektiğinde.
- Çalışan model yok kadar üretilir sonra şelale yaşam döngüsü boyunca aşama.
- Yavaş teslimat süreleri . Müşteri, tamamen tamamlanana kadar ürünü göremez.
- Müşterinin sisteme önceden alışma fırsatı yoktur. Şelale modeli daha çok bir iç süreç ve son kullanıcıyı hariç tutar .
- müşteri bilgilendirilmedi projenin sağlığı hakkında iyi.
- Son tarihler kaçırılabilir sıkı yönetim ve düzenli izleme yapılmazsa.
- Var değişikliklere yer yok Ürün, pazar gereksinimlerini karşılamayacağından geliştirme sırasında görünür olsa bile.
- Test gecikmeleri tamamlanana kadar. Ayrıca, büyük revizyonlar bu noktada çok maliyetlidir.
- Yüksek risk ve belirsizlik Proje tamamlanana kadar sorunların fark edilmemesi için çok fazla alan olduğundan şelale modeline dahil oluyor.
- Uygun bir model değil uzun, karmaşık ve devam eden projeler için.
- Zor ilerlemeyi ölçmek her aşamada.
- Test görevlileri, projenin birçok aşamasında boşta oturacaktır.
Çevik İş Akışı
Şimdi Çevik Yazılım geliştirme yaşam döngüsünü göreceğiz. Çevik, daha doğru ve hızlı bir şekilde iş yapma sürecidir.
Bu model, özellikle yazılım geliştirme için kullanılan bir proje yönetimi yöntemiyle ilgilidir. Görevlerin kısa iş aşamalarına bölünmesi ve planların sık sık yeniden değerlendirilmesi ve uyarlanması ile karakterizedir. Her ekip üyesi, temel iş akışları fikrine sahip olmalıdır.
(resim kaynak )
Agile'da geliştiriciler ve test uzmanları, uygulama yazılımını geliştirmek ve test etmek için paralel olarak çalışır. Geliştirme, yinelemeli modda yapılır. Her bir yineleme kullanıcı hikayesi, analiz, tasarım, kodlama ve test gerektirir.
Gereksinimin hatasız ve uygulanabilir olup olmadığını doğrulamak için gereksinimi ayrıntılı bir şekilde test ediyoruz. Her yinelemenin bitiminden sonra bir sonraki yinelemeye geçin ve aynı süreci yeni / diğer gereksinimlere göre takip ederiz.
Böylelikle yazılım bloğunu geliştirme ve test etme süreci, kısa sürede daha doğru ve esnek bir şekilde gerçekleştirilir. Yani bu süreci daha fazla endüstri takip ediyor ve benimsiyor.
İlk olarak, ürün sahibi tüm gereksinimleri ürün biriktirme listesine ekleyecektir. Ürün biriktirme listesi tüm kullanıcı hikayelerini içerir. Diyelim ki 100 ila 150 kullanıcı hikayesi tüm proje ile ilgilidir. Şimdi, uygulanmamız gereken sprint iş yığınına belirli kullanıcı hikayelerini ekleyin. Ardından, tüm geliştiriciler, QA, BA sprint öğeleri üzerinde çalışacak. Çevik akış bu şekilde çalışır.
Agile'da Kullanılan Anahtar Terminolojiler
Sprint iş yığını nedir?
manuel test için ücretsiz çevrimiçi test
Mevcut yinelemede veya sprintte uygulamamız gereken kullanıcı hikayelerinin listesidir.
Örneğin, Sprint iş yığınında 20 ila 30 kullanıcı hikayesi vardır. O halde bunlar, mevcut sprintte uygulamamız gereken kullanıcı hikayeleridir.
(resim kaynak )
Sprint nedir?
Sprint, seçilen kullanıcı hikayelerini belirli bir süre içinde uygulamamız gereken küçük süredir. Sprint süresi yaklaşık 2 ila 3 hafta olacaktır. Süresi firmadan firmaya değişmektedir.
Bu sprint süresinde, takımın gereksinimi analiz etmesi, gereksinimleri tasarlaması, kodlama yapması, test etmesi, sorunu çözmesi, yeniden test etmesi, regresyon testi, demo ve daha birçok aktivite yapması gerekir.
Günlük Standup Scrum toplantısı
İş Analisti, Geliştirici, Test Uzmanı ve Proje Yöneticisi günlük ayağa kalkma toplantılarının bir parçasıdır. Günlük yapılır. 15 ila 30 dakikadan fazla sürmemelidir.
Burada tüm ekip üyeleri günlük çalışma durumunu paylaşacak. Burada tartıştığımız ana şeyler şunlardır: dün tamamlanan şeyler nelerdir, bugünün çalışması için plan ve projede karşılaştıkları zorluklar veya bağımlılıklar.
Herhangi bir ekip üyesi proje sırasında herhangi bir zorluk veya engelle karşılaşırsa, ilgili kişi bunu tamamlamak için çalışacaktır.
Açılış tablosu
Zamanın ve işin resimli bir grafik temsilidir. X ekseni kalan işi, y ekseni kalan sprint süresini temsil eder. Takım, belirli bir sprintte mevcut olan zamanla ilgili iş görevlerini oluşturmalıdır. Ekip, çalıştığı ve tamamladığı işe göre görev saatlerini günlük olarak yakacaktır.
(resim kaynak )
Kanban Grafiği
Bir proje yönetim şeması / aracıdır. Bununla tüm projenin görevlerini yönetebiliriz. Proje ilerleme durumunu ve bireylerin çalışma durumunu kontrol edebiliriz. İlerleme öğeleri, bekleyen öğeler ve bitmiş öğelerin resimli dijital temsilini gösterir.
(resim kaynak )
.net c # mülakat soruları
Poker Aktivitesini Planlamak
Kullanıcı hikayelerini tahmin etmek için sprint ekibi üyeleri arasında oynanan bir oyundur. Burada tüm takım poker aktivitesini oynayacak. Her ekip üyesi, kullanıcı hikayesi noktasına göre tahmini verir. Ekip, çoğunluk tahmin oylarına dayanarak, zaman aralığına karar verecek ve tahsis edecektir.
Örneğin , bir kullanıcı hikayesi ekip üyesi 3, 5, 8, 3, 1, 3 gibi bir tahmin verecektir. Ardından ekip tahmin olarak 3'ü seçecektir. Poker aktivite kartında 0, 1, 3, 5, 8, 13, 20, 100, ara, şüpheler var mı? kartları. Bu ekip üyelerine dayanarak herhangi bir tahmin kartı önerecektir. Bunun gibi, belirli sprint ile ilgili tüm kullanıcı hikayelerini tahmin edeceğiz.
(resim kaynak )
- 0 poker numarası şunları temsil eder: o öğede / kullanıcı hikayesinde görev yok
- 1, 3 sayı şunları temsil eder: görev daha az
- 5, 8 sayı şunları temsil eder: orta seviye görevler
- 13, 20 sayı şunları temsil eder: büyük seviyeli görevler
- 100 numara şunları temsil eder: çok büyük görevler
- Infinity şunları temsil eder: Görev çok büyük, birden fazla göreve ve kullanıcı hikayesine bölünmesi gerekiyor
- Ara şunları temsil eder: Molaya ihtiyacım var
- ? Temsil eder: Şüpheler
Saldırı ustası
Ekibin Agile sürecini takip etmesine ve proje ihtiyacını karşılamasına yardımcı olan kişidir. Toplantıyı gerektiğinde yönetecek ve projenin ihtiyacını tartışmaya yardımcı olacaktır.
Scrum master, projeyle ilgili zorlukları ve bağımlılıkları çözmek için tüm ekip üyelerine bir köprü görevi görür. Her sprint ile ilgili proje ilerlemesini takip edecek.
Standup toplantı, retrospektif toplantı, inceleme, inceleme, demoya dahil oluyor. Günlük stand up toplantılarını yapan ve ekip üyelerini güncelleyen kişidir.
Ürün sahibi
Ürünü / projeyi iş açısından yönlendiren ve izleyen kişidir. Ürünün iş ihtiyacına göre geliştirilmiş olup olmadığını izlemeye devam ediyor. Kullanıcı hikayelerine öncelik veren ve gereksinimleri ürün birikiminden sprint iş yığınına taşıyan kişi o. Proje son tarihlerini tahmin edecek.
Ürüne her zaman kullanıcının bakış açısından bakar. Ürün sahibi, uygulamanın nasıl çalışması gerektiği konusunda tam bilgiye sahiptir.
Kullanıcı hikayesi
Bu bir gereklilik bloğudur. Aynı modül ile ilgili kullanım durumları / gereksinimi setini içerir. Burada, bir uygulamanın her bir bileşeninin nasıl çalışması gerektiğini ve kullanıcı arayüzünün nasıl görünmesi gerektiğini tanımlıyoruz. Her bileşenin kapsamı kullanıcı hikayesinde tanımlanmıştır.
Görevler
Ekip üyeleri, kendilerine atanan kullanıcı hikayesi için görevi oluşturacaklar. Geliştirme görevi, test görevi, kullanıcı hikayesi analizi görevi gibi farklı görevlere dayalı olarak görevi oluşturmaları gerekir. Görev süresi, kullanıcı hikayesi puanlarına bağlı olmalıdır.
Bir test uzmanı olarak, kullanıcı hikayesi analizi, test senaryosu hazırlama, yürütme, regresyon testi ve çok daha fazlası için görevler oluşturacağız.
Bakiye Bakımı
Bu bölüm, biriktirme öğelerinin yönetilmesini içerir. Burada yaptığımız faaliyetler, biriktirme kalemlerine öncelik vermek, daha küçük öğelere bölmek, görevi oluşturmak ve kabul kriterlerini güncellemektir.
Yineleme
Yineleme, yazılım uygulamasının bazı modüllerinin / parçalarının geliştirilmesi ve test edilmesidir. Her bir yineleme, ürünün analizinden, ürünün tasarımından, ürünün geliştirilmesinden, ürünün test edilmesinden ve ürünün demosundan oluşur.
Çevik Metodolojiyi Benimsemek İçin Temel Faktörler
- Gözlem: Çalışmayı ve ürünü düzenli olarak gözden geçirin ve faaliyetleri buna göre planlayın. Yani ürün geliştirme süreci ve ürün kalitesi iyi olacak.
- Hoş Geldiniz Değişiklikleri: Değişiklikler çok kolay halledilir. Yazılım modülleri ayrı ayrı geliştirilip sonradan entegre edildiği için ürün üzerinde fazla bir etkisi yoktur. Bu nedenle, gereksinim gelecekte değiştirilirse yeniden çalışma yapılmayacaktır.
- Zaman aralığı: Başvurunun her birimi için bize zaman çerçevesi verilmiştir. Dolayısıyla tahmin, proje süresi tahminlerine göre doğru olacaktır.
- Müşteri memnuniyeti: Müşteri memnuniyeti daha fazladır çünkü proje boyunca müşteri ve hissedar ile etkileşim kurarız ve her ürün geliştirme seviyesinde bir demo vereceğiz. Böylelikle iş akışları ve iş ilerleyişi hakkında müşteri / müşteri geri bildirimlerini düzenli olarak alıyoruz. Böylece uygulamanın çalışması ve geliştirilmesi buna göre yapılır.
Çevik Metodoloji Türleri
- Çevik Scrum Metodolojisi
- Yalın Yazılım Geliştirme
- Kanban
- Ekstrem Programlama (XP)
- Kristal
- Dinamik Sistem Geliştirme Yöntemi (DSDM)
- Özellik Odaklı Geliştirme (FDD)
Çevik Artılar:
- Çevik modelin en büyük avantajlarından biri, harika uyarlanabilirlik . Uyarlanabilirlik, 'değişime yanıt vermek' demektir. Çevik, müşteri ihtiyaçlarındaki ve önceliklerindeki değişikliklerle başa çıkmada çok esnektir.
- İzin verir genel ürün birikimini sürekli olarak iyileştirin ve yeniden önceliklendirin Takımın MVP'yi sunmaya odaklandığı mevcut yinelemeyi etkilemeden. Değişiklikler bir sonraki yineleme için planlanabilir, böylece değişiklikleri yalnızca birkaç hafta içinde getirme fırsatı sunar.
- Çevik metodoloji büyük ölçüde paydaş katılımı . Müşteri ve proje ekibi her sprint öncesinde, sırasında ve sonrasında bir araya gelir. Müşteri proje boyunca sürekli olarak yer aldığından, ekibin müşterinin vizyonunu net bir şekilde anlaması için daha fazla fırsat vardır.
- Çalışan yazılım erken ve sıklıkla teslim edilir. Bu artar paydaşın güveni ekipte ve ekibi teşvik eder son derece kararlı kal projeye.
- Bu model verir şeffaflık . Hem paydaşlar hem de ekip neler olup bittiğini çok iyi biliyor. Müşteri, devam eden işi görebilir.
- Bir ila dört haftalık sabit programlı sprintler, erken ve öngörülebilir teslimat . Yeni özellikler, zaman sınırlamalı bir şekilde hızlı ve sık sık yayınlanır.
- Çevik müşteri odaklı . Yalnızca işlevselliği sağlamakla kalmaz, aynı zamanda kullanıcıya değeri olan özelliği sunmaya da odaklanır. Her kullanıcı hikayesinin iş odaklı bir kabul kriteri vardır.
- Değerli müşteri geribildirimi kazanıldı erken projede ve üründe gerekli değişiklikler yapılabilmektedir.
- Odak noktası iş değeridir . Önce müşteri için en önemli olanı sunar.
- Çıktıların kalitesini iyileştirir . Şelalenin aksine, bir Agile projesinde test sürekli ve sık sık yapılır ve bu da sorunların erken tespit edilmesine ve düzeltilmesine yardımcı olur.
- Çevik TDD (Test Driven Development) yaklaşımını destekler MVP aracılığıyla piyasaya sürülecek özellikler için birim testleri oluşturmak için yeterli zaman sağlar.
- Ayrıca üreterek sık yapılan yapılar , müşteri gereksinimlerindeki herhangi bir yanlış hizalama da erken tespit edilip düzeltilebilir.
- Biz alırken anında kullanıcı geri bildirimi her MVP sürümünden sonra, proje başarısızlık riski düşüktür, Çevik bir şekilde çalışırken.
- Çevik takım çalışmasını teşvik eder . Agile ekip üyeleri arasında büyük bir işbirliği, etkileşim, uyum ve coşku var.
- Her bir sprint için maliyet ve program tahminleri, sprint başlamadan önce müşteriye iletilir. Bu karar vermeyi geliştirir Kullanıcı her bir özelliğin maliyetini anlayabilir ve buna göre öncelik verebilir.
- Çevik bir projede, sürekli gelişme . Geçmiş sprintlerden öğrenilen dersler gelecek sprintlere uygulanabilir.
- Projenin her aşamasında belirli göreve odaklanır.
Çevik Eksileri:
- Agile takımlarının bir belgeleri ihmal etme eğilimi . Bunun nedeni, Agile manifestosunun kapsamlı dokümantasyondan çok çalışan yazılıma odaklanmasıdır. Bununla birlikte, ekipler kod ve dokümantasyon arasında doğru dengeyi korumalıdır.
- Yüksek derecede müşteri katılımı gerektirdiğinden, bazen müşteriler için sorunlu olabilir projeye katılmak için fazla zamanı ve ilgisi olmayanlar.
- Ekip bağlılık ve adanmışlıktan yoksunsa, iyi çalışmaz. Waterfall katılım gerektirir, ancak Agile bağlılık gerektirir.
- İlk mimari ve tasarım zayıfsa, sık yeniden düzenleme gerekli.
- Şelale ile karşılaştırıldığında, Çevik uygulaması zor . Ekip üyeleri, Agile konseptleri konusunda bilgili olmalıdır. Agile'ı uygulamak çok fazla disiplin ve bağlılık gerektirir.
- Yeniden önceliklendirme nedeniyle, daha az tahmin edilebilir sprint sonunda teslim edileceğinden daha fazla.
- Zaman kutulu teslimat ve sık yeniden önceliklendirme nedeniyle, tahsis edilen zaman çizelgesinde birkaç özelliğin teslim edilememe ihtimali vardır. Bu yol açabilir ek sprintler ve ek maliyetler . Bu aynı zamanda şu sorunlara da yol açabilir: belirsiz zaman çizelgeleri .
- Şelaleye göre yapı eksikliği, disiplinli, son derece yetkin ve yetenekli ekipler gerektirir . Bu olmadan proje gerçekten zor olabilir.
- Kullanılabilirlik nihai çıktıya ait bir planın daha azı .
- Bazen Dış paydaş, Çevik yaklaşımı takip etmeye direnemez . Bu gibi durumlarda, Agile ile ilgili eğitim ve öğretim geniş bir kitleye gereklidir.
- Tüm ekip üyelerinin Proje yönetimine dahil olması gerekmektedir.
- Belgeler daha az ayrıntılıdır.
Agile Vs Şelale Modelleri Arasındaki Fark
Şelale ve Çevik Yazılım Geliştirme Yaşam Döngüleri arasındaki farklar aşağıda listelenmiştir.
Şelale | Çevik |
---|---|
Süreç, farklı aşamalara bölünmüş tek bir proje olarak ele alınır. | Süreç birden fazla projeye bölünmüştür ve her proje farklı aşamaların bir yinelemesine sahiptir. |
Şelale metodolojisi, ürünün yaşam döngüsünün her aşamasının bir sırayla gerçekleştiği bir modeldir. Bir şelaleyi andıran bu aşamalardan projenin ilerleyişi yavaş yavaş aşağıya doğru akmaktadır. | Çevik metodoloji, yinelemeli bir yaklaşımı izleyen bir modeldir. |
Bu model, tek seferlik toplu teslimata inanır. Ürün, SDLC'nin sonunda teslim edilir. | Bu model, belirli zaman aralıklarında çok sayıda küçük teslimat parçasına inanmaktadır. Her sprintin sonunda bir MVP (Minimum Canlı Ürün) verilir. |
Geleneksel ve eski moda bir yaklaşım. | Yeni ve modern bir yaklaşım. |
Tek döngü ve tek sürüm. | Tekrarlayan sayıda yineleme ve birden çok sürüm. |
Yazılım geliştirme yaşam döngüsünü farklı aşamalara ayırır. | Yazılım geliştirme yaşam döngüsünü sprintlere böler. |
![]() | ![]() |
Yapısal ve katı model. Projenin tanımını, özelliklerini ve tasarımını değiştirmek zordur. | Bu model esnekliği ile bilinir. Herhangi bir proje aşamasında istediğimiz zaman değişiklik yapabiliriz. |
Uzun vadeli planlama ölçeği. | Kısa vadeli planlama ölçeği. |
Müşteri ile geliştirici arasında uzun bir mesafe vardır. | Müşteri ile geliştirici arasında kısa bir mesafe vardır. |
Spesifikasyon ve uygulama arasında uzun süre. İş analisti, gereksinimi proje başlamadan önce toplar ve hazırlar. | Spesifikasyon ve uygulama arasında kısa süre. Ürün sahibi, her sprintte takım için gereksinimleri ve güncellemeleri hazırlar. |
Sorunları keşfetmesi uzun zaman alır. | Sorunlar hızla keşfedilir. |
Yüksek proje programı riski. | Düşük proje programı riski. |
Değişikliklere daha az tepki verme yeteneği. | Değişikliklere hızlı tepki verme yeteneği yüksektir. |
Test aşaması ancak geliştirme aşaması tamamlandıktan sonra gerçekleşir. | Kaliteyi sürekli sağlamak için testler genellikle gelişime paralel olarak yapılır. |
Müşteri yalnızca ihtiyaç toplama aşamasında yer alır ve bundan sonra müşterinin katılımı olmaz. Resme ancak ürünün teslimatı sırasında giriyor. | Müşteri proje boyunca yer alır ve müşteri memnuniyetini sağlamak için zaman zaman müşteriden geri bildirim alınır. |
Açıkça tanımlanmış gereksinimleri olan ve değişiklik beklemeyen projeler için uygundur. | Gelişmesi gereken ve değişen gereksinimleri içeren projeler için uygundur. |
Sıkı sıralı süreç. | Son derece işbirlikçi yazılım geliştirme süreci, daha iyi ekip çabalarına ve hızlı problem çözmeye yol açar. |
Proje zihniyetini sergiler. | Bir ürün zihniyetini ortaya çıkarır ve bu nedenle daha müşteri odaklıdır. Talepler ve değişiklikler sürecin bir parçasıdır |
Resmi ve hiyerarşik. Proje yöneticisi karar vericidir. | Gayri resmi. Tüm ekip karar vermekten sorumludur. |
Bu model, proje boyunca gereksinimlerde herhangi bir değişiklik olmayacağını öngörmektedir. | Bu model adaptasyona dayalıdır ve değişiklikleri kucaklar. |
Bireyin çalışmasının ve projenin ilerlemesinin durumunu doğrulamak için manuel belgeler oluşturmanız gerekir. | Projenin ilerlemesini ve kişinin çalışma durumunu doğrulamak için Kanban grafiğini ve Burn Down grafiğini takip eder. |
Agile ve Waterfall metodolojileri arasındaki farklar ve her birinin faydaları ve zorlukları hakkında yeterince tartıştık. Şimdi çevik test ile şelale testi arasındaki farkları inceleyelim.
Çevik Test ile Şelale Testi Arasındaki Farklar
Yazılım testi perspektifinden, Agile testinin Waterfall testinden ne kadar farklı olduğu hakkında adil bir fikre sahip olmak bizim için önemlidir.
Şelale Testi | Çevik Test |
---|---|
Test ekipleri ve geliştirme ekipleri net bir sınırla ayrılır ve aralarında sıkı ve resmi bir iletişim vardır. | Test ekibi ve geliştirme ekipleri tek bir ekip olarak entegre edilmiştir ve aralarında serbest bir iletişim akışı vardır. |
Test, geliştirme ve inşa aşamalarının tamamlanmasından sonra başlar. | Test, geliştirme aşamasıyla eşzamanlı olarak başlar. |
Planlama, test aşamasından hemen önce yapılır. | Planlama, proje başlamadan önce yapılır ve genellikle proje sırasında yapılır. |
Test planı proje sırasında nadiren gözden geçirilir. | Test planı her sprintten sonra gözden geçirilir. |
Test ekibinin şartlarda herhangi bir değişiklik önermesi oldukça zordur. | Test ekibi, gereksinim toplama ve değiştirme sürecine aktif olarak katılır. |
Tüm işlevler için test senaryoları bir kez oluşturulur. | Test senaryoları, her sprintte yayınlanması gereken işlevler için sprint ile oluşturulur. |
Kabul testi, yayınlandıktan sonra müşteri tarafından bir kez gerçekleştirilir. | Kabul testi, her yinelemeden sonra ve teslimattan önce bir iş analisti veya test ekibi tarafından yapılabilir. Daha sonra her sürümden sonra müşteri tarafından yapılır. |
Ayrıntılı ve kapsamlı test belgeleri. | Test dokümantasyonu sadece gerektiği kadar yapılır. |
Test tahminleri ve görevlendirmeleri genellikle test yöneticisinin sorumluluğundadır. | Test tahminleri ve görevlendirmeleri, tahminlerin sağlanması ve görevlerinin seçilmesinde yer alan ekibin ve test mühendislerinin ortak sorumluluğudur. |
Regresyon testi nadiren yapılır ve tüm test senaryolarının yürütülmesini içerir. | Gerileme testi, her yinelemeden sonra yapılır ve yalnızca gerekli olan test durumlarını içerir. |
Sonuç
Bu makalede, her modelin artılarını ve eksilerini kapsayan bir karşılaştırma tablosu ile modern Çevik yaklaşım ile geleneksel Waterfall yazılım geliştirme ve test yöntemi arasındaki kesin farkları öğrendik.
Bu yazıda listelenen tüm faktörleri göz önünde bulundurarak, yazılım uygulamasını geliştirmek için doğru yazılım geliştirme yaşam döngüsü modelini seçebiliriz. Şelale modeline göre Agile metodolojilerinin tercih edildiğini söylemekte hiç şüphe yok. Şirketlerin% 90'ı, yazılım Uygulamasını geliştirmek için Çevik iş akışını tercih ediyor ve takip ediyor.
Çevik metodoloji her türlü proje için iyidir. Şelale metodolojisini çok az şirket takip etmektedir. Bu metodoloji yalnızca uygulama küçük, basitse ve gereksinimde herhangi bir değişiklik yoksa uygundur.
Bazı durumlarda, ihtiyaçlara göre Spiral, V ve V ve Prototype adı verilen diğer yaklaşımları da tercih ediyoruz.
Umarım bu bilgiler, projeniz için en iyi modelin hangisi olduğuna karar vermenize yardımcı olur. Ayrıca Her yöntemin eksilerini ortadan kaldıran hibrit model - burada tartışılmıştır.
Önerilen Kaynaklar
- Örnek Olay: Şelale ve Çevik Geliştirme Süreçlerinin Kusurlarını Hibrit Model Kullanarak Nasıl Ortadan Kaldırılır
- SDLC Şelale Modeli nedir?
- Zephyr Kurumsal Test Yönetim Aracı İncelemesi - Çevik Araçta Şelale Modeli Varlıkları Nasıl Kullanılır
- VersionOne Eğitimi: Hepsi Bir Arada Çevik Proje Yönetimi Aracı Kılavuzu
- Jira Portföy Eğitimi: JIRA için Çevik Proje Portföy Yönetimi Eklentisi (İnceleme)
- 2021'de EN İYİ 10 En İyi Çevik Proje Yönetim Aracı
- Çevik Tahmin Teknikleri: Çevik Bir Projede Doğru Bir Tahmin
- Çevik Sürece Başarılı Geçiş için Çevik Test Zihniyetini Geliştirmeye Doğru 4 Adım