Waterfall yazılım geliştirme metodolojisi hala uygulanabilir mi?

Deneyimlerime göre, Şelale modelinin , modern yazılım geliştirme dünyasında uygulanabilir bir yöntem olarak kabul edilecek gereksinim değişikliklerine çok esnek ve yanıt vermediği kanıtlanmış gibi görünüyor . Daha çevik, yinelemeli yöntemlerin büyüme ve kanıtlanmış sicili, herhangi birinin, proje başlangıcından ürün dağıtımına kadar çok az değişiklik olduğunu veya hiç değişiklik yapmadığını varsayan sert bir blok sürecini takip etmesi için hiçbir neden olmadığını göstermektedir.

Şelale geliştirme metodolojisi, zaman, maliyet ve kalite açısından yazılım sistemleri sunmak için hala geçerli midir?

Bahsettiğiniz şelale modeli hiçbir zaman gerçek bir projede kullanılan bir süreç modeli olarak tasarlanmamıştır. Bunun yerine, bir strawman. Yazılım projelerinde var olan temel aşamaları ve faaliyetleri ve aralarındaki en temel akışı tanımlar. Yazılımın nasıl geliştirileceğinin bu kadar basitleştirilmesi hatalı bir yazılımdır ve hatta bu şekilde sunulmuştur.

Wikipedia makalesinden:

Şelale modelinin ilk resmi tanımı, Winston W. Royce tarafından 1970 tarihli bir makale olarak belirtilmiştir, ancak Royce bu makalede "şelale" terimini kullanmamıştır. Royce bu modeli kusurlu, çalışmayan bir modele örnek olarak sundu.

Tartışılan makale Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme başlığıdır . İçinde, Royce bu modeli ikinci sayfada sunar. Ancak, resimsel temsilin hemen altındaki metin okumaya devam ediyor:

Bu kavrama inanıyorum, ancak yukarıda açıklanan uygulama risklidir ve başarısızlığı davet eder.

Bunu, geliştirme aşamasının "tamamlanmasının" ardından yapılan testlerle ilgili problemler ve buradaki başarısızlıkların nasıl büyük yeniden tasarımlara ve kod değişikliklerine ve bunların maliyet ve programda nasıl büyük taşmalara yol açabileceği üzerine bir tartışma ile devam ediyor. Kağıt boyunca, orijinal modeli bir proje üzerinde gerçekten uygun olan bir modelle geliştirir. Sonunda, prototipleme, müşteri etkileşimi ve eserlerin geliştirilmesini tanıtan bir model ile sonuçlanır - sonunda 1990'ların sonunda ve 2000'lerin başında başlayan çevik hareket için kritik olacak fikirler.

Sorunuzu cevaplamak için: Sorduğunuz Şelale, zaman ve bütçeye uygun kalitede yazılım projeleri sunmak için uygun bir yöntem değildir ve asla geçerli değildir. Bununla birlikte, projelerde çalışabilen ve çalışabilen çevikliğin karşısında yatan başka plan odaklı yöntemler de vardır.

İnsanlar ders kitabı şelale modelini kullanmazlar ve muhtemelen hiç kullanmazlar.

Amacı, sistem geliştirmedeki adımlar hakkında düşünmenizi sağlamak olan idealleştirilmiş, teorik bir yapıdır. Ana nokta, daha büyük değişikliklerin mümkün olduğunca erken gerçekleşmesini istemenizdir, çünkü çok fazla kod oluşturulduktan sonra büyük bir değişiklik yapmak için asla zamanınız veya paranız olmaz.

Bir süreçten daha çok bir düşünme yolu olmasına rağmen, hala çoğu - muhtemelen çoğu kuruluşun yazılım (veya evler, denizaltılar veya başka herhangi bir şey ...) inşa etmeye devam etmesinin yolu.

Gerçek dünyada, aşamalar arasında tam olarak kesinti yoktur ve bazen küçük alt projeler için önceki aşamalara geri dönersiniz. Metodolojinin size söylediği şey "bunlara izin verilmez" değildir. Size söylediği şey "bu şeyler size para ve / veya zaman maliyeti" dir - bu yüzden bundan kaçınmaya çalışın.

Agile Snobs (TM) için burunlarını "eski moda" geliştiricilere ve tuhaf, işlenemeyen şelale metodolojisine bakmak iyi ve iyidir, ancak konunun gerçeği de Agile'ın her derde deva olmadığıdır. Bazı projeler Agile kullanılarak inşa edilemez ve Agile olduklarını düşünen birçok takım aslında sadece özensiz ve organize değildir.

Metodoloji mesele değildir. Mesele, ne yaptığınızı ve bunu neden bu şekilde yaptığınızı düşünmek ve en kısa sürede müşteriye en yüksek değeri elde etmektir.

Çoğu zaman çeviklikle karşılaştırılan efsanevi şelale süreci hiç var olmadı ve bu nedenle ölü olarak kabul edilemez. Gerçek şelale süreçleri hala canlı ve iyi durumdadır ve kullanıcı beklentilerini karşılayan bütçe yazılımları zamanında teslim etmede mükemmeldir.

Belki ne elde ettiğinizi sormanın daha iyi bir yolu, "ne zaman daha az yinelemeli ve daha resmi ne kadar iyi?"

Durumun böyle olduğu durumlar vardır:

• Gereksinimler değişmediğinde.

• Yeni gereksinimleri karşılarken, orijinal gereksinimlerin% 100'üne ulaşmaktan daha az önemlidir.

• Tüm teknoloji bileşenleri olgun ve iyi anlaşıldığında.

Bir anlamda sizi çevik olmaya iten şeyin tam tersini yapabilirsiniz.

Her yerde çok az teknik uygulanabilir. Çok azının faydası yok.

Evet, çok canlı, bugün kullanılan " V modeli " daha yaygın .

Her iki durumda da, Agile'nin sahip olduğu sorun, çözümün neredeyse hiç bitmemesidir, müşteri değişiklik talep etmeye devam edebilir ve geliştirme, bunları tekrar tekrar çözmeye devam edecektir. Zaman ve malzeme maliyetine dayalı bir proje için bu çok işe yarar. Sabit bir maliyeti olan bir proje için değil.

Bu sabit maliyetli projeler için, müşteri neredeyse her zaman önceden tanımlanmış kilometre taşlarının ilerleme göstermesini beklemektedir, ancak bunlar çalışma kodundan ziyade resmi yazılı çeşittir. Bu tür müşteriler için, yazılı spesifikasyonlar, yazılım geliştirmenin ikincil bir değerlendirme olduğu proje haline gelir (iyi tanımlanmış bir projeniz varsa, yazılımın geliştirilmesi kolay olmalıdır). Bu şirketler aynı zamanda ucuz, dış kaynaklı geliştirme kaynaklarından yoğun olarak yararlanan şirketlerdir.

Dolayısıyla, sabit bir paranız veya zamanınız varsa, gereksinimlerin değişmesini beklemeyin veya herhangi bir gereksinimin değiştirilmesine izin verilmiyorsa ve güçlü bir yazılı belge seti sağlamanız bekleniyorsa, o zaman şelale modelleri yalnızca mantıklı olmak.

Çevikliği bu projelerin ortasında geliştirme yapmak için kullanabilirsiniz, ancak yine de şartnamelerin gereksinimlerden yaratıldığı bir rampa aşaması ve yazılımın yerinde kurulduğu ve test edildiği bir rampa aşaması var. Agile bu vakalara iyi yanıt vermiyor.

Kime? Karşılaştığım yöneticilerin çoğu hala programlama için Şelale Yazılım Geliştirme Sürecini kullanıyor ve yukarı seviyeler kolay planlama için hoşlanıyor gibi görünüyor.

Pratik olarak, çok az geliştiricinin işe yaradığına veya hatta geçerli olduğuna inanıyorum.