Çevik BT BT Sektörünü Nasıl Dönüştürebilir?

Yazar: Roger Morrison
Yaratılış Tarihi: 20 Eylül 2021
Güncelleme Tarihi: 21 Haziran 2024
Anonim
Çevik BT BT Sektörünü Nasıl Dönüştürebilir? - Teknoloji
Çevik BT BT Sektörünü Nasıl Dönüştürebilir? - Teknoloji

İçerik



Kaynak: Darkovujic / Dreamstime.com

Paket servisi:

Birçokları için, yazılım geliştirme şelale modeli on yıllardır standart olmuştur, ancak bu şimdi çok daha esnek olan Çevik metodoloji ile değiştirilmektedir.

Yazılım geliştirme için Çevik metodoloji, BT endüstrisini olumlu yönde etkileyebilir. Çevik metodolojinin benimsenmesinin sonuçları çeşitli şekillerde ölçülebilir. Yazılım değişikliği taleplerinin daha hızlı geri dönüşü, daha az hata, takım performansının nicel ölçümü ve darboğazlar, Agile'nin başarılı bir şekilde uygulanmasının bir yansımasıdır. Çevik'in etkisini başarıyla ölçmek için bir kuruluş Çevik öncesi ve Çevik sonrası gelişme ile ilgili çeşitli ölçümleri karşılaştırmalıdır. Çevik'in gerçek etkisi, sadece gelirdeki artışla veya sabit hataların artmasıyla ölçülemez. Gerçek etkiyi anlamak için çeşitli iç parametrelerin dikkate alınması gerekir. (Çevik geliştirme hakkında daha fazla bilgi için, bkz. Çevik Yazılım Geliştirme 101.)


Neden Çevik BT?

BT endüstrisi, temel olarak yazılım geliştirme şelale modelinin kısıtlamaları nedeniyle Çevik uygulamalara yönelmektedir. Genel olarak, BT şirketlerinin değişen müşteri taleplerine veya piyasa koşullarına cevap veremediği veya yazılım geliştirme şelalesi modeliyle maliyetleri düşüremediği görülmüştür. Bu ezici eğilimi Agile metodolojisine karşı dengeleyip denemenin heyecanını bir parça yutturmaca olarak görsek bile, şelale modeline karşı birçok deneysel geri bildirim var.

Basitçe söylemek gerekirse, şelale modeli, çalışmanın sıralı bir şekilde yapıldığı bir yazılım geliştirme modelidir - birbiri ardına faz. Bu modelin beş aşaması vardır: gereksinimler, tasarım, uygulama, doğrulama ve bakım. Genellikle, bir aşama tamamlandıktan sonra, daha erken bir aşamada değişiklik yapmak imkansız olmasa da zordur. Dolayısıyla, varsayım, gereksinimlerin hemen hemen sabit olduğu yönündedir. Çevik model ile olan temel fark, gereksinimlerde bir değişiklik olmayacağı varsayımına dayanmaktadır. Çevik, iş durumlarının değişeceğini ve gereksinimlerin de değişeceğini varsayar. Böylece, yazılım ss üzerinden daha küçük parçalar halinde verilirken, şelale modelinde ilk teslimat veya serbest bırakma uzun bir süre sonra yapılır. (Geliştirme hakkında daha fazla bilgi için, bkz. Apache Spark, Hızlı Uygulama Geliştirmeye Nasıl Yardımcı Olur.)


Şelale modeline karşı en dikkate değer eleştiri, şartlarda değişiklik olmayacağı varsayımı olmuştur. Bu varsayım hatalı ve gerçekçi değildir. Örneğin, 2001 yılında İngiltere’deki 1.027 IT projesinde yapılan bir araştırma, bu varsayımın BT projelerinin başarısızlığının en büyük nedeni olduğunu göstermiştir.

Başka bir örnekte, "Çevik ve İteratif Gelişme: Bir Yönetici Kılavuzu" adlı kitabın yazarı Craig Larman, ABD'deki şelale modelini kullanarak Savunma Bakanlığı (DoD) tarafından yürütülen bir dizi projenin ABD’de başarısız olduğuna işaret etti. hedeflerine ulaşmak. 1980'lerde ve 1990'larda, DoD STD 2167'de yayınlanan standartlara göre yazılım geliştirme projeleri için şelale modelini kullanması istenmiştir. Şok edici istatistikler bu yazılım projelerinin% 75'inin hiç kullanılmadığını ortaya koydu. Bu raporun ardından, tanınmış bir yazılım mühendisliği uzmanı olan Dr. Frederick Brooks altında bir görev gücü başlatıldı. Görev gücü “DoD STD 2167 aynı şekilde modern en iyi uygulamayı yansıtacak şekilde radikal bir revizyona ihtiyaç duyan” bir raporla ortaya çıktı. Evrimsel gelişim teknik olarak en iyisidir, zaman ve para tasarrufu sağlar. ”

Şelale modelinin aşağıdaki dört varsayımı, gerçek dünya senaryolarında başarısız olmuştur:

  • Verilen gereksinimler oldukça iyi tanımlanmıştır ve bu nedenle önemli ölçüde değişmeyecektir.
  • Gereksinimler gelişim aşamasında değişse bile, gelişim döngüsü içinde yerine getirilecek kadar küçük olacaktır.
  • Yazılımın tesliminden sonra gerçekleşen sistem entegrasyonu plana göre gerçekleştirilecektir.
  • Yazılım yeniliği ve yenilik için gereken çaba, planlı ve öngörülebilir bir programa göre devam edecektir.

Çevik Metodoloji, Şelale Modelinin Sorunlarını Nasıl Ele Alır?

Çevik metodoloji temel olarak şelale modelinden farklıdır ve varsayımlarından açıkça anlaşılmaktadır:

  • Müşteri bile değil hiç kimse gereksinimleri tam olarak bilemez veya anlayamaz. Gereksinimlerin değişmeyeceğinin garantisi yoktur.
  • Gereksinim değişiklikleri küçük ve yönetilebilir olmayabilir. Aslında, çeşitli boyutlarda gelecekler ve gelmeye devam edecekler. Böylece, yazılım değişiklikleri takip etmek için küçük artışlarla teslim edilecektir.

Çevik BT Sektörünü Nasıl Etkiledi?

Çevik birçok yerde benimsendiğinde, birçok şirket Çevik'i benimsemeyi planlıyor. Agile, BT endüstrisinde kesinlikle önemli değişiklikler yapmış olsa da, gerçekleri ve rakamları elde etmek hala biraz zor. Ancak Çevik'in etkisi, aşağıda verilen British Telecom (BT) vaka incelemesiyle anlaşılabilir.

Hata Yok, Stres Yok - Hayatınızı Yok Etmeden Hayat Değiştiren Yazılım Yaratma Adım Adım Kılavuzunuz


Hiç kimse yazılım kalitesiyle ilgilenmediğinde programlama becerilerinizi geliştiremezsiniz.

BT'nin Çevik Uygulamalara Geçiş Nedenleri

BT, 2004 yılında yazılım geliştirme uygulamaları ile ilgili bir takım sorunlar yaşamaya başladı. BT, basit ve karmaşık bir dizi yazılım projesi geliştirdi. Pek çok yazılım projesi kararlaştırılan zaman dilimi içinde kalite çıktısı geliştiremedi. BT, sorunların köklerini şelale modeline borçlu olduğunu buldu. Yani, şelale modelini güçlendirmek yardımcı olmayacaktı. Sorunların ana nedenleri aşağıda verilmiştir:

Gereksinimlerin Kötü Yönetimi

  • Çok sınırlı bir süre içinde yerine getirilmesi için çok fazla gereksinim verildi.
  • Birçok gereksinim, işletme ihtiyaçları ile ilgisizdi.
  • Hemen hemen hepsi, tüm gereksinimlere yüksek öncelikli statü verilmemişse.
  • Gereksinimler, gelecekteki senaryolar göz önünde bulundurulmadan mevcut işletme ihtiyaçlarını temsil ediyordu. Bu, gelecekteki yazılım değişiklikleri olasılığını açık bıraktı.

Kötü Yazılım Tasarımı

  • Çok sayıda gereksinim göz önüne alındığında, tasarımcılar yalnızca gereksinimlerin ne anlama geldiğini bulmaya çalışırken çok fazla zaman harcadılar. Gerçek tasarım için çok az zaman kaldı.
  • Gereksinim analistleri, yazılı olmayan, gizli bilgilerle yanlarına alarak diğer ödevlere geçtiler.
  • Yukarıdaki iki faktör zayıf tasarımla sonuçlandı. Tasarımcılar hala orijinal zaman çizelgesine göre teslim etmek zorunda kaldılar.

Geliştirme Kısıtlamaları

Kodlama, hatalı yazılım tasarımından dolayı aceleci ve kalitesizdi. Geliştiriciler, zayıf bir yazılım tasarımının zayıf kodla sonuçlanacağının farkındaydı, ancak yine de kararlaştırılan zaman çizelgesine göre teslim etmek zorunda kaldılar. Entegrasyon sırasında pek çok hata bildirilecektir çünkü ünite testleri ve regresyon testleri çalışmadı.

Yazılım dağıtıldığında, müşteri gereksinimlerin zaten değiştiğini ve iş senaryosunun da olduğunu not eder. Yazılımın ayrıca birçok sorunu var. Etkili olarak, yazılım geliştirme çabalarının tümü artık israf olarak kabul edilmektedir.

BT Yukarıdaki Sorunları Çözmek İçin Ne Yaptı?

BT, şelale modelini güçlendirmenin sorunların cevabı olmadığını fark etti. Yeni bir yaklaşıma ihtiyaç vardı. Böylece, Çevik yaklaşımı uygulamaya karar verdi. Yeni yaklaşım çerçevesinde, aşağıdakilere karar verildi:

  • BT, 12 aylık geliştirme döngüsü yerine 90 günlük bir döngüde uygulanabilir yazılım parçaları sunacaktı. Fikir, bir veya iki iş problemine odaklanmak ve 90 gün içinde bir yazılım çözümü sunmayı hedeflemekti. Bu döngünün başlangıcı, gereksinimlerin açıkça tanımlanması, analiz edilmesi ve önceliklendirilmesi için farklı paydaşlar arasında yoğun bir tartışma ile işaretlendi.
  • Hedef, net ve somut iş değerleri sunmaktı. Dahili müşteri, net gereksinimler sağlamak için baskı altındaydı. Böylece, belirsiz hedeflerin yerine, kullanıcı öyküleri açık kabul kriterleri ile verildi.
  • Teslim edilecek olan yazılım tamamen test edilecek ve belgelendirilecektir. Yazılım, önceden sorunları belirlemek için sık sık entegrasyon testlerinden geçiyordu.

Çevik yaklaşımla BT değişen ihtiyaçlara veya iş durumlarına daha kolay adapte olabilir. Kod kalitesi iyileştirildi ve son dakikadaki temel hatalar giderildi.

Sonuç

Çevik, tüm avantajları ve etrafındaki yutturmaca nedeniyle, potansiyelinin tam olarak gerçekleştirilmediği bir aşamadadır. Bunun nedeni birçok kuruluşun yaklaşımı orijinal ilkelerini değiştirecek şekilde özelleştirmesidir. Sonuç olarak, şelale modeli bazı durumlarda geri dönüş yapıyor. Özelleştirme devam ederken, Agiles'in temel prensiplerini korumak önemlidir. Pek çok kuruluş tam olarak Çevik olduğunu iddia ediyor, ancak gerçek anlamda Çevik bir şirket olmak için hala gidecekleri bir yol var.