Çevik kalkınma metodolojisine uygulanabilir bir alternatif var mı?


47

İki baskın yazılım geliştirme metodolojisi şelale ve çeviktir. Bu ikisini tartışırken, onları ayırt eden belirli uygulamalara çok fazla odaklanılır (çift programlama, TDD vb. İle işlevsel özellik, büyük ön tasarım, vb.)

Fakat asıl farklar çok daha derin, çünkü bu uygulamalar bir felsefeden geliyor.

Şelale diyor ki: Değişim masraflıdır, bu yüzden minimize edilmelidir.
Çevik diyor ki: Değişim kaçınılmazdır, bu yüzden değişikliği ucuza yapın.

Benim sorum, TDD veya işlevsel özellikleri hakkında ne düşündüğünüze bakmaksızın, şelale geliştirme metodolojisi gerçekten uygulanabilir mi?

Gerçekten de, yazılım değişimini en aza indirmenin değerli bir yazılım sunmak isteyenler için uygun bir seçenek olduğunu düşünüyor mu? Yoksa, kaçınılmaz değişimi yönetmek için durumlarımızda hangi tür uygulamaların en iyi şekilde çalıştığı ile ilgili bir soru mu var?


1
ilginç soru. cevapları bekliyorum.
DevSolo


3
@FarmBoy - Güzel soru. Çevik felsefeyi biraz daha farklı görüyorum. “Agile diyor ki: Değişim kaçınılmazdır, bu yüzden değişimin maliyetini belirlemeyi ucuz yapın” derdim. Değişim hala çok pahalı olabilir, ancak çevik olarak bunu hızlı ve ucuz bir şekilde anlayabilirsiniz, böylece değişimin maliyetini her zaman biliriz. Başka şekilde ifade etmek, insanların çevik değişim yaptıkları için ucuz olacağını düşündürüyor. Süreç ne olursa olsun bazı değişiklikler çok pahalıya mal olur.
Mike Two

1
@Yannis Rizos: Neden bu ilginç soruyu tek bir topluluk oyu olmadan tek başına kapatıyorsun?

1
Pierre303 @ nedeniyle bu tartışma soruya burada bu soruyu gündeme getirdi.
Ryathal

Yanıtlar:


59

Elbette şelale uygulanabilir. Bizi aya getirdi!

Ve burada konuşan çevik bir koç!

Projelerinizi yönetme biçiminizle ilgili sorunları açıkça belirlemediğiniz sürece, değiştirmek için geçerli bir neden yoktur.

Çevik ve Şelale metodolojilerinin bir alternatifi olarak , SİZİN metodolojisini önereceğim . Özel işinize, özel ekibinize, ürünlerinize, çalışma şeklinize, şirket kültürünüze uyarlanmış ... Bu yüzden Scrum'a metodoloji yerine basit bir çerçeve denir .

Metodolojiyi uygulamak istemek, çünkü hakkında konuştuğunuz bir blogda yer alan biri, sorun yaşamadan bir şey yapmadan devam etmek kadar salakça.


10
SİZİN metodolojisinde +1, bir sonraki Çevik antrenör bana SCRUM'u söyleyen tek yolun arka tarafa geçmesini sağlayacak;)
Martijn Verburg

1
@ karianna: Özellikle SCRUM yapıyorum, ancak bazen uygun değil. Öte yandan, SCRUM'u patronlarına, problemlerini çözeceğini düşünerek satmaya çalışan bir ekip gördüm. Başarısız oldular çünkü sorun patronları ya da başbakanları değildi. Tek bir kural yok. Her durum kendi çözümü. Ve evet, çoğu organizasyon sorunu çevik tekniklerle çözülebilir, ancak çevik gümüş bir kurşun değildir.

5
Sadece ay değil. Uzay mekiğinin gömülü sistemlerinde ~ 1M C kod satırı vardı. ~ 30 yıldan fazla bir süredir, yalnızca üretim hatalarını yapan 2 hata vardı.
Dan Ne

2
Şelale ayrıca ilk üç astronotu da öldürdü. Bu Apollo programını şelale posteri çocuğu olarak kullanmaktaki ısrar, en iyi şekilde cahildir. Waterfall ayrıca, her iki programın da tam bir finansal gözlük oluşturmasından ve Mekik orijinal teknik bir “uzay aracı” için kullanıldığında aşırı mühendis, kırılgan, pahalı bir “ferrari” olarak sorumlu olarak belirtiliyor. SpaceX'in Waterfall konusunda hemfikir olamayacağından eminim.

4
@DanNeely uzay mekiği yazılımının yüksek kalite seviyesi ucuz değildi. Görünüşe göre fiyat kod satırı başına 1000 $ boyutundaydı .

21

Öncelikle ifadelerinize katılmıyorum:

Şelale diyor ki: Değişim masraflıdır, bu yüzden minimize edilmelidir.
Çevik diyor ki: Değişim kaçınılmazdır, bu yüzden değişikliği ucuz yapın.

Benim yorumum:

Şelale diyor: Müşteri ne istediğini biliyor.
Agile diyor ki: Müşteri ne istediğini bilmiyor bu yüzden birkaç farklı versiyon yapmak zorunda kalacağız.

Gördüğüm "şelale" nin en iyi uygulaması, çok büyük bir finansal müşteriyle büyük bir entegrasyon projesiydi ve yaklaşık 40+ alt proje vardı. Sağladığımız masaüstü ve web sitesi paketi, bu 40+ alt projenin sadece 1'i. Diğer insanların parasını çok fazla harcadıklarını düşünürken, eşyalarını bir arada tutuyorlardı ve 40+ farklı gemiyi oluşum halinde birlikte hareket ettiriyorlardı. Proje, hedef tarihte ( proje boyunca bir kez hareket eden hedef) yayına girdi ve ben bunu daha verimli ve daha agresif bir şekilde yapabileceklerini düşündüm. Canlı gece takvimi yaklaşık 100 sayfa uzunluğundaydı ve bu sayfaların yaklaşık 40'ı ilgili her türlü insanın acil panik iletişim bilgileriydi. Bu müşteriden çok etkilendim.

Veya, biz etrafında koşmak ve en son şikayet / hata raporu olanı yapmak hangi, ne yapmak ve diyebiliriz o becerikli.



11
Daha çok "Şelale diyor: Müşteri ne istediğini bilmiyor bu yüzden hadi oturalım, konuşalım ve hacklemeye başlamadan önce ne istediğine
karar verelim

+1: Çok iyi cevap. Çevik toplumun tek bir temel sorunu olduğunu düşünüyorum: Çevik, belirli proje ve müşteri sınıfları için belirli bağlamlarda iyidir, ancak gereksinimlerin bu kadar hızlı ve daha yapılandırılmış yaklaşımların daha iyi bir seçim olduğunu değiştirmeyen projeler olduğunu görmekte başarısız olurlar. . Çevik topluluğun, yaklaşımlarının daha iyi bir seçim olduğu alanları gerçekçi bir şekilde tanımlamaya çalışması gerektiğini düşünüyorum (bu tür alanların var olduğunu düşünüyorum) ve bunu genel bir çözüm olarak itmeye çalışmayın, çünkü öyle değil.
Giorgio

6
@scrwtp - ve Agile daha çok "Müşterim ne istediğini bilmiyor, konuşamıyor ve düşünmüyor / düşünemiyor ve her 5 dakikada bir fikrini değiştiriyorlar. Yüzlerinde bir şey kıpırdamak zorundayım anlamlı cevaplar almak için ". Vay. Bunu yazarken talihsiz geliyor.
Michael Kohne

1
@ scrwtp: Bence milyon dolarlık soru şudur: "oturup" konuşup hemfikir olabileceğiniz "inancı" uygulanabilir mi? Cevap: bağlıdır, doğru mu? Bir dizi değişkene bağlıdır: proje ne kadar büyük? Ne kadar büyük olduğunu bile biliyor muyuz? Müşterilerin bizimle ne kadar "oturması" gerekir? On yıllardır, neredeyse% 100 kurallayıcı olan yazılım geliştirmeyi inşaatla ilişkilendirmeye çalıştık. Yazılım geliştirme, "tamamen gerici" ve "% 100 kurallayıcı" arasında ortada bir yerdedir. Çoğu mağazada, "tamamen gerici" ye yakın, bu nedenle çevikliğin benimsenmesi.
Calphool

21

Şöyle söyleyerek başlarsınız:

İki baskın yazılım geliştirme felsefesi şelale ve çeviktir.

Bu yanlış. Bu ikilik, çevik toplum tarafından kendilerini konumlandıracak bir rakip oluşturmak amacıyla yapılmıştır. Çevik modaya girmeden önce, insanlar bina yazılımına sayısız farklı yaklaşımdan bahsederdi. Bugün hala varlar, ancak bir şekilde çevik savunucular tarafından "şelale" adı verilen büyük bir karışıklığa toplanmışlar.

Ben kullanıyorum AÇIK / Metis büyük bir başarı ile 10 yıldır ve türevleri. Kesinlikle çevik ve kesinlikle şelale değil. Binlerce geliştirici, her gün çevik olmayan yöntemler kullanarak uçaklar, hayati öneme sahip sistemler, bankacılık vb. İçin son derece karmaşık yazılımlar üretiyor.

Yani evet, elbette çevikliğe karşı uygulanabilir bir alternatif var.


6
OPEN / Metis'in bu bağlantıdan ne olduğunu hızla anlayamıyorum. (Genellikle bir metodoloji indirmenize gerek yoktur.) Sorum şu: felsefe nedir, özellikle değişim ile uğraşırken? Değişimi en aza indirmeye mi, yoksa değişim maliyetini düşürmeye mi çalışıyor? Sorumun çevik uygulamalar hakkında değil, çevik felsefe ile ilgili olduğunu unutmayın.
Eric Wilson

OPEN / Metis, kademeli olarak sistemler inşa eden yinelemeli bir yaşam döngüsüne sahiptir. Değişimin, sadece gerçekleşecek bir şey değil, gerçekleştiği zaman büyük olan bir şey olduğu kabul edilir , çünkü bir bilgi sisteminin geliştirilmesinin amacı bir değişimin gerçekleşmesidir. Bununla birlikte, değişimin maliyeti, uygun bir yaşam döngüsü ve ilgili uygulamalar yoluyla kontrol edilir ve yönetilir.
CesarGon

1
"Metodolojileri indirme" konusundaki görüşünüzle ilgili olarak, ... metodolojileri indirmiyorsunuz, kabul ediyorum. Metodolojileri açıklayan belgeleri indirirsiniz. Aksi takdirde, onları nasıl öğrenirsiniz? XP, Scrum, vb.
Tanımlayan


10

Evet, sorunlu alanınıza bağlı olarak çeşitli yazılım geliştirme teknikleri uygulanabilir. "Dersler için Atlar".

Örneğin, bir Nükleer enerji santralini kontrol etmek veya NASA uzay mekiğini sürmek için yazılımlar yazıyorsunuz. Bu tür bir sorun alanı muhtemelen bir şelale (hatta daha katı) yaklaşımı için daha uygundur, mümkünse (veya BOOM!) Mümkünse tüm sorunları çözmek istiyorsunuz.

En son web 2.0 / 3.0 / buzzy pazarlama terimini kullanan kullanıcı arayüzü Çevik olmak daha iyi bir yoldur (bu hızlı geri bildirime ve değişime ihtiyacınız vardır).

Metodoloji ne olursa olsun yine de uygulanabilecek yazılım işçiliği prensipleri dediğim şey var.

  • Kaynak kontrolü
  • yapı ve CI
  • çiftler programı
  • TDD
  • ^% $$ veririm

ve dahası.

Ne yaparsanız yapın, denklemin her iki tarafındaki zilotları dinlemeyin, sizin için, ekibiniz ve problem alanınız için doğru olanı yapın.


Eğer karşılayabiliyorsanız şelale çalışıyor. Yukarıdaki kişiler NASA'nın ay projesi yazılım maliyetinin kod satırı başına yaklaşık 1000 $ olduğunu iddia etti. Çoğu dükkan kod satırı başına 1-10 $ gibi bir şeye ihtiyaç duyar ve çevik bu tür durumlar için daha iyidir. Ancak, çevikliğin genel olarak daha iyi kalite sağladığını iddia etmiyorum. Temelde yazılımın doğru olduğundan emin olmak için çok para harcayabiliyor musunuz ya da yazılımın doğru olmadığını öğrendikten sonra çözümü bulmak daha mı ucuz oluyor.
Mikko Rantalainen,

2

Sorun, yazılımın karmaşıklığından kaynaklanıyor. Şelale, köprü yapımı ve yol kaplamaları gibi işler için harikadır, çünkü fizik hiç değişmez. Elbette, bir noktada yeni bir asfalt geliştireceğiz, ancak yolların yapımında bir devrim yaratmayacak. Bir köprünün süspansiyonundaki çelik ya doğru boyutta ya da değil. Yazılımla olduğu gibi gerçek bir inşaat projesini kirletemez veya tasfiye edemezsiniz.

Yazılım değişiklikleri Yazılım hızla değişiyor. Moore kanunu bir çip üzerindeki transistörlerin sayısının her 18-24 ayda bir iki katına çıktığını belirtir. Sonuç olarak, bir programdaki kod satırı sayısı da iki katına çıkar. Bu nedenle, bu kod satırları arasındaki karmaşıklık, 2 ^ (2t) gibi büyük bir OO ile artar.

Yazılım hızla değişiyor ve karmaşıklığı da katlanarak artıyor.

Yazılımın maliyetini kontrol ederken , yalnızca çarpma veya katkı maddesi değil, üstel faktörleri kontrol etmek istersiniz . Kodun değiştirilmesi karmaşıklığı arttırır (ve proje ilerledikçe katlanarak daha da karmaşıklaşır) üstel bir şekilde.

Değişim ise kaçınılmaz. Programlamanın doğası, dili sınıflar ve özel yöntemlerle genişletir, böylece dili değiştirir. Bunu başka bir mühendislik disiplinde yapamazsınız (yol yapımında olduğu gibi. Sadece kansas'taki California'da bir yol açmak için yeni kaldırım icat etmiyorsunuz).

Çevik yöntem ayrıca size gelecekteki sürümleri ve hata düzeltmelerini işlemek için bir platform sunar. Sürümlü yazılım geliştirmek için yönetim araçlarına, işlemlerine, eğitimli çalışanlara sahip olursunuz. Bir şelale yöntemiyle, küçük hata düzeltmeleri bile için ekibinizi yeniden eğitmeniz gerekir.

Neyse, benim 2 kuruş.


2
Fizik yasaları kadar kesin olan yazılım tasarımının birçok yönü vardır. Çevik bir şelale veya diğer metodolojiler gibi bir araçtır ve yayınlanan diğer insanlar gibi anlamsız olduğu birçok iş vakası vardır. Boeing'in uçuş kontrol yazılımında çevik bir sürecin ortasında olduklarını söylediği bir uçağa binmek için sıraya girsem sizi şaşırırdım ve uçağın hayır havasında uçup gitmediğini yinelemeleri için müşterilere ihtiyaçları vardı. sebep.
Hounshell

Ve sadece argümanınızdaki av tüfeğine daha fazla delik açmak için, şu anda Kansas ve Kaliforniya arasındaki bir yol için uygun olan, ancak New York ve Boston arasındaki bir yol için uygun olmayan yol tasarımları var . Asfaltın işlenmesi için yeni teknikler her zaman ortaya çıkıyor.
Hounshell

2
Son olarak, “Bir şelale yöntemiyle, küçük hata düzeltmelerini bile halletmek için ekibinizi yeniden eğitmeniz gerekir.” Diyorsunuz. Bu şelale işleminin nasıl yürüdüğü konusunda çok cahil. Her yazılım geliştirme senaryosu için ne kadar uygunsuz olduğunu anlamadan önce, iyi bir şelale mağazasını denemelisiniz.
Hounshell

1
Merhaba Stephan, tüm yazılım gereksinimleri sürekli değişmiyor.
Paul Nathan

1
İş her zaman değişir ; Değişmeyen ve uyum sağlamayan bir işletme, ölmekte olan bir iştir. Zaman, değişimle iyi etkileşimde bulunmayan bir sabittir . Değişimi beklediğini kabul eden bir felsefeye sahip olan bir sistem , değişimin yerine getirilmesini sağlayabilir, aksi halde Zaman değişimin yerine getirilmesi gerekir ve bu bir yeniden yaratma sabitidir!

2

Soruyu cevaplamak için, en azından genel durumda, belki de değil - henüz olmasa da, yazılım için uygun bir alternatif var mı? Yazılımın niteliğine bağlı olduğunu düşünüyorum. Yazılım, bilgi olarak ücretsiz kopyalanabilir. Bir köprünün veya bir evin aksine. Bu, pratikte, bir ev inşa etmede iyi olabileceğim ve nispeten basit bir alanda çalıştığım anlamına gelir. Hangi noktada tek seferlik bir yaklaşım kullanmıyorsunuz?

Ancak yazılımın sıfır çoğaltma maliyeti olduğu için neden aynı şeyi iki kez yaptınız? Yazılım imalattan uzak durur. Bu nedenle, eğer tüm yazılımlar yeni ürün yaratıyorsa, her zaman ne yaptığımızı bilmediğimiz karmaşık bir alanda çalışırız. Veya önünü bilmek pahalı ve bunu yaparak öğrenmek daha ucuz. Karmaşık, riskli bir alanda, deneyleri denemek, arttırmak ve yinelemek istiyorum.

Nükleer santraller ve uçuş teli sistemleri genellikle şelale yapmak istediğiniz yazılımlara örnek olarak verilmektedir. Ancak mekik aviyonik sistemi tekrarlı bir şekilde gelişmedi mi? Kanada ve ABD hava trafik kontrol sistemleri nasıldı?

OPEN / Metis yinelemeli ve artımlıysa, o zaman benim için, kendini diğer ortak çevik uygulamalarla ilişkilendirmese bile, çevik felsefeye sahip gibi görünüyor.


2
Yani şimdi çevik yinelemeli ve artımlı için kredi almaya çalışıyor? '92'deki gelişime başladığımdan beri yinelemeli ve artımlı olanların şelale gelişiminin CORE parçaları olduğunu unutmayın.
Dunk

1

Şelale yöntemi kesinlikle uygulanabilir ve diğer yaklaşımlar kadar felsefi bir ses. Şelalenin Çevik'ten çok daha uzun zaman geçtiğini unutmayın, ancak bunun bir metodolojinin diğerinden daha iyi olup olmadığını belirten bir argüman olmadığını unutmayın .

Waterfall yöntemini, tüm sorun alanı ve müşterinin bir yazılım paketinde ne elde etmek istediği hakkında net bir anlayışa sahip olduğunuzda kullanırsınız. Muhtemelen sözleşmeyi alırken sabit bir fiyat verdiniz ve müşteriniz kararlaştırılan gerekliliklerden sapamayacağının farkında. Süreciniz kesinlikle gelişimin çeşitli aşamaları arasında bir dizi imzadan geçen bir süreçtir ve genellikle her bir aşamada her biri zorunlu olarak gerekmeyen farklı bir ekip - hatta bazen farklı bir şirket tarafından - tamamlanmıştır. diğerleri ile temasa geçin. Şelalenin, dış müteahhitlere ihale edildiğinde askeri ve devlet projelerinde iyi etkilere başvurduğunu sıklıkla görüyorsunuz. Şelale ve diğer benzer yaklaşımların kötü bir üne kavuşması, geliştiricilerin problemlerle karşılaştığında, kötü tahmin, beklenmedik bir süre olmadan planlanmış programlar veya sorunlu alanın zayıf veya eksik olduğu gibi. Mesele hiçbir zaman gerçekte bir metodolojinin hatası değildir, ancak uygulamasındadır.

Çevik ile herhangi bir metodoloji arasındaki karşılaştırma yanlıştır. Çevik bir metodoloji değil, bir felsefedir veya belki de yazılım geliştirme konusunda nasıl çalıştığınıza bakmanın farklı bir yolunu temsil eden bir şemsiye terim olduğunu söylemek daha iyi olur. Bir metodoloji sadece bir araçtır ve bu yüzden değeri her zaman Çevik olmanın ne demek olduğuna dair yüreklerden olan bireylerden ve etkileşimlerden daha az olacaktır .

Gerçekten de, yazılım değişimini en aza indirmenin değerli bir yazılım sunmak isteyenler için uygun bir seçenek olduğunu düşünüyor mu?

Değişimi en aza indirmek için her fırsat hem geliştirici hem de müşteri için değerlidir. Değişiklikler bir programın kaymasına ya da bir programın karşılanması için özelliklerin bırakılmasına neden olabilir. Projelerinizin değerini etkileyen değişimin etkilerini bu şekilde yönetiyorsunuz.

Yoksa, kaçınılmaz değişimi yönetmek için durumlarımızda hangi tür uygulamaların en iyi şekilde çalıştığı ile ilgili bir soru mu var?

Uygulamalarınız değişimin yönetimine yardımcı olabilir veya değişikliği tamamen görmezden gelebilirler. Önemli olan, geliştirme uygulamalarınızın birleşmesi ve müşterilerinizle olan ilişkinizin yönetimi ve bunların tüm taraflar için birlikte etkili bir şekilde çalışıp çalışmadığı.

Tüm amaçları ve amaçları olan bizler için Çevik , sizin için çalışan bir yöntem seçtiğinizi anlıyoruz. Belirli bir yaklaşımı seviyorsanız izleyin. Gereksinimlerinize tam olarak uymuyorsa, değiştirin. El yapımı yazılımları nasıl kullandığınız, elinizdeki kaynaklardan en iyi şekilde yararlanmaya çalışmak ve projenizi başarısızlığa doğru yönlendirebilecek uygulamaları en aza indirgemek için sık sık ortaya çıkmaktadır ve sık sık yönteminize uyacak şekilde yönteminizi değiştirmeniz gerektiğini keşfedersiniz. Eldeki belirli bir proje.

"Tamam, öyleyse şimdi Çevikiz" diyen bir şey ve aslında Çevik'in olduğu felsefesiyle yaşamak ve çalışmak. Eğer Şelalesi'ni, Artımlı, Spiral, Scrum, XP, FDD, ya da başka bir yöntem kullanmak olsun, temelde Çevik nerede size değeri:

  • Bireyler ve süreçler ve araçlar üzerindeki etkileşimler
  • Kapsamlı dokümantasyon üzerinde çalışan yazılım
  • Sözleşme müzakere konusunda müşteri işbirliği
  • Bir planı takip etmeyi değiştirmeye cevap vermek

ve bu değerleri başarıyla uygulamak için araçlarınızı, yönteminizi ve deneyiminizi bir araya getirdiğiniz yer.


2
Vay. Burada çok garip şeyler var. Şelale, daha uzun süre olması temelinde uygulanabilir mi? Şelale savunma sözleşmelerinde kullanım temelinde haklı mı? Değişimi en aza indirmek için her fırsat gerçekten müşterinin çıkarınadır mı, yoksa gerçekten istediğini değil de istediğini düşündüğü şeyi sağlamaya mı yol açar? Bunu önemsiyor görünüyorsun, nereden geldiğini anlamaya çalıştım, ama bir şeyleri özlüyorum.
Eric Wilson

1
@EricWilson Şelalesi daha uzun süredir var ve Çevik felsefe tartışılmadan çok önce başarıyla kullanıldı. Uygulanabilir çünkü var olduğu ve uygun şekilde uygulandığında kullanmak isteyenler için işe yarıyor. Kullanımını haklı göstermedim, ancak yalnızca çalıştığını gördüğüm kişisel deneyime sahip olduğum bir örneğe işaret ettim ve evet, birkaç muhteşem başarısızlık da gördüm. Değişimi en aza indirmek için fırsatlar aramıyorsunuz, değişimi tanıtmak için fırsatlar istiyorsunuz, ancak bunu makul bir şekilde yapmanız gerekiyor, aksi takdirde müşterileriniz istediklerinden daha az alırlar veya son teslim tarihlerini kaybederler.
S.Robins

0

Evet, Şelale, Spiral, İteratif ve diğer hibrit işlem modellerinin hepsi uygulanabilir, ancak değişiklik kaçınılmaz. Süreç, değişimin nasıl ele alınacağı ile ilgili değildir ve (bence) en büyük belirleyici, sorunu ne kadar iyi bildiğiniz / anladığınız ve ne kadar doğru planlayabileceğiniz ve tahmin edebileceğinizdir.

"İki baskın yazılım geliştirme metodolojisinin şelale ve çevik olduğu" ifadesi oldukça belirgindir, çünkü yazılım geliştirme süreçlerinin bir yelpazesi vardır ve çoğu şirket, belirli bir proje için sıklıkla değişen süreç modelinin kendi versiyonunu sentezler. Yazılım geliştirmeye ikiden fazla uygulanabilir yaklaşım vardır. Şelale ve Çevik, “değişim” spektrumunun karşıt uçlarına düşme eğiliminde olsa da, bu rakip metodolojileri aşağıdaki gibi tanımlamak makul olacaktır.

Şelale diyor ki: Değişim masraflıdır, bu yüzden minimize edilmelidir.

Çevik diyor ki: Değişim kaçınılmazdır, bu yüzden değişikliği ucuza yapın.

Ama bu hikayenin tamamı değildir. İşletmelerin planlama ve tahmin edebilmesi gerekir, ancak yazılım yaratıcı bir süreçtir ve tahminler çoğu zaman yanlıştır. İyi - hızlı - ucuz üçgeni hatırladın mı? Dördüncü bir boyut, süreç ekler ve süreç azaltma işleminin, tahminler yanlış çıktığında ve bir projenin gecikme tehlikesi altında olduğu durumlarda programı da sıkıştırabilir. Yazılım, elverişli (değişken) bir işlemdir ve Çevik, İteratif, Spiral, hepsi kısa aralıklarla artan işlevsellik sağlama yeteneği sunar.

Şelale ve diğer gereksinimlere dayanan süreç modelleri, değişimin ele alınması için kontrollere sahiptir, bu nedenle Şelalenin değişimi en aza indirdiğini söylemek yanlış olur, Şelalenin değişimi tanıdığını ve yönettiğini ve bu değişikliğin etkisini ilettiğini söylemek daha doğru olur (çünkü değişiklik sizlerin zaman zaman etkilenmesini sağlar. gereksinimleri ve tasarım ön). Bir ürün oluştururken veya gereksinimleri tam olarak tanımlamanız gerektiğinde (işlevsellik), hibrit modellerden birine yönlendirilirsiniz.

Tahminler yanlış olduğunda, sık sık işlem (demir üçgenin dördüncü bacağı) takvimi karşılamak için feda edilir.


Utangaç değildim. Çeşitli şirketlerde beş yıllık gelişimden sonra, sadece iki taneyle karşılaştım, bunlardan sadece biri kalıcı. Spiral? Hiç duymadım.
Eric Wilson


Demek istediğim, onlarla gerçek dünyada karşılaşmamıştım. İntikamlarda her türlü şey var ama 2010'da tekrar bir soru sorduğum için onları avlamaya başlamayacağım.
Eric Wilson

-1

Olgun çevik ve şelale yaklaşımları birbirinden ayırt edilemez. Şelale yaklaşımının amacı hakkındaki varsayımınız yanlış. Her ikisi de kaliteli yazılım üretme hedefine sahiptir. Bir bütün olarak şirket için sağlam bir kalkınma yaklaşımınız olmadığında , hangi yaklaşımın benimseme için en az sürtünme miktarını sağlayacağına bakmanız gerekir. Sonunda kısa gelişme dönemlerinde, sağlam bir KG ekibi ve geliştirmeyi yönlendiren bir işletme, birinci sınıf yazılım üretmek için en önemli şeydir.


1
Senin yorumuna bir uyarı koyardım. Şelale yetenekli insanlar gerektirir ya da yüzünde düz düşer. İyi tasarlamayı öğrenmek zordur. Kodlamayı öğrenmek nispeten kolaydır. IMO, çoğu geliştiricinin çevikliği tercih etmesinin temel nedeni bu.
Dunk

4
Aynı çevik diyebilirim. Jr.'ın rehberliği olmayan geliştiriciler çabuklukla çevik bir karışıklık yapabilir.
Charles Lambert,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.