Pek çok görüşmede muhtemelen size metodolojiler sorulacaktır. Bu en önemli veya zor soru değil, ancak bir kopya kağıdına sahip olmak güzel olurdu. Bu yazımızda geliştirme metodolojisinin ne olduğunu aktarmaya ve karşılaştırmaya çalışacağız. Bir yazılım geliştirme metodolojisi, belirli bir ürünü geliştirmek için kullanılan bir süreçtir, yani bir geliştirici ekibi tarafından geliştirmeyi organize etmenin bir yoludur. Her biri kendi yaklaşımını tanımlayan birçok farklı geliştirme modeli vardır. Her projede bunlardan birinin kullanılması gerektiği söylenemez. Doğru yaklaşım tamamen duruma bağlıdır. Bunlardan üçünü daha ayrıntılı olarak ele almak niyetindeyim.
Şelale
Şelale metodolojisi en eski yöntemlerden biridir ve kesinlikle sıralı bir uygulamayı içerir: her aşama bir sonraki başlamadan önce tamamlanmalıdır. Diğer bir deyişle, bir sonraki aşamaya geçiş, bir önceki aşamanın çalışmasının %100 tamamlanmış olduğu anlamına gelir. Resim nasıl çalıştığını gösteriyor: önce sorunu analiz ediyoruz (görevleri belgeliyoruz, zorlukları tartışıyoruz), sonra tasarlıyoruz (projenin yapısı bu aşamada şekilleniyor) ve sonra kodlayıp test ediyoruz. Önceki aşamalara dönüşe izin verilmez. Bu yaklaşım, gereksinimlerin önceden bilindiği ve değişme olasılığının düşük olduğu küçük projeler için önerilir. Avantajlar:
Her aşamada eksiksiz ve tutarlı dokümantasyon
Kullanım kolaylığı
Kararlı gereksinimler
Bütçeler ve son tarihler önceden tanımlanmıştır
Dezavantajları:
Büyük miktarda belge
çok esnek değil
İstemci, ürünün demo sürümünü göremiyor
Geriye doğru hareket etme seçeneği yok
Scrum
Scrum, tüm süreci iterasyonlara bölen bir yazılım geliştirme metodolojisidir. Her etkileşimin sonunda ekip, ürünün demo sürümünü sağlamaya hazırdır. Resim, ekibin geliştirmenin tüm aşamalarında paralel olarak ilerlediğini ve her yinelemenin sonunda projenin bitmiş bir parçasına sahip olmayı mümkün kıldığını gösteriyor. Metodolojinin özünü basit kelimeler kullanarak kısaca açıklamaya çalışacağım, ancak çok fazla terminoloji var. Bence en önemli şey özü anlamak. Terminolojiyi deneyimle hatırlayacaksınız. Tüm gelişim sprintlere ayrılır (genellikle 2-3 hafta). birikmiş iş var(görev listesi) tüm geliştirme dönemi ve her bir ayrı sprint için. Her görevin kendi hikaye noktası vardır (zorluk derecesi). Süreçteki her katılımcının bir rolü vardır:
Scrum ekibi, bir proje üzerinde çalışan profesyonellerden (geliştiriciler, testçiler, tasarımcılar) oluşur.
Scrum ustası, scrum ilkelerine uyulmasını sağlayan kişidir.
Ürün sahibi müşteridir.
Bu metodoloji iletişime dayanır, bu nedenle çok sayıda toplantı vardır:
Stand-up – Bu, her gün yapılan ve tüm ekip üyelerinin katıldığı kısa bir toplantıdır. Her katılımcı 3 soruyu yanıtlar: Ne yaptım? Ben ne yapacağım? Ve hangi engelleme sorunları var?
Planlama toplantısı – Bu toplantı sprintin başında yapılır. Bir sonraki sprintte yapılması gereken görevler bu toplantıda belirlenir.
Retrospektif - Bu toplantı sprint sonunda yapılır ve amacı nelerin iyi yapıldığını ve nelerin iyileştirilebileceğini belirlemektir.
Avantajlar:
Müşteri, geliştirme sürecinde sonuçları görebilir
Geliştirme sürecinin günlük olarak izlenmesi
Geliştirme sırasında ayarlamalar yapabilme
Tüm ekip üyeleri ile kurulan iletişim
Az miktarda belge
Dezavantajları:
Geliştirme için gereken işçilik ve diğer maliyetleri değerlendirmek zor
Geliştirme başlamadan önce darboğazları belirlemek zor
Herkesi diğer ekip üyelerinin çalışmalarına dahil etme ihtiyacı.
Kanban
Kanban, ekibin görevlerini tamamlamada kaydettiği ilerlemeyi görselleştirmeye dayalı bir yöntemdir. Ana fikir, şu anda gerçekleştirilmekte olan görevlerin sayısını azaltmaktır ("Devam Ediyor" sütununda). Scrum'da ekip, sprintleri başarıyla tamamlamaya odaklanır. Kanban'da görev üstün bir konuma sahiptir. Bu, temel işlevlerin zaten uygulanmış olduğu ve minimum iyileştirmelerin ve hata düzeltmenin kaldığı bakım aşamasındaki projeler için iyidir. Kanban'da görevler ayrı ayrı atanır. Bir görev, diğer görevlerden bağımsız olarak panodaki tüm aşamalardan geçer ve tamamlandığında müşteriye gösterilebilir. Bir Kanban panosu, her biri ayrı bir geliştirme sürecini temsil eden sütunlardan oluşur. Bazı sütunlar (örneğin, "Devam Ediyor" ) tutabilecekleri görev sayısını sınırlayın. Bu, görev dağılımındaki sorunlu alanları hızlı ve kolay bir şekilde bulmanıza yardımcı olur. Resim, böyle bir tahtanın bir örneğini göstermektedir. Sütun sayısı ve adları değişebilir. En yaygın olanı sunacağım:
Yapılacaklar – Yapılması gereken görevlerin listesi
Devam Ediyor – Şu anda üzerinde çalışılan görevler
Kod İncelemesi – Yapılan ve inceleme için gönderilen görevler
Test Ediliyor – Test için hazır görevler
Bitti – Biten görevler
Avantajlar:
Kullanım kolaylığı
Görünürlük (darboğazların bulunmasına yardımcı olur, anlayışı basitleştirir)
Sürecin kendisine yüksek ekip katılımı
Son derece esnek geliştirme
Dezavantajları:
Kararsız bir görev listesi
Uzun vadeli projelere uygulanması zor
Zor son teslim tarihlerinin olmaması
Yazılım geliştirme metodolojileri hakkında son bir söz
Yönetim pozisyonlarına sahip olan veya olmayı hedefleyen kişiler, yazılım geliştirme metodolojilerini tam olarak anlamalıdır, ancak herkesin en azından temelleri anlaması gerekir. Metodolojiler, geliştirme sürecinin ayrılmaz bir parçasıdır ve yalnızca BT alanında kullanılmaz. Yazımı okumak için zaman ayırdığınız için teşekkür ederim. Umarım size yardımcı olmuştur. Yalnızca kilit noktaları mümkün olduğunca erişilebilir ve öz bir şekilde açıklamaya çalıştım. Sonuç olarak, bu makale ayrıntılı değildir. Bu konudaki görüşlerinizi duymaktan ve sorularınızı yanıtlamaktan memnuniyet duyarım. Herşey gönlünce olsun!
Avantajlar:
Metodolojinin özünü basit kelimeler kullanarak kısaca açıklamaya çalışacağım, ancak çok fazla terminoloji var. Bence en önemli şey özü anlamak. Terminolojiyi deneyimle hatırlayacaksınız. Tüm gelişim sprintlere ayrılır (genellikle 2-3 hafta). birikmiş iş var(görev listesi) tüm geliştirme dönemi ve her bir ayrı sprint için. Her görevin kendi hikaye noktası vardır (zorluk derecesi). Süreçteki her katılımcının bir rolü vardır:
