Çevik Geliştirme

Çevik yazılım geliştirme, kısa yinelemeler halinde iş teslim eden, sürekli geri bildirimi içeren ve anlayış geliştikçe planları uyarlayan bir yazılım geliştirme yaklaşımıdır. 2001 yılında yayınlanan Çevik Manifesto'da dört değer tercihi belirtilmiştir: süreçler ve araçlar yerine bireyler ve etkileşimler, kapsamlı dokümantasyon yerine çalışan yazılım, sözleşme müzakeresi yerine müşteri işbirliği ve bir planı takip etmek yerine değişime yanıt verme.

Manifestonun ifadeleri sıklıkla yanlış alıntılanıyor ve bu da önemli bir noktayı ortaya koyuyor. Her ifade, her ikisinin de değeri olan iki şey arasında bir tercihi ifade ediyor, ikincisinin reddini değil. Belge açıkça, sağdaki maddelerin de değeri olduğunu, ancak soldaki maddelerin daha değerli olduğunu belirtiyor. Manifestoyu belgelemeyi, planlamayı veya sözleşmeleri yasaklayan bir metin olarak yorumlayan uygulamalar, söylediklerinin yarısını göz ardı etmiş ve genellikle eleştirmenlerin yaklaşımın kendisine atfettiği düzensizliği ortaya çıkarmıştır.

Temel mantık belirsizlikle ilgilidir. Sıralı geliştirme, gereksinimlerin önceden doğru bir şekilde belirlenebileceğini varsayar; bu, iyi anlaşılmış sorunlar için geçerlidir ancak değeri insanların bunlara nasıl tepki verdiğine bağlı olan ürünler için geçerli değildir. Yinelemeli teslimat, bir karar ile bu karara ilişkin kanıt arasındaki aralığı kısaltarak yanlış yapmanın maliyetini azaltır; bu da sorunun belirsizliğiyle orantılı olarak değerlidir.

Pratikte en sık karşılaşılan hata, ilkeler olmadan törenlerin benimsenmesidir. Kuruluşlar, sabit kapsam, sabit son tarihler, yıllık planlama ve geri bildirimlere göre hareket etme mekanizması olmaksızın günlük toplantılar, yineleme sınırları ve tahmin uygulamaları getirirler. Sonuç olarak, ek toplantılarla iki haftalık bölümler halinde yürütülen ardışık bir geliştirme süreci ortaya çıkar; bu da her iki yaklaşımın da doğru şekilde uygulanmasından daha yavaştır ve metodolojiye yönelik yaygın şüpheciliğe yol açar.

Müşteri iş birliği unsuru, kuruluşların en çok zorlandığı ve en sık atladığı unsurdur. Geri bildirime uyum sağlamak, gerçek kullanıcıların çalışan yazılımla düzenli olarak etkileşim kurması anlamına gelen geri bildirim almayı gerektirir. Dahili bir paydaş veya yazılı bir şartname gibi bir aracı üzerinden çalışan ekipler, amacını veren girdiden yoksun bir yineleme ritmine sahiptir ve kimsenin doğrulamadığı bir yönde güvenle yineleme yaparlar.

Ölçeklendirme, orijinal formülasyonun ele almadığı gerçek zorluklar ortaya çıkarır; çünkü manifesto, küçük ve aynı yerde bulunan ekipler düşünülerek yazılmıştır. Bir ürün üzerinde birçok ekibi koordine etmek, uyum, bağımlılık yönetimi ve mimari tutarlılık mekanizmaları gerektirir ve bunu ele alan çeşitli ölçeklendirme çerçeveleri, yaklaşımın azaltmayı amaçladığı süreç ağırlığını yeniden getirdiği için sıklıkla eleştirilir. Gerilim, bir anlayış eksikliğinden ziyade gerçektir.

Değerlendirme, uyumluluktan ziyade sonuçlara odaklanmalıdır. İlgili sorular şunlardır: Fikirden doğrulanmış öğrenmeye kadar geçen süre kısaldı mı, ekip kanıtlar gerektirdiğinde yön değiştirebiliyor mu, kalite son teslim tarihine bağlı olarak ödün verilmek yerine korunuyor mu ve ürün kullanıcılar için ölçülebilir şekilde daha iyi mi? Her yıl sabit bir spesifikasyona göre ürün teslim ederken her öngörülen uygulamayı gerçekleştiren ekipler, terminolojiyi benimsemiş ancak hiçbir faydasını görmemiştir.

Bu yaklaşım, ekip uygulamaları kadar organizasyonel koşullara da bağlı olduğundan, benimsenmesi sıklıkla uygulama ekibinin dışında kalan yönetim, finansman ve planlamada değişiklikler gerektirir. Uygulamada bu, aşağıdaki kapsamda ele alınır: ürün geliştirme Teslimat sürecinin kendisiyle birlikte, geri bildirim döngüsü de desteklenmektedir. kullanıcı araştırmasıVe bu yeteneği kurum içinde geliştiren kuruluşlar genellikle bunu bir çerçeve içinde kurarlar. ürün departmanı Planlama ve uygulama sorumluluğunun bir arada bulunduğu yer.