Çevik Şelalenin Şelalenin Verimliliği / Etkinliği ile ilgili bir çalışma var mı [kapalı]

Geçen gün yapılan bir toplantıda, çevrenin şelaleye kıyasla gelişme süresinde yalnızca% 60 kadar etkili olduğu iddia edildi. Bu talebi doğrulamak veya reddetmek istemiyorum. 2 metodolojiyi karşılaştıran herhangi bir çalışma olup olmadığını öğrenmek ilginç.

İkisini karşılaştıran bir çalışma var mı?

"Yazılım Üretimi: Gerçekten Ne İşe Yarar ve Neden İnanıyoruz?" Kitabında , iyi bilimsel desteklerle XP, Scrum, Dinamik Yazılım Geliştirme ve Yalın dahil Çevik yöntemler üzerine bazı bölümler bulunmaktadır. O'Reilly'den beklediğiniz gibi yüksek kalitededir. Editörlerden biri, güvenilir bir bilgisayar bilimi yazarı, editör ve sunum yapan mükemmel Greg Wilson'du .

Kitabın kendisi, çevik olanlar dahil olmak üzere birçok araştırma çalışmasını özetlemektedir. Bir bölüm Dybå, T. tarafından " İki Başın Birinden Daha mı İyi? İkili Programlamanın Etkinliği Üzerine" ; Arisholm, E.; Sjøberg, DIK; Hannay, JE; Shull, F; ve " Çevik yazılım geliştirme deneysel çalışmaları: sistematik bir inceleme ", Tore Dybå ve Torgeir Dingsøyr.

Genel anlamda, çoğu çevik uygulamanın yararlı olduğu, ancak çift programlamanın ve TDD'nin ve diğer çevik kiracıların etkilerinin, birinin umabileceği kadar güçlü olmadığıdır. TDD'nin aslında biraz bağımlılık yapabileceği konusunda rahatsız edici bir dipnot bile var *.

Kitap, hepsi bir arada bir bütün olarak yapılan birçok araştırmaya erişmenin harika bir yoludur. Web’de kitabı inceleyen birkaç blog ve başka siteler var.

* Bu mutlaka benim görüşüm değil!

Başlığı sevmediğim kadarıyla, Denge Çevikliği ve Disiplini Dengelemek: Çapraşıklar için bir Rehber'in sizinle ilgili bazı bilgiler içerebileceğine inanıyorum. İki yazılım mühendisliği süreci ve yazılım proje yönetimi uzmanı tarafından hazırlanan bu kitap - Barry Boehm ve Richard Turner. Bu kitap çevik ve plana dayalı metodolojilerin çeşitli yönlerine bakar, onları karşılaştırır ve karşılaştırır, ayrıca “her iki dünyanın en iyisini” durumuna ulaşmak için onları birleştirmeyi tartışır.

Çeviklik ve Disiplin Dengeleme Ek E, çeşitli çevik ve plana dayalı yöntemlerin maliyetleri ve faydaları hakkında çok sayıda deneysel bilgi içerir. Bununla birlikte, zaman etkinliği ile ilgili herhangi bir veri bulunmuyor. Ancak verilere göz attığımda, (şüphelendiğim gibi) bunun bir ya da ya da seçenek olmadığı anlaşılıyor - bazı projeler çevik yöntemler uygularken daha az çaba, daha hızlı programlar ve daha düşük hatalar yaşadı. Ancak, kullanılan diğer projeler. Bu bölüm, farklı endüstrilerdeki bir dizi farklı projeyi, kullandıkları sürecin türünü ve proje boyunca yaşadıklarını tartışmaktadır.

Ek E'de belirtilen ve bu verileri sağlayan birçok vaka çalışması bulunmaktadır. Belirli bir endüstride, hatta belirli bir organizasyon içinde odaklandığımız için rastgele adlandırmaya başlayacağım çok fazla insan var. Durumlara bakacaksanız, makul biçimde geçerli sonuçlar çıkarmak için ekibinize, projenize, organizasyonunuza ve sektörünüze benzer olanları bulmanızı öneririm.

In Hızlı Gelişme: Taming Yabani Yazılım Tarifeleri , şartların mimari, istenilen güvenilirlik, risk yönetimi, zamanlama kısıtlamaları, sürecin miktarı arasında anlayış düzeyini anlama düzeyini: Steve McConnell bir ömrü metodolojisi seçerken dikkate birkaç faktörü tanımlar genel gider, proje ortası "ders düzeltmeleri", müşteriye görünürlük sağlama yeteneği, yönetime görünürlük sağlama ve geliştirme ekibinin ve yönetimin karmaşıklığı. Örgüt kültürü gibi başkaları da var, bu yüzden muhtemelen hiçbir yerde ayrıntılı bir liste yok.

Aynı projeye rağmen, takım faktörü de var. Plan güdümlü spiral metodolojisini kullanarak yazılımı kararlı bir şekilde teslim eden bir takımı alırsanız ve bunları Scrum'a atarsanız, üretkenlikte bir düşüş, çökmede bir artış görecekler ve gelmeden önce yeni bir süreç modelinin üstesinden gelmek zorunda kalacaklar. başarılı olmak için etrafında. Başka bir metodoloji daha uygun olsa da, yazılımı gerçekten teslim etmek için her zaman işletmenin ihtiyacı vardır. Bu nedenle süreç iyileştirme çabaları genellikle uzun vadeli çabalardır ve bir gecede değil - bir takımda büyük değişiklikler şok edicidir ve (metodoloji kağıda daha uygun olsa bile) üretkenlikte düşüşe neden olabilir.

Sürecin etkinliğinden ya da etkinliğinden çok daha fazlası var ve plan odaklı bir ortamda ve çevik bir ortamda çalışan aynı ekibin anlık görüntüsüne bakamıyorsunuz. Bir karar verirken sınai ve örgütsel bağlamı, projenin özelliklerini, ekibini, müşterisini vb. Göz önünde bulundurmanız gerekir.

Okuduklarıma dayanarak, iş arkadaşlarınızın değerlendirmesine katılmam gerekecek. Çevik bir projenin benzer bir plan odaklı projeden ziyade bazı performans ölçütleri bakımından% 60 daha az verimli olduğu bir yerde bazı vaka çalışmaları bulabileceğinize eminim. Ancak, çevikliğin% 80 daha az çaba,% 50 daha az zaman ve üründe yüksek müşteri memnuniyeti sağladığını gösteren çalışmalar da var.

Çalışmam yok ama deneyimlerimi iletmek istiyorum.

Söz konusu metodolojilerin herhangi birinin etkinliği, analistlere büyük ölçüde bağlıdır.

İyi bir ürün sahibine sahip olduğunuzda, örneğin SCRUM, kötü özellikli bir şelale yaklaşımından kesinlikle daha hızlıdır.

Kötü bir ürün sahibi ile çevik, harika bir özellik ile şelale daha kesinlikle yavaş.

Bununla birlikte, çoğu zaman, gereklilikleri tam olarak yeterince erken bilmiyoruz ve çevik metodolojilerin daha hızlı geri bildirim döngüleri var. Bu, belirsiz arazide çevikliğin makul maliyetlerle yüksek kaliteli bir ürün sunmak için daha iyi bir yöntem olduğu anlamına gelir. Çok sayıda başka avantajlar vardır; örneğin, çevik projelerin çalışmadıklarında iptal edilmeleri daha kolaydır ve böylece kaybı en aza indirir.

Çevik metodolojilerin riski azalttığını söylerken, şelale, bazen daha hızlı olsa bile, oldukça parasal bir kumar olabilir.

Çevik gelişme süresinde verimli olarak sadece% 60 oldu

Doğru.

Ancak, bu bir topal ölçüdür.

Çevik yöntemler genellikle daha erken zamanda gerçek değeri sağlar.

Şelale, ne teslim edildiğine bakılmaksızın bir takvime sadık kalıyor ve çok fazla zaman geçinceye kadar çoğu zaman değerli bir şey vermiyor.

Daha ileri.

"Geliştirme zamanı" nı "geliştirme ve deneme zamanından" ayrı olarak ölçebilirsiniz.

Çevik genellikle test içerir. Bu yüzden daha yavaş görünüyor.

Şelale gelişimi testlerden temiz bir şekilde ayrılabilir. Yani kod "teste hazır". Ama daha sonraya kadar "bitmedi".

Yani. Tamamen haklılar. Ölçdükleri için.