Hangi yazılım geliştirme metodolojileri temel olarak görülebilir

Yazılım geliştirme metodolojisini içeren küçük bir araştırma yazısı yazıyorum. Mevcut tüm metodolojileri araştırıyordum ve tüm metodolojilerden, diğerlerinin temellerini sağlayan herhangi bir şey olduğunu merak ediyordum.

Örneğin, aşağıdaki yöntemlere bakarak:
Çevik, Prototipleme, Temiz Oda, Yinelemeli, RAD, RUP, Spiral, Şelale, XP, Yalın, Scrum, V Modeli, TDD.

Şunu söyleyebilir miyiz: Prototipleme, İteratif, Spiral ve Şelale diğerleri için "temel" dir?

Yoksa "vakıf" diye bir şey yok mu ve her metodolojinin kendine özgü bir tarihi var mı?

Tabii ki araştırma metodumdaki tüm metodolojileri tanımlamak isterdim, ama bunu yapmak için yeterli zamanım yok ve bu yüzden hangi metodolojilerin temsilci olarak görülebileceğini bilmek istiyorum.

Listenizdeki adların tümü metodoloji değildir ve farklı düzeylerde ölçeklenir:

• Yinelemeli, çeşitli yöntem ve tekniklerle paylaşılan bir özelliktir. Scrum yinelemeli bir metodolojidir, TDD yinelemeli bir tekniktir.
• Agile'ı kavramsal / felsefi düzeyde kalan bir metodoloji süper kümesi olarak görüyorum. Nesne yönelimli programlamada onu soyut olarak tanımlayabilirsiniz - örneklenemeyen ve türetilmesi ve uygulanması gereken bir dizi değer ve ilkedir. Scrum ve XP bunu yapar.
• Temiz oda, RAD, RUP, Spiral, Şelale, XP, Yalın, Scrum, V-Modeli uygun metodolojiler, yani yazılım geliştirme süreçleridir (Scrum ağır bir sürecin aksine hafif bir "çerçeve" olduğunu iddia etse de)
• Prototip ve TDD teknikler, faaliyetlerdir. TDD bir XP uygulamasıdır.

Temeli zor olan bir işi ayırt etmek. Açıkça tarihsel bir çizgi çizebilirsiniz, ancak bir metodoloji nadiren doğrudan bir başkasına dayanır. Oldukça üst üste biniyorlar, birbirlerinden ödünç alıyorlar, bazen birbirlerine cevap veriyorlar ... Açıkça tanımlanmış bir sınıflandırma göremiyorum, ancak muhtemelen birkaç büyük aileyi özetleyebilirsiniz.

Ona bakmanın bir başka yolu da bir nesil perspektiften. Kurumsal yazılımlar açısından 2 nesil metodolojiyi bildiğimizi söyleyebilirim. Bunlardan ilki Şelale ve V-Modeli, yazılıma uygulanan diğer mühendislik disiplinlerinden çoğunlukla önceden var olan süreçlerdi. İkinci nesil (Agile diyebilirsiniz, ancak Agile terimi icat edilmeden çok önce başladı), insanların yazılımın tamamen farklı bir hayvan olduğunu ve iyi sonuç veren kriterler olduğunu fark etmeye başladığı ilk nesil süreçlerin ağırlığına tepki olarak başlatıldı. yazılım ve bu kriterleri sağlayabilecek adımlar gerçekten spesifikti ve hala araştırılması gerekiyordu.

Son olarak, yazılımda diğer disiplinlerden daha da fazla, metodolojilerin sadece işleri yapmak için uygulayabileceğiniz tarifler olmadığını unutmayın. Yazılım geliştirme, teknik yönler kadar insani yönlere sahiptir ve bir gümüş mermi metodolojisi ile gelen bir ekip veya yönetici ve körü körüne uygulanacak şeylerin bir kontrol listesi bazı sürprizler bekleyebilir. Yıllar süren Kaos Raporu gibi yazılım projesi başarı oranları üzerine yapılan çalışmalara bakarak, yazılım metodolojilerinin geçmişinin sağlam, bilimsel olarak oluşturulmuş, tekrarlanabilir süreçlerin kuralından çok bir dizi başarısız denemeyle ilgisi olduğunu söyleyebilirsiniz.

Üç vardır:

1. none (aka kovboy kodlaması)
2. şelale
3. hızlı uygulama geliştirme (RAD veya spiral)

gerisi bunların varyantları ve kombinasyonlarıdır

şelaleden gelen eserlerin (başlangıç, gereksinimler, fonksiyonel özellikler, tasarım özellikleri, test spesifikasyonları, kalite kontrol spesifikasyonları vb.) hepsinin, tümü diğer metodolojiler kapsamında olmasa da, proje için önemli olan şeyleri kapsadığını unutmayın. çok farklı yollar. Örneğin, TDD'de özellikler, kullanıcı hikayeleri ve test açıklamaları gereksinimleri, fonksiyonel özellikleri ve şelalenin test özelliklerini kapsar. RUP'ta, şelale özelliklerinin bir parçasını (örneğin Paydaşlar belgesi, Başlangıç ​​belgesinin bir parçasıdır) parçalayan ancak spiral bir şekilde ilerleyen daha fazla eser eklenir.

tamamlandığında sonuçlarınızın bağlantısını yayınlayın, kulağa ilginç bir yazı gibi geliyor!

Belki de sadece antik metodolojilerden ('metodolojiler değil) bahsetmek istersiniz:

1. toplu işlem: bir deste kart gönderin ve ertesi gün çıktıyı geri alın. Dezavantajları: gönderiler arasında çok fazla zaman; hata ayıklama için bir çekirdek dökümü inceleyin.

2. cli yöntemleri - vi veya emacs kullanın, sonra derleyin; tüm komut satırından bu güne kadar linux kabuğunda olduğu gibi. Dezavantajları: hata ayıklamak zor (gdb? Beni dinliyor musun?), Karanlık 40 yaşındaki kabuk komutları.

Sadece bir düşünce.

Üç temel yaklaşımdan bahsedebilirsiniz: Prototipleme, Spiral ve Şelale. Yalın, TDD veya Temiz Oda'yı bir metodoloji olarak değil, metodolojinin bir parçası olabilecek bir süreç olarak görmüyorum.