Uyarlanabilir Yazılım Geliştirme - Hızlı Kılavuz

Çevik nedir?

Edebi anlamda "çevik" kelimesi, hızlı ve kolay hareket edebilen veya hızlı ve net düşünebilen ve hareket edebilen biri anlamına gelir. İş dünyasında “çevik” planlama ve iş yapma yöntemlerini tanımlamak için kullanılır; burada gerektiğinde değişiklik yapmanın işin önemli bir parçası olduğu anlaşılır. İş "çevikliği", bir şirketin her zaman pazar değişikliklerini hesaba katacak durumda olduğu anlamına gelir.

Yazılım geliştirmede, "çevik" terimi "değişikliklere yanıt verme yeteneği - Gereksinimler, Teknoloji ve İnsanlardan kaynaklanan değişiklikler" anlamına gelecek şekilde uyarlanmıştır.

Çevik Manifesto

Çevik Manifesto, 2001 yılında bir yazılım geliştiricileri ekibi tarafından yayınlandı ve geliştirme ekibinin önemini vurgulayarak, değişen gereksinimleri ve müşteri katılımını barındırdı.

Çevik Manifesto -

Bunu yaparak ve başkalarının yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz. Bu çalışma sayesinde, değer kazandık -

  • Süreçler ve araçlardan ziyade bireyler ve etkileşimler.
  • Kapsamlı dokümantasyon yerine çalışan yazılım.
  • Sözleşme pazarlığı yerine müşteri işbirliği.
  • Bir planı takip etmek yerine değişime yanıt vermek.

Yani sağdaki öğelerde değer varken soldaki öğelere daha çok değer veriyoruz.

Çevikliğin Özellikleri

Çevikliğin özellikleri aşağıdadır -

  • Çevik Yazılım Geliştirmede Çeviklik, güçlendirilmiş ve kendi kendini örgütleyen çok disiplinli, çapraz fonksiyonlu ekiplerle tüm ekibin kültürüne odaklanır.

  • Paylaşılan sorumluluğu ve hesap verebilirliği teşvik eder.

  • Etkili iletişimi ve sürekli işbirliğini kolaylaştırır.

  • Tüm ekip yaklaşımı gecikmeleri ve bekleme sürelerini önler.

  • Sık ve sürekli teslimatlar, hızlı geri bildirimler sağlayarak ekibin gereksinimlere uyum sağlamasına olanak tanır.

  • İşbirliği, uygulamada farklı bakış açılarını zamanında birleştirmeyi, hata düzeltmelerini ve değişiklikleri barındırmayı kolaylaştırır.

  • İlerleme, şeffaflığı vurgulayan, sabit, sürdürülebilir ve öngörülebilirdir.

Çevik Metodolojiler

Çevik yöntemlerin ilk uygulamaları arasında Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development ve Dynamic Systems Development Method (DSDM) bulunmaktadır. Agile manifestosu 2001'de yayınlandıktan sonra artık bunlara toplu olarak Agile metodolojileri adı verilmektedir.

Bu eğitimde Çevik Metodolojiyi öğreneceğiz - Adaptive Software Development.

Uyarlanabilir Yazılım Geliştirme nedir?

Uyarlanabilir Yazılım Geliştirme, belirleyici uygulamaları karmaşık sistemler ve karmaşık ortamlar bağlamında bırakarak uyarlanabilir uygulamalara doğru bir harekettir. Uyarlanabilir Yazılım Geliştirme, karmaşık sistemler oluşturmak için bir teknik olarak işbirliği ve öğrenmeye odaklanır. Hızlı Uygulama Geliştirme (RAD) ve Evrimsel Yaşam Döngülerinin en iyi uygulamalarından geliştirilmiştir. Daha sonra Uyarlanabilir Yazılım Geliştirme, Planlamanın yerini spekülasyonla yönetime uyarlanabilir yaklaşımları içerecek şekilde genişletildi.

Jim Highsmith, 2000 yılında Uyarlanabilir Yazılım Geliştirme üzerine bir kitap yayınladı. Highsmith'in sözleriyle -

“Uyarlanabilir Yazılım Geliştirme, evrimsel model gibi döngüseldir, aşama adları Spekülasyon yapın, işbirliği yapın, gittikçe karmaşıklaşan sistemlerin öngörülemeyen alanını yansıtmayı öğrenin. Uyarlanabilir gelişim, iki temel yoldan evrimsel mirasından daha ileri gider. Birincisi, determinizmi açıkça ortaya çıkışla değiştirir. İkincisi, Yaşam Döngüsündeki bir değişikliğin ötesinde, yönetim tarzındaki daha derin bir değişikliğe gidiyor. "

Bir Yazılım Geliştirme Yaşam Döngüsü (SDLC) modeli, bir yazılım geliştirme projesinin her aşamasında gerçekleştirilen faaliyetleri tanımlayan bir çerçevedir.

Bir Yazılım Geliştirme Yaşam Döngüsünde, faaliyetler beş aşamada gerçekleştirilir -

  • Requirements Gathering- Geliştirilecek bir yazılım için gereksinimler toplanır. Bu gereksinimler, müşteri / kullanıcı tarafından anlaşılan bir dilde olacaktır. Etki alanına özgü terminoloji önerilir.

  • Analysis - Toplanan gereksinimler, uygulama açısından analiz edilir ve yazılım özellikleri hem işlevsel gereksinimleri hem de işlevsel olmayan gereksinimleri kapsayacak şekilde yazılır.

  • Design - Bu aşama, yazılım mimarisi ve geliştirme için seçilen teknolojiye dayalı uygulama özelliklerine ulaşmayı içerir.

  • Construction - Bu aşamada kod geliştirilir, birim test edilir, entegre edilir, entegrasyon test edilir ve yapı üretilir.

  • Testing- Oluşturulan yazılımın fonksiyonel testi bu aşamada yapılır. Bu, işlevsel olmayan gereksinimlerin test edilmesini de içerir.

Bu etkinlikleri gerçekleştirmek için iki yaklaşım vardır -

  • Prescriptive - Faaliyetleri çerçeve tarafından tanımlandığı şekilde önceden belirlenmiş bir şekilde gerçekleştirmenin yollarını sağlayacak SDLC modelleri.

  • Adaptive- İzlenmesi gereken belirli kurallar ile etkinlikleri gerçekleştirmede size esneklik sağlayacak SDLC modelleri. Çevik yöntemler çoğunlukla bu yaklaşımı izler ve her birinin kendi kuralları vardır. Ancak, uyarlanabilir veya çevik bir yaklaşım izlenmesi, yazılımın herhangi bir disipline uyulmadan geliştirildiği anlamına gelmez. Bu bir kaosa yol açar.

Belirli bir SDLC modelinin iyi veya kötü olduğunu söyleyemeyeceğimizi anlamanız gerekir. Her birinin kendi güçlü ve zayıf yönleri vardır ve bu nedenle belirli bağlamlara uygundur.

Projeniz için bir SDLC modeli seçtiğinizde, anlamanız gerekir -

  • Kuruluş Bağlamınız
  • Teknoloji Bağlamınız
  • Takım Kompozisyonunuz
  • Müşteri Bağlamınız

Örneğin, yazılım geliştirme öngörülebilir ise, Kuralcı bir yaklaşım kullanabilirsiniz. Öte yandan, yazılım geliştirme öngörülemezse, yani gereksinimler tam olarak bilinmiyorsa veya geliştirme ekibinin mevcut alan veya teknolojiye önceden maruz kalmaması vb. Durumlarda Uyarlamalı yaklaşım en iyi seçimdir.

Aşağıdaki bölümlerde, sektör genelinde yazılım geliştirme projelerinin yürütülmesi sırasında geliştirilen en yaygın SDLC modellerini anlayacaksınız. Ayrıca her birinin güçlü ve zayıf yönlerini ve hangi bağlamlarda uygun olduklarını da öğreneceksiniz.

Waterfall modeli, yaygın olarak bilinen, anlaşılan ve yaygın olarak kullanılan klasik bir SDLC modelidir. 1970 yılında Royce tarafından tanıtıldı ve sektördeki çeşitli organizasyonlarda yazılım geliştirme için ortak bir yaklaşım olarak hala takip ediliyor.

Waterfall modelinde, her yaşam döngüsü aşaması yalnızca önceki yaşam döngüsü aşaması tamamlandıktan sonra başlayabilir. Bu nedenle, geri besleme döngüleri olmayan doğrusal bir modeldir.

Şelale Modeli - Güçlü Yönler

Şelale modelinin güçlü yönleri:

  • Anlaşılması kolay, kullanımı kolay.
  • Deneyimsiz geliştirme ekibine yapı sağlar.
  • Kilometre taşları iyi anlaşılmıştır.
  • Gereksinim istikrarını ayarlar.
  • Yönetim kontrolü için idealdir (planlama, izleme, raporlama).
  • Kalite, maliyet veya programdan daha önemli olduğunda iyi çalışır.

Şelale Modeli - Zayıf Yönler

Waterfall modelinin zayıf yönleri veya dezavantajları:

  • İdealleştirilmiş - Gerçekle çok iyi uyuşmuyor.

  • Gerçekçi değil - projenin başlarında doğru gereksinimler beklenemez.

  • Daha yaygın olan keşifsel gelişimin yinelemeli doğasını yansıtmaz.

  • Değişiklik yapmak zor ve pahalıdır.

  • Yazılım sadece proje sonunda teslim edilir. Bundan dolayı -

    • Ciddi kusurların keşfedilmesini geciktirir.

    • Eski gereksinimlerin teslim edilme olasılığı.

  • Küçük ekipler ve projeler için maliyetli olabilecek önemli yönetim yükü.

  • Her aşamada - analistler, tasarımcılar, geliştiriciler, testçiler - deneyimli kaynaklar gerektirir.

  • Test, yalnızca geliştirme tamamlandıktan ve test uzmanları önceki aşamalardan hiçbirine dahil olmadıktan sonra başlar.

  • Her aşama silolarda yürütüldüğünden, işlevler arası ekiplerin uzmanlığı paylaşılmaz.

Şelale Modeli Ne Zaman Kullanılır?

Şelale modelini şu durumlarda kullanabilirsiniz:

  • Gereksinimler çok iyi bilinmektedir.

  • Ürün tanımı sabittir.

  • Teknoloji iyi anlaşılmıştır.

  • Mevcut bir ürünün yeni versiyonu.

  • Mevcut bir ürünü yeni bir platforma taşımak.

  • Yapılandırılmış işlevler arası ekiplere sahip büyük organizasyon.

  • İletişim kanalları organizasyon içinde ve müşteri ile de iyi kurulmuştur.

Evrimsel Prototipleme Modeli

Evrimsel Prototipleme modelini kullanarak yazılım geliştirmede, geliştiriciler gereksinimler aşamasında bir prototip oluşturur. Son kullanıcılar daha sonra prototipi değerlendirir ve geri bildirimde bulunur. Geri bildirim, prototipte düzeltmeler veya ek işlevler olabilir. Geri bildirime dayalı olarak, geliştiriciler prototipi daha da geliştirirler.

Böylece, ürün Prototip → Geribildirim → Rafine Prototip Döngüleri aracılığıyla gelişir ve dolayısıyla Evrimsel Prototipleme adı verilir. Kullanıcı ürünün işlevselliğinden ve çalışmasından memnun olduğunda, prototip kodu nihai ürün teslimi için gerekli standartlara getirilir.

Evrimsel Prototipleme Modeli - Güçlü Yönler

Bir Evrimsel Prototipleme modelinin güçlü yönleri veya avantajları şunlardır:

  • Müşteriler / son kullanıcılar, prototipe bakarak toplandıklarında sistem gereksinimlerini görselleştirebilirler.

  • Geliştiriciler müşterilerden öğrenirler ve bu nedenle etki alanı veya üretim ortamı ile ilgili belirsizlikler yoktur.

  • Esnek tasarım ve geliştirmeye izin verir.

  • Prototip ile etkileşim, ek olarak ihtiyaç duyulan işlevsellik farkındalığını artırır.

  • Beklenmeyen gereksinimler ve gereksinim değişiklikleri kolaylıkla karşılanır.

  • Sürekli ve gözle görülür ilerleme işaretleri üretilir.

  • Doğru ve sürdürülebilir bir son ürünün teslimi.

Evrimsel Prototipleme Modeli - Zayıf Yönler

Evrimsel Prototipleme modelinin zayıf yönleri veya dezavantajları aşağıdaki gibidir -

  • Modelin öngördüğü şey olmasa da, kodla ve düzelt geliştirmede yapılandırılmış geliştirmeyi terk etme eğilimi.

  • Bu model, hızlı ve kirli yöntemler için kötü bir ün kazandı.

  • Genel bakım kolaylığı muhtemelen gözden kaçabilir.

  • Müşteri muhtemelen prototipin nihai olarak teslim edilmesini isteyebilir, ancak geliştiricilere son adımı, yani son ürünün standardizasyonunu uygulama fırsatı vermez.

  • Proje sonsuza kadar devam edebilir (sürekli kapsam sürünerek) ve yönetim bunu takdir etmeyebilir.

Evrimsel Prototipleme Modeli Ne Zaman Kullanılır?

Evrimsel Prototipleme modelini kullanabilirsiniz -

  • Gereksinimler kararsız olduğunda veya açıklığa kavuşturulması gerektiğinde
  • Bir şelale modelinin gereksinimleri açıklama aşaması olarak
  • Kullanıcı arayüzleri geliştirmek için
  • Kısa ömürlü gösteriler için
  • Yeni veya orijinal geliştirme için
  • Yeni bir teknolojiyi uygulamak için

Yinelemeli Artımlı bir modelde, başlangıçta, bir toplam sistemin kısmi bir uygulaması, teslim edilebilir bir durumda olacak şekilde inşa edilir. Artan işlevsellik eklendi. Varsa önceki teslimattan kaynaklanan kusurlar giderilerek çalışan ürün teslim edilir. İşlem, tüm ürün geliştirme tamamlanana kadar tekrarlanır. Bu işlemlerin tekrarlarına yinelemeler denir. Her yinelemenin sonunda, bir ürün artımı sunulur.

Yinelemeli Artımlı Model - Güçlü Yönler

Yinelemeli Artımlı modelin avantajları veya güçlü yönleri şunlardır:

  • Önce önceliklendirilmiş gereksinimleri geliştirebilirsiniz.

  • İlk ürün teslimi daha hızlıdır.

  • Müşteriler önemli işlevleri erkenden alır.

  • İlk teslimat maliyetini düşürür.

  • Her sürüm, müşterinin her zaman çalışan bir ürüne sahip olması için bir ürün artımıdır.

  • Müşteri, her ürün parçasına geri bildirim sağlayabilir, böylece geliştirme sonunda sürprizlerden kaçınabilir.

  • Gereksinim değişiklikleri kolaylıkla yerine getirilebilir.

Yinelemeli Artımlı Model - Zayıf Yönler

Yinelemeli Artımlı modelin dezavantajları şunlardır:

  • Etkili yineleme planlaması gerektirir.

  • Gerekli işlevselliğin dahil edilmesini ve daha sonra değişikliklerin yapılmasını sağlamak için verimli tasarım gerektirir.

  • Artımların tanımlanmasına izin vermek için eksiksiz ve tamamen işlevsel bir sistemin erken tanımını gerektirir.

  • Bazıları diğerleri geliştirilmeden çok önce geliştirildiğinden, iyi tanımlanmış modül arayüzleri gereklidir.

  • Komple sistemin toplam maliyeti daha düşük değildir.

Yinelemeli Artımlı Model Ne Zaman Kullanılır?

Yinelemeli Artımlı model şu durumlarda kullanılabilir -

  • Gereksinimlerin çoğu önceden biliniyor ancak zaman içinde değişmesi bekleniyor.

  • Gereksinimler önceliklidir.

  • Hızlı bir şekilde sunulan temel işlevlere ihtiyaç vardır.

  • Bir projenin uzun geliştirme programları vardır.

  • Bir projenin yeni teknolojisi vardır.

  • Etki alanı ekip için yenidir.

Hızlı Uygulama Geliştirme (RAD) modelinin aşağıdaki aşamaları vardır -

  • Requirements Planning phase - İhtiyaç planlama aşamasında, iş sorunlarını yapısal bir şekilde tartışmak için bir atölye çalışması yapılması gerekir.

  • User Description phase - Kullanıcı Tanımı aşamasında, kullanıcılardan bilgi toplamak için otomatik araçlar kullanılır.

  • Construction phase - İnşaat aşamasında kod üreteçleri, ekran üreteçleri gibi üretkenlik araçları bir zaman çerçevesi içinde “Bitene Kadar Yap” yaklaşımıyla kullanılır.

  • Cut Over phase - Cut over fazında sistemin kurulumu, kullanıcı kabul testleri ve kullanıcı eğitimi yapılır.

Hızlı Uygulama Geliştirme Modeli - Güçlü Yönler

Hızlı Uygulama Geliştirme modelinin avantajları veya güçlü yönleri aşağıdaki gibidir -

  • Daha az ekip üyesi ile azaltılmış döngü süresi ve daha iyi üretkenlik, daha düşük maliyet anlamına gelir.

  • Tüm döngü boyunca müşterinin katılımı, müşteri memnuniyetine ve iş değerine ulaşamama riskini en aza indirir.

  • Odak, gördüğün şeydir modunda (WYSIWYG) koda taşınır. Bu, inşa edilmekte olan şeyin doğru olduğu konusunda netlik sağlar.

  • İş, veri ve süreçlerle ilgili bilgileri yakalamak için modelleme kavramlarını kullanır.

Hızlı Uygulama Geliştirme Modeli - Zayıf Yönler

Hızlı Uygulama Geliştirme modelinin dezavantajları veya güçlü yönleri aşağıdaki gibidir -

  • Hızlandırılmış geliştirme süreci, kullanıcıya hızlı yanıtlar vermelidir.

  • Asla kapatılamama riski.

  • Eski sistemlerle kullanımı zor.

  • Geliştiriciler ve müşteriler, kısaltılmış bir zaman dilimi içinde hızlı ateş faaliyetlerine kendini adamalıdır.

Hızlı Uygulama Geliştirme Modeli Ne Zaman Kullanılır?

Hızlı Uygulama Geliştirme modeli şu durumlarda kullanılabilir:

  • Kullanıcı yaşam döngüsü boyunca dahil olabilir.
  • Proje zaman sınırlamalı olabilir.
  • İşlevsellik aşamalı olarak sağlanabilir.

Hızlı Uygulama Geliştirme modelinin güçlü yönleri takdir edilmekle birlikte, sektörde çok az kullanılmaktadır.

Spiral model, Şelale modeline Risk Analizi ve RAD prototipini ekler. Her döngü, Şelale modeliyle aynı adım dizisini içerir.

Spiral modelin dört kadranı vardır. Bunları detaylı olarak tartışalım.

Kadran 1 - Hedefleri, alternatifleri ve kısıtlamaları belirleyin

  • Objectives - İşlevsellik, performans, donanım / yazılım arayüzü, kritik başarı faktörleri vb.

  • Alternatives - Oluşturun, yeniden kullanın, satın alın, alt sözleşme vb.

  • Constraints - Maliyet, program, arayüz vb.

Çeyrek 2 - Alternatifleri değerlendirin, riskleri belirleyin ve çözün

  • Belirlenen hedeflere ve kısıtlamalara göre alternatifleri inceleyin.

  • Deneyim eksikliği, yeni teknoloji, sıkı programlar vb. Gibi riskleri belirleyin.

  • Proje üzerindeki etkilerini değerlendirerek, gerekli azaltma ve acil durum planlarını belirleyerek ve bunları uygulayarak belirlenen riskleri çözün. Risklerin her zaman izlenmesi gerekir.

Çeyrek 3 - Bir sonraki seviye ürün geliştirin

Tipik faaliyetler şunları içerir:

  • Bir tasarım yaratın
  • Tasarımı inceleyin
  • Kod geliştirin
  • Kodu inceleyin
  • Test ürünü

Çeyrek 4 - Sonraki aşamayı planlayın

Tipik faaliyetler şunları içerir:

  • Proje planı geliştirin
  • Yapılandırma yönetimi planı geliştirin
  • Bir test planı geliştirin
  • Bir kurulum planı geliştirin

Spiral Model - Güçlü Yönler

Spiral yöntemin avantajları veya güçlü yönleri:

  • Çok fazla maliyet gerektirmeden risklerin erken belirtilmesini sağlar.
  • Kullanıcılar, hızlı prototip oluşturma araçları sayesinde sistemi erken görüntüleyebilirler.
  • Önce kritik yüksek riskli işlevler geliştirilir.
  • Tasarımın mükemmel olması gerekmiyor.
  • Kullanıcılar tüm yaşam döngüsü adımlarına yakından dahil edilebilir.
  • Kullanıcılardan erken ve sık geri bildirim.
  • Kümülatif maliyetler sıklıkla değerlendirilir.

Spiral Model - Zayıf Yönler

Spiral yöntemin dezavantajları veya zayıf yönleri şunlardır:

  • Bir sonraki yinelemeye devam etmeye hazır olduğunuzu gösteren hedefler, doğrulanabilir kilometre taşları tanımlamak zor olabilir.

  • Planlama, hedefleri sıfırlama, risk analizi yapma ve prototipleme için harcanan zaman ek yük olabilir.

  • Riskleri değerlendirmek için harcanan zaman, küçük veya düşük riskli projeler için çok büyük olabilir.

  • Spiral model, yeni ekip üyeleri için anlaşılması karmaşıktır.

  • Risk değerlendirme uzmanlığı gereklidir.

  • Spiral sonsuza kadar devam edebilir.

  • Geliştiriciler, geliştirme dışı aşama etkinlikleri sırasında yeniden atanmalıdır.

Spiral Model Ne Zaman Kullanılır?

Spiral model şu durumlarda kullanılabilir:

  • Bir prototipin oluşturulması uygundur.
  • Risk değerlendirmesi önemlidir.
  • Bir proje orta ila yüksek risklidir.
  • Kullanıcılar ihtiyaçlarından emin değiller.
  • Gereksinimler karmaşıktır.
  • Ürün hattı yenidir.
  • Keşif sırasında önemli değişiklikler beklenmektedir.
  • Potansiyel iş değişiklikleri nedeniyle uzun vadeli proje taahhüdü.

Çevik Yöntemler, Çevik manifestoya dayanır ve doğası gereği uyarlanabilirdir. Çevik yöntemler şunları sağlar -

  • Takım İşbirliği.
  • Müşteri işbirliği.
  • Sürekli ve sürekli iletişim.
  • Değişikliklere yanıt.
  • Çalışan bir ürünün hazırlığı.

Zaman kutulu yinelemelerle yinelemeli ve artımlı geliştirmeyi teşvik eden birkaç Çevik yöntem ortaya çıktı. Çevik yöntemler uyarlanabilir olsa da, belirli yöntemin kuralları atlanamaz ve bu nedenle disiplinli bir uygulama gerektirir.

Çevik Yöntemler - Güçlü Yönler

Çevik yöntemin avantajları veya güçlü yönleri:

  • Erken ve sık yayınlar.
  • Değişen gereksinimlerin karşılanması.
  • Müşteri ve geliştiriciler arasında günlük iletişim.
  • Motive olmuş bireyler etrafında inşa edilen projeler.
  • Kendi kendini organize eden ekipler.
  • Basitlik, hemen gerekli olana odaklanır.
  • Gelecek için bina yok ya da kodu aşırı yüklemiyor.
  • Etkinliği artırmak için davranışı ayarlamak için düzenli düşünme.

Çevik Yöntemler - Zayıf Yönler

Spiral yöntemin dezavantajları veya zayıflıkları -

  • Müşteri mevcudiyeti mümkün olmayabilir.

  • Takımlar yöntemin kurallarına uyma konusunda deneyimli olmalıdır.

  • Bir yinelemede sunulması gereken işlevselliğe hızlıca karar vermek için uygun planlama gereklidir.

  • Takımın tahmin becerilerine ve müzakere becerilerine sahip olması beklenir.

  • Takım etkili iletişim becerilerine sahip olmalıdır.

  • Yeni takımlar kendilerini organize edemeyebilir.

  • Zaman kutulu yinelemelerde geliştirmek ve sunmak için disiplin gerektirir.

  • Tasarımın basit ve sürdürülebilir olması gerekir, bu nedenle etkili tasarım becerileri gerektirir.

Çevik yöntemler ne zaman kullanılır?

Çevik yöntemler şu durumlarda kullanılabilir:

  • Uygulama zaman açısından kritiktir.

  • Kapsam sınırlıdır ve daha az resmidir (çevik yöntemlerin bazı çevik yöntemlere belirli uzantılarla birlikte daha büyük projelere ölçeklenmesi devam etmektedir).

  • Organizasyon disiplinli yöntemler kullanır.

Daha önceki SDLC modelleri daha çok istikrar, öngörülebilirlik ve azalan getiri uygulamalarına yöneliktir. İnternet Platformları gibi endüstri, geri dönüş ortamlarını, öngörülemeyen, doğrusal olmayan ve hızlı yaklaşımları artırmak için hareket ediyor.

Uyarlanabilir Yazılım Geliştirme (ASD) bu sorunları çözmek için gelişti. Ürün geliştirmeyi yönetme yeteneğini artırmak için yönetim açısından en önemli faktör olarak ortaya çıkmaya odaklanır.

Jim Highsmith'in sözleriyle, "Uyarlanabilir Yazılım Geliştirme çerçevesi, geleneksel Yazılım Geliştirme metodolojilerindeki yıllara dayanan deneyime, Hızlı Uygulama Geliştirme (RAD) teknikleri hakkında danışmanlık, uygulama ve yazma ve ürün geliştirmelerini yönetmek için yüksek teknolojili yazılım şirketleriyle birlikte çalışmaya dayanmaktadır. uygulamalar ”.

Şelale modelinin yetersiz geri bildirimle doğrusallık ve öngörülebilirlik ile karakterize edildiği bulunmuştur. Bir dizi olarak görülebilirPlan → Build → Implement.

Spiral model gibi Evrimsel Yaşam Döngüsü modelleri, Deterministik yaklaşımı Uyarlanabilir olana taşıdı. Plan → Build → Revise Cycles.

Bununla birlikte, uygulayıcıların zihniyeti, uzun vadeli öngörülebilirliğin kısa vadeli öngörülebilirliğe dönüşmesiyle belirleyici kalmıştır. RAD gibi Evrimsel Yaşam Döngüsü modellerinin uygulamalarının daha az Belirleyici olduğu bulunmuştur.

Uyarlanabilir Yaşam Döngüsü

Uyarlanabilir model farklı bir bakış açısıyla oluşturulmuştur. Evrimsel model gibi döngüsel olsa da, fazın isimleri giderek karmaşıklaşan sistemlerin öngörülemez doğasını yansıtır.

Uyarlanabilir Gelişim, evrimsel mirasının ötesine iki temel yolla gider -

  • Belirleyiciliği açıkça Ortaya Çıkarma ile değiştirir.

  • Yaşam döngüsündeki bir değişikliğin ötesinde, yönetim tarzındaki daha derin bir değişikliğe kadar gider.

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsünün üç aşaması şunlardır:

  • Speculate - Spekülasyon, belirleyici kelime planlamasının, ürün özelliklerinin planlanmasının veya proje yönetimi görevlerinin planlanmasının yerini alır.

  • Collaborate - İşbirliği, aralarında bir denge kurmayı temsil eder

    • Geleneksel proje yönetimi anlayışı ile yönetmek ve

    • Ortaya çıkması için gereken işbirliği ortamını yaratmak ve sürdürmek.

  • İşbirlikçi Faaliyetler, ortamdaki değişikliklerin hızını koruyan ürünler oluşturur.

  • Learn - Learn, hem geliştiricileri hem de müşterileri, bir sonrakinin yönünü öğrenmek için her geliştirme döngüsünün sonuçlarını kullanmayı hedefler.

Bu bölümde, Uyarlanabilir Yazılım Geliştirme'nin çeşitli kavramlarını anlayacağız.

Karmaşık Uyarlamalı Sistemler (CAS) Teorisi

Santa Fe enstitüsündeki Brian Arthur ve meslektaşları, Fizik, Biyoloji, Evrim ve Ekonomi anlayışında devrim yaratmak için Karmaşık Uyarlanabilir Sistemler (CAS) teorisini kullandılar.

Brian Arthur, yirmi yılı aşkın süredir, ana akım iktisatçıları, azalan getiri, denge ve deterministik dinamikler gibi temel varsayımların hakim olduğu görüşlerinin artık gerçekliği anlamak için yeterli olmadığına ikna etmeye çalışarak doruğa ulaştı. Yeni dünya, artan getiri, istikrarsızlık ve neden ve sonucu belirleyememe durumlarından biridir.

İki dünya davranış, stil ve kültür açısından farklılık gösterir. Onlar için -

  • Farklı Yönetim Teknikleri
  • Farklı Stratejiler
  • Farklı Anlayış

Karmaşık Yazılım Geliştirme

Yazılım Uygulamaları kapsamının patlamasıyla, yazılım geliştirme kuruluşları bile yukarıda bahsedildiği gibi benzer çelişkiler yaşamaktadır.

  • Tek Dünya, istikrar ve öngörülebilirliğin temellerine dayanan yönetim uygulamalarından türetilen (Arthur'un terimleriyle azalan getiri anlamına gelir) belirleyici gelişme ile temsil edilir.

  • İkinci Dünya, azalan sektörlerden, öngörülemeyen, doğrusal olmayan ve hızlı, artan geri dönüş ortamlarına geçen endüstriler tarafından temsil edilmektedir.

Bu ikinci dünyanın sorunlarını ele almak için Jig Highsmith, Belirleyici Yazılım Geliştirmeden farklı bir Adaptif Yazılım Geliştirme çerçevesi sundu.

Uyarlanabilir Yazılım Geliştirme, karmaşık sistemleri ele almaya odaklanır -

  • Geliştirme yaşam döngüsü için Uyarlanabilir Yazılım Geliştirme.

  • Geleneksel proje yönetimi uygulamalarından farklı bir zihniyet gerektiren Uyarlanabilir Yönetim Teknikleri.

Bu eğitimde, bu iki uygulamayı da anlayabilirsiniz.

Uyarlanabilir Yazılım Geliştirme (ASD) iki perspektife dayanmaktadır -

  • Bu bölümün ilk bölümünde verildiği gibi, Karmaşık Uyarlanabilir Sistemler (CAS) teorisine dayalı kavramsal perspektif.

  • Dayalı Pratik Perspektif

    • Deterministik yazılım geliştirme metodolojilerinde yılların tecrübesi.

    • Hızlı Uygulama Geliştirme (RAD) teknikleri hakkında danışmanlık, uygulama ve yazma; ve yüksek teknoloji yazılım şirketleriyle ürün geliştirmelerini yönetmek için çalışmak.

Bu bölümde, Uyarlanabilir Yazılım Geliştirme'nin kavramsal perspektifini anlayacaksınız.

Karmaşık Uyarlamalı Sistemler (CAS) Kavramları

Karmaşık Uyarlamalı Sistemler (CAS) teorisinin birçok kavramı vardır. Uyarlanabilir Yazılım Geliştirme, bu kavramlardan ikisine dayanmaktadır -

  • Emergence
  • Complexity

Çıkış

Karmaşık yazılım ürünü geliştirme projelerinde, sonuçlar doğal olarak tahmin edilemez. Ancak bu tür ortamlardan her zaman başarılı ürünler ortaya çıkar.

Bu, Karmaşık Uyarlamalı Sistemler (CAS) teorisinde gösterildiği gibi Ortaya Çıkma ile olabilir. Basit bir örnekle, kuşların sürü davranışıyla anlaşılabilir.

Bir kuş sürüsünü gözlemlediğinizde, şunu fark edersiniz -

  • Her kuş dener

    • Diğer kuşlar da dahil olmak üzere ortamdaki diğer nesnelerle minimum mesafeyi koruyun.

    • Çevresindeki kuşlarla hızları eşleştirin.

    • Çevresindeki kuş kütlesinin algılanan merkezine doğru ilerleyin.

  • Grup için hiçbir davranış kuralı yoktur. Tek kural, bireysel kuşların davranışları ile ilgilidir.

  • Bununla birlikte, kuş sürüsü gibi ortaya çıkan bir davranış vardır. Hatalı kuşlar yetişmek için acele ettiğinde, sürü engellerin etrafından ayrılır ve diğer tarafta yeniden şekillenir.

Bu, Adaptif Gelişimdeki en zor zihinsel model değişikliklerinin gerekliliğini gösterir - Bu bireysel özgürlüğü yönetme ve organize etme yollarından, yaratıcı yeni bir düzenin spontane kendini örgütlemeden beklenmedik bir şekilde ortaya çıktığı fikrine.

Gelişmenin yanı sıra yönetim açısından da ortaya çıkış en önemli kavramdır.

Karmaşıklık

Yazılım Geliştirme bağlamında, Karmaşıklık şununla ilgilidir:

  • Geliştiriciler, müşteriler, satıcılar, rakipler ve hissedarlar gibi bir ekibin bireyleri, sayıları ve hızları.

  • Boyut ve teknolojik karmaşıklık.

Uyarlanabilir Yazılım Geliştirme Uygulamaları

Uyarlanabilir Yazılım Geliştirme, yazılım yönetimi uygulamalarına farklı bir bakış açısı sunar. Aşağıdaki bölümlerde, her ikisi de gereksinimleri toplamak için sonuçları olan iki önemli uygulamayı anlayabilirsiniz - Kalite ve RAD.

Tüm uygulamaların ayrıntılarını bu öğreticide Uyarlanabilir Yazılım Geliştirme Uygulamaları bölümünde bulabilirsiniz.

Kalite

Karmaşık bir ortamda, "İlk seferde doğru yap" şeklindeki asırlık uygulama, başlangıçta neyin doğru olduğunu tahmin edemeyeceğiniz için işe yaramaz. Doğru değeri üretmek için bir hedefe sahip olmalısınız. Bununla birlikte, karmaşık ortamda, kapsam (özellikler, performans, kusur seviyeleri), zamanlama ve kaynaklar gibi değer bileşenlerinin kombinasyonları ve permütasyonları o kadar geniştir ki hiçbir zaman optimum bir değer olamaz. Bu nedenle odak noktası, rekabetçi pazarda en iyi değeri sunmak için değişmektir.

RAD Uygulamaları

RAD Uygulamaları genellikle aşağıdakilerin bir kombinasyonunu içerir -

  • Evrimsel Yaşam Döngüsü
  • Müşteri Odak Grupları, JAD Oturumları, Teknik İncelemeler
  • Zaman Kutulu Proje Yönetimi
  • Sürekli Yazılım Mühendisliği
  • Savaş odaları olan özel takımlar

RAD projelerinin doğasında uyarlanabilir, ortaya çıkan bir tadı vardır. Birçok BT kuruluşu RAD'ye karşıdır. Bununla birlikte, Microsoft ve diğerleri, temel dünya görüşleri hakkında soruları gündeme getirdiği için RAD ile karşılaştırılabilir teknikler kullanarak inanılmaz derecede büyük ve karmaşık yazılımlar üretti.

RAD uygulamaları ve Microsoft süreci, Uyarlanabilir Geliştirme uygulamasının örnekleridir. Onlara bir etiket vermek (yani, Adaptive Development) ve artan bir bilimsel bilgi birikimi olduğunu fark etmek (yani, CAS teorisi) neden işe yaradıklarını açıklar. Bu, bu uygulamaların daha kapsamlı kullanımı için bir temel oluşturmalıdır.

Uyarlanabilir Yazılım Geliştirme, RAD uygulamalarından gelişmiştir. Bu uygulamalara ekip yönleri de eklendi. Yeni Zelanda'dan Kanada'ya kadar şirketler, çok çeşitli proje ve ürün türleri için uyarlamalı Yazılım Geliştirme'yi kullandı.

Jim Highsmith, 2000 yılında Adaptive Software Development'ı yayınladı.

Uyarlanabilir Yazılım Geliştirme uygulamaları değişime uyum sağlama yeteneği sağlar ve çok az planlama ve öğrenme ile gelişen ürünlerle çalkantılı ortamlara uyarlanabilir.

ASD Yaşam Döngüsünün Aşamaları

Uyarlanabilir Yazılım Geliştirme, Evrimsel model gibi döngüseldir ve faz adları karmaşık sistemlerdeki öngörülemezliği yansıtır. Uyarlanabilir geliştirme yaşam döngüsündeki aşamalar:

  • Speculate
  • Collaborate
  • Learn

Bu üç aşama, Uyarlanabilir Yazılım Geliştirme'nin dinamik doğasını yansıtır. Uyarlanabilir Gelişim, Belirleyiciliği açıkça Ortaya Çıkarma ile değiştirir. Yaşam döngüsündeki basit bir değişikliğin ötesinde, yönetim tarzındaki daha derin bir değişikliğe kadar gider. Uyarlanabilir Yazılım Geliştirme, dinamik bir Spekülasyon-İşbirliği-Öğrenme Yaşam Döngüsüne sahiptir.

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsü görevlere değil sonuçlara odaklanır ve sonuçlar uygulama özellikleri olarak tanımlanır.

Spekülasyon yapmak

Plan terimi çok belirleyicidir ve istenen sonuç hakkında oldukça yüksek derecede kesinlik gösterir. Plana uygunluğun örtük ve açık hedefi, yöneticinin projeyi yenilikçi yönlere yönlendirme yeteneğini kısıtlar.

Uyarlanabilir Yazılım Geliştirmede, plan terimi, spekülasyon terimi ile değiştirilir. Ekip spekülasyon yaparken planlamayı bırakmaz, ancak karmaşık problemlerdeki belirsizliğin gerçekliğini kabul eder. Spekülasyon, keşif ve denemeyi teşvik eder. Kısa döngülü yinelemeler teşvik edilir.

İşbirliği yap

Karmaşık uygulamalar inşa edilmez, gelişir. Karmaşık uygulamalar, büyük miktarda bilginin toplanmasını, analiz edilmesini ve soruna uygulanmasını gerektirir. Çalkantılı ortamlarda yüksek bilgi akışı oranları vardır. Bu nedenle karmaşık uygulamalar, büyük miktarda bilginin toplanmasını, analiz edilmesini ve soruna uygulanmasını gerektirir. Bu, yalnızca ekip işbirliği ile ele alınabilen çeşitli Bilgi gereksinimleri ile sonuçlanır.

İşbirliği, sonuç üretmek, bilgiyi paylaşmak veya kararlar almak için ortak çalışma yeteneğini gerektirir.

Proje yönetimi bağlamında İşbirliği, geleneksel yönetim teknikleriyle yönetme ile ortaya çıkması için gereken işbirliği ortamını yaratma ve sürdürme arasındaki dengeyi gösterir.

Öğrenin

Yaşam Döngüsünün Öğrenme kısmı, projenin başarısı için çok önemlidir. Takım aşağıdaki gibi uygulamaları kullanarak bilgilerini sürekli olarak geliştirmek zorundadır:

  • Teknik İncelemeler
  • Proje Geçmişi
  • Müşteri Odak Grupları

İncelemeler, her yinelemeden sonra yapılmalıdır. Hem geliştiriciler hem de müşteriler varsayımlarını inceler ve her bir geliştirme döngüsünün sonuçlarını bir sonrakinin yönünü öğrenmek için kullanır. Takım öğrenir -

  • Ürün değişiklikleri hakkında

  • Ürünlerin nasıl geliştirildiğine ilişkin temel varsayımlarda daha temel değişiklikler

Ekibin büyük hatalardan çok küçük hatalardan ders alabilmesi için yinelemelerin kısa olması gerekir.

Tahmin Edin - İşbirliği Yapın - Bir Bütün Olarak Döngüyü Öğrenin

Yukarıda verilen Spekülasyon-İşbirliği Yap-Öğren döngüsünden gözlemlediğiniz gibi, üç aşamanın doğrusal olmadığı ve örtüştüğü açıktır.

Uyarlanabilir bir çerçeveden aşağıdakileri gözlemliyoruz.

  • Öğrenmeden İşbirliği Yapmak veya İşbirliği Yapmadan Öğrenmek zordur.

  • Öğrenmeden Spekülasyon Yapmak veya Spekülasyon Yapmadan Öğrenmek Zordur.

  • İşbirliği Yapmadan Spekülasyon Yapmak veya Spekülasyon Yapmadan İşbirliği Yapmak Zordur.

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsü altı temel özelliğe sahiptir -

  • Misyon odaklı
  • Özellik tabanlı
  • Iterative
  • Time-boxed
  • Risk odaklı
  • Toleranslıyı değiştir

Bu bölümde, Uyarlanabilir Yazılım Geliştirmenin bu altı özelliğini anlayacaksınız.

Misyon odaklı

Pek çok proje için, ekibe rehberlik eden genel misyon iyi ifade edilmiştir, ancak gereksinimler projenin başlangıcında belirsiz olabilir. Misyon beyanları, başlangıçta keşfi teşvik eden ancak bir proje boyunca dar bir odak noktası olan kılavuzlar görevi görür. Bir görev, sabit bir hedef yerine sınırlar sağlar. Misyon beyanları ve bu ifadelerle sonuçlanan tartışmalar, kritik proje ödünleşim kararları vermek için yön ve kriterler sağlar.

Net bir görev ve sürekli bir görev iyileştirme uygulaması olmadan, yinelemeli yaşam döngüleri, gelişimde ilerleme olmadan ileri geri sallanan salınımlı yaşam döngüleri haline gelir.

Özellik tabanlı

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsü, görevlere değil uygulama özelliklerine dayanır. Özellikler, müşterinin önceliklerine göre bir yineleme sırasında geliştirilen işlevlerdir.

Müşteriler geri bildirim sağladığında, özellikler birkaç yinelemede gelişebilir.

Uygulama sonrasında müşteriye doğrudan sonuç veren uygulama özellikleri birincildir. Kullanım kılavuzu gibi müşteri odaklı bir belge de bir özellik olarak kabul edilir. Veri modeli gibi diğer belgeler, çıktılar olarak tanımlansa bile her zaman ikincildir.

Yinelemeli

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsü yinelemelidir ve geri bildirim almak, ortaya çıkan öğrenmeyi özümsemek ve daha fazla geliştirme için doğru yönü belirlemek için sık sürümlere odaklanır.

Zaman kutulu

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsünde, yinelemeler zaman sınırlıdır. Ancak, Uyarlanabilir Yazılım Geliştirmedeki zaman sınırlamasının son tarihlerle ilgili olmadığı unutulmamalıdır. Ekibin uzun saatler boyunca işbirliğine dayalı bir ortama meydan okumak veya çıktıların kalitesinden ödün vermek için çalışmasını sağlamak için kullanılmamalıdır.

Uyarlanabilir Yazılım Geliştirmede, zaman sınırlaması, gerektiği zaman ve gerektiği zaman zor takas kararlarına odaklanmak ve zorlamak için bir yön olarak kabul edilir. Değişim oranlarının yüksek olduğu belirsiz bir ortamda, işi bitirmek için zaman sınırlaması gibi periyodik bir zorlama işlevinin olması gerekir.

Risk odaklı

Uyarlanabilir Yazılım Geliştirmede yinelemeler, kritik risklerin tanımlanması ve değerlendirilmesi ile yönlendirilir.

Değişime toleranslı

Uyarlanabilir Yazılım Geliştirme değişime toleranslıdır, değişimi rekabet avantajını birleştirme yeteneği olarak görür, ancak geliştirme için bir sorun olarak görmez.

Uyarlanabilir Yazılım Geliştirme uygulamaları, sürekli değişimi norm olarak kabul edecek şekilde donatılmış yaşam döngüsü ile sürekli adaptasyona olan inançla yönlendirilir.

Uyarlanabilir Yazılım Geliştirme Yaşam Döngüsü şunlara adanmıştır:

  • Devamlı öğrenme
  • Yönü değiştir
  • Re-evaluation
  • Belirsiz bir geleceğe bakmak
  • Geliştiriciler, yönetim ve müşteriler arasında yoğun işbirliği

Uyarlanabilir SDLC

Uyarlanabilir Yazılım Geliştirme, RAD'yi Yazılım Mühendisliği En İyi Uygulamaları ile birleştirir, örneğin:

  • Proje başlangıcı.
  • Uyarlanabilir döngü planlaması.
  • Eşzamanlı bileşen mühendisliği.
  • Kalite incelemesi.
  • Nihai QA ve sürüm.

Uyarlanabilir Yazılım Geliştirme uygulamaları aşağıdaki gibi gösterilebilir -

Yukarıda gösterildiği gibi, Uyarlanabilir Yazılım Geliştirme uygulamaları aşağıdaki gibi üç aşamaya yayılmıştır -

  • Spekülasyon - Başlatma ve planlama

    • Proje başlangıcı

    • Tüm proje için zaman sınırı oluşturma

    • Yineleme sayısına karar verin ve her birine bir zaman aralığı atayın

    • Yinelemelerin her biri için bir tema veya hedef geliştirin

    • Her bir yinelemeye özellikler atayın

  • Collaborate - Eşzamanlı özellik geliştirme

    • Dağıtılmış ekipler için işbirliği

    • Daha küçük projeler için işbirliği

    • Daha büyük projeler için işbirliği

  • Learn - Kalite İncelemesi

    • Müşterinin bakış açısından sonuç kalitesi

    • Teknik açıdan sonuç kalitesi

    • Teslimat ekibinin işleyişi ve ekip üyelerinin yararlandığı uygulamalar

    • Proje durumu

Spekülasyon - Başlatma ve Planlama

Uyarlanabilir Yazılım Geliştirmede, spekülasyon aşaması iki faaliyete sahiptir -

  • Initiation
  • Planning

Spekulate, başlatma ve planlama aşamasında tekrar tekrar gerçekleştirilebilecek beş uygulamaya sahiptir. Onlar -

  • Proje başlangıcı
  • Tüm proje için zaman sınırı oluşturma
  • Yineleme sayısına karar verin ve her birine bir zaman aralığı atayın
  • Yinelemelerin her biri için bir tema veya hedef geliştirin
  • Her bir yinelemeye özellikler atayın

Proje başlangıcı

Proje Başlatma şunları içerir:

  • Projenin misyonunu ve hedeflerini belirlemek
  • Kısıtlamaları anlamak
  • Proje organizasyonunun kurulması
  • Gereksinimleri belirleme ve özetleme
  • İlk boyut ve kapsam tahminlerinin yapılması
  • Temel proje risklerinin belirlenmesi

Proje başlatma verileri, hızı ana unsur olarak dikkate alarak bir ön JAD oturumunda toplanmalıdır. Başlatma, küçük ve orta ölçekli projeler için yoğunlaştırılmış iki ila beş günlük bir çabayla veya daha büyük projeler için iki ila üç haftalık bir çabayla tamamlanabilir.

JAD oturumları sırasında, özellikleri tanımlamak ve nesneye, verilere veya diğer mimari modele genel bir bakış oluşturmak için gereksinimler yeterince ayrıntılı bir şekilde toplanır.

Tüm Proje için Zaman Kutusunun Belirlenmesi

Proje başlatma çalışmasından kaynaklanan kapsam, özellik seti gereksinimleri, tahminler ve kaynak kullanılabilirliğine dayalı olarak tüm proje için zaman çerçevesi oluşturulmalıdır.

Bildiğiniz gibi, Spekülasyon tahmin etmekten vazgeçmez, sadece tahminlerin yanlış gidebileceğini kabul etmek anlamına gelir.

Yinelemeler ve Zaman kutusu

Genel proje kapsamına ve belirsizlik derecesine bağlı olarak yineleme sayısına ve bireysel yineleme uzunluklarına karar verin.

Küçük ila orta ölçekli bir uygulama için -

  • Yinelemeler genellikle dört ila sekiz hafta arasında değişir.
  • Bazı projeler en iyi iki haftalık yinelemelerle çalışır.
  • Bazı projeler sekiz haftadan uzun sürebilir.

Sizin için neyin işe yaradığına bağlı olarak zamanı seçin. Yinelemelerin sayısına ve yinelemelerin her birinin uzunluğuna karar verdiğinizde, yinelemelerin her birine bir zamanlama atayın.

Bir Tema veya Hedef Geliştirin

Ekip üyeleri, her yineleme için bir tema veya hedef geliştirmelidir. Bu, Scrum'daki Sprint Hedefine benzer bir şeydir. Her yineleme, inceleme ve geri bildirim sağlamak için ürünü müşteriye görünür kılan ürün işlevselliğini gösterebilen bir dizi özellik sunmalıdır.

Yinelemeler dahilinde, yapılar, entegrasyon sürecini mümkün kılan ve ürünü geliştirme ekibine görünür kılan, tercihen günlük olarak çalışan özellikler sunmalıdır. Test, özellik geliştirmenin devam eden, ayrılmaz bir parçası olmalıdır. Proje sonuna kadar geciktirilmemelidir.

Özellikleri Ata

Geliştiriciler ve müşteriler, her bir yinelemeye birlikte özellikler atamalıdır. Bu özellik ataması için en önemli kriter, her yinelemenin müşteriye önemli işlevselliğe sahip görünür bir özellik kümesi sunması gerektiğidir.

Özniteliklerin yinelemelere atanması sırasında -

  • Geliştirme ekibi özellik tahminlerini, riskleri ve bağımlılıkları bulmalı ve bunları müşteriye sağlamalıdır.

  • Müşteriler, geliştirme ekibi tarafından sağlanan bilgileri kullanarak özellik önceliklendirmeye karar vermelidir.

Bu nedenle, yineleme planlaması özellik tabanlıdır ve geliştiriciler ve müşterilerle bir ekip olarak yapılır. Deneyimler, bu tür planlamanın, proje yöneticisinin göreve dayalı planlamasına göre projenin daha iyi anlaşılmasını sağladığını göstermiştir. Ayrıca, özellik tabanlı planlama, her bir projenin benzersizliğini yansıtır.

İşbirliği ─ Eşzamanlı Özellik Geliştirme

İşbirliği aşamasında, odak noktası geliştirmedir. İşbirliği aşamasının iki etkinliği vardır -

  • Geliştirme ekibi işbirliği yapar ve çalışan bir yazılım sunar.

  • Proje yöneticileri, işbirliğini ve eşzamanlı geliştirme faaliyetlerini kolaylaştırır.

İşbirliği, geliştirme ekibini, müşterileri ve yöneticileri kapsayan ortak bir yaratım eylemidir. Paylaşılan yaratım, güven ve saygı ile beslenir.

Takımlar şu konularda işbirliği yapmalıdır -

  • Teknik problemler
  • İş gereksinimleri
  • Hızlı karar verme

Uyarlanabilir Yazılım Geliştirmede İşbirliği aşamasıyla ilgili uygulamalar aşağıdadır -

  • Dağıtılmış ekipler için işbirliği
  • Daha küçük projeler için işbirliği
  • Daha büyük projeler için işbirliği

Dağıtılmış Ekipler için İşbirliği

Dağıtık ekipleri içeren projelerde aşağıdakiler dikkate alınmalıdır -

  • Değişen ittifak ortakları
  • Geniş tabanlı bilgi
  • İnsanların etkileşim şekli
  • Karşılıklı bağımlılıkları yönetme yolları

Daha Küçük Projeler için İşbirliği

Daha küçük projelerde, ekip üyeleri fiziksel yakınlıkta çalışırken, etkili olduğu görüldüğünden, resmi olmayan koridor sohbetleri ve yazı tahtası yazılarıyla işbirliği yapılması teşvik edilmelidir.

Daha Büyük Projeler için İşbirliği

Daha büyük projeler, ek uygulamalar, işbirliği araçları ve proje yöneticisi etkileşimi gerektirir ve bağlama dayalı olarak düzenlenmelidir.

Öğrenin - Kalite İncelemesi

Uyarlanabilir Yazılım Geliştirme, 'Deney ve Öğren' kavramını teşvik eder.

Hatalardan ve deneylerden ders almak, ekip üyelerinin kısmen tamamlanmış kodu ve eserleri erken paylaşmasını gerektirir:

  • Hataları bul
  • Onlardan öğren
  • Küçük sorunları daha büyük hale gelmeden bularak yeniden çalışmayı azaltın

Her geliştirme yinelemesinin sonunda, öğrenilecek dört genel kategori vardır -

  • Müşterinin bakış açısından sonuç kalitesi
  • Teknik açıdan sonuç kalitesi
  • Teslimat ekibinin ve uygulama ekibinin işleyişi
  • Proje durumu

Müşteri Perspektifinden Sonuç Kalitesi

Uyarlanabilir Yazılım Geliştirme projelerinde müşterilerden geri bildirim almak birinci önceliktir. Bunun için önerilen uygulama bir müşteri odak grubudur. Bu oturumlar, uygulamanın çalışma modelini keşfetmek ve müşteri değişiklik taleplerini kaydetmek için tasarlanmıştır.

Müşteri odak grubu oturumları, jad oturumlarına benzer şekilde kolaylaştırılmış oturumlardır, ancak gereksinimler oluşturmak veya proje planlarını tanımlamak yerine, uygulamanın kendisini gözden geçirmek için tasarlanmıştır. Müşteriler, bir yinelemeden kaynaklanan çalışan yazılım hakkında geri bildirim sağlar.

Teknik Açıdan Sonuç Kalitesi

Uyarlanabilir Yazılım Geliştirme projelerinde teknik eserlerin periyodik olarak gözden geçirilmesine önem verilmelidir. Kod İncelemeleri sürekli olarak yapılmalıdır. Teknik mimari gibi diğer teknik eserlerin incelemeleri haftalık olarak veya bir yinelemenin sonunda gerçekleştirilebilir.

Uyarlanabilir Yazılım Geliştirme projelerinde ekip kendi performansını periyodik olarak izlemelidir. Retrospektifler, ekipleri ekip olarak kendileri ve çalışmaları hakkında birlikte öğrenmeye teşvik eder.

Yineleme sonu retrospektifleri, aşağıdaki gibi periyodik ekip performansının kendi kendini incelemesini kolaylaştırır:

  • Neyin işe yaramadığını belirleyin.
  • Takımın daha fazla yapması gereken şey.
  • Takımın daha az yapması gereken şey.

Proje Durumu

Proje durumu incelemesi, daha fazla çalışmanın planlanmasına yardımcı olur. Uyarlanabilir yazılım geliştirme projelerinde, proje durumunun belirlenmesi özellik tabanlı bir yaklaşımdır, her bir yinelemenin sonunda tamamlanmış özelliklerle işaretlenen yazılımın çalışması ortaya çıkar.

Proje Durumu incelemesi şunları içermelidir -

  • Proje nerede?
  • Planlara karşı proje nerede?
  • Proje nerede olmalı?

Uyarlanabilir Yazılım Geliştirme projelerindeki planlar spekülatif olduğundan, yukarıdaki 2. sorudan daha fazlası, 3. soru önemlidir. Yani, proje ekibi ve müşterilerin sürekli olarak kendilerine sormaları gerekiyor, "Şimdiye kadar neler öğrendik ve nereye gitmemiz gerektiği konusundaki bakış açımızı değiştiriyor mu?"

Geleneksel yazılım yönetiminin bir akış şeması aşağıda gösterilmiştir.

Geleneksel yazılım yönetimi, komuta-kontrol terimi ile karakterize edilmiştir.

Birçok kuruluş, optimizasyon, verimlilik, öngörülebilirlik, kontrol, titizlik ve süreç iyileştirme geleneğine sahiptir. Bununla birlikte, ortaya çıkan bilgi çağı ekonomisi uyum, hız, işbirliği, doğaçlama, esneklik, yenilikçilik ve esneklik gerektirir.

Harvard iş inceleme ve yönetim kitapları yetkilendirme, katılımcı yönetim, öğrenen organizasyon, insan merkezli yönetim vb. Gibi terimlerle ortaya çıktı, ancak bunların hiçbiri modern organizasyonların yönetimine konulmuyor.

Uyarlanabilir Yazılım Geliştirme bağlamında, boşluk çok daha geniş görünüyor ve diğer alanlarda başarılı olduğu kanıtlanmış Uyarlanabilir yönetim tekniklerini dikkate almak gerekiyor.

Uyarlanabilir Yönetim

Uyarlanabilir yönetim, kaynak yöneticilerinin paydaşlar ve bilim adamları ile ekip olarak birlikte çalıştığı ortamlarda aşağıdaki hedeflerle başarılı olduğunu kanıtlamıştır:

  • Yönetilen sistemlerin insan müdahalelerine nasıl tepki verdiğini öğrenmek.

  • Gelecekte kaynak politikalarını ve uygulamalarını iyileştirmek.

Uyarlanabilir yönetimin arkasındaki ilke, birçok kaynak yönetimi faaliyetinin, sonuçları önceden güvenilir bir şekilde tahmin edilemediği için deneyler olmasıdır. Bu deneyler daha sonra gelecekteki iyileştirmeler için öğrenme fırsatları olarak kullanılır.

Uyarlanabilir yönetim, yeni bilgiler karşısında ve çeşitli paydaş hedefleri ve tercihleri ​​ortamında zamanında yanıt verme yeteneğini artırmayı amaçlamaktadır. Paydaşları, çevresel belirsizlikler araştırılırken ve daha iyi anlaşılırken anlaşmazlıkları bağlamaya ve bunları düzenli bir şekilde tartışmaya teşvik eder.

Uyarlanabilir yönetim, paydaşların, yöneticilerin ve diğer karar vericilerin bilginin sınırlarını ve kusurlu bilgilere göre hareket etme ihtiyacını anlamasına yardımcı olur.

Uyarlanabilir yönetim, aşağıdakileri açıkça belirterek verilen kararların değiştirilmesine yardımcı olur:

  • Kararlar geçicidir.
  • Bir yönetimin kararının her zaman doğru olması gerekmez.
  • Değişiklikler bekleniyor.

İki tür Uyarlanabilir yönetim yaklaşımı vardır -

  • Pasif Uyarlanabilir Yönetim.
  • Aktif Uyarlamalı Yönetim.

Pasif Uyarlanabilir Yönetim

Uyarlanabilir yönetim, bilimsel bilgiyi geliştirmeyi ve böylece belirsizlikleri azaltmayı amaçlar.

Pasif Uyarlanabilir yönetim içinde, mevcut bilgi ve anlayışa dayalı olarak tercih edilen tek bir eylem şekli seçilir. Yönetim eylemlerinin sonuçları izlenir ve sonraki kararlar sonuçlara göre ayarlanır.

Bu yaklaşım, öğrenmeye ve etkili yönetime katkıda bulunur. Ancak, seçilen eylem seyrinin ötesine geçen koşullar için bilimsel ve yönetim yeteneklerini geliştirme yeteneği sınırlıdır.

Aktif Uyarlamalı Yönetim

Aktif Uyarlanabilir bir yönetim yaklaşımı, yönetim eylemleri gerçekleştirilmeden önce bilgileri gözden geçirir.

Daha sonra, tek bir modelden ziyade, bir dizi rakip, alternatif ekosistem sistemi modelleri ve ilgili tepkiler (örneğin, demografik değişiklikler; eğlence amaçlı kullanımlar) geliştirilir. Yönetim seçenekleri, bu alternatif modellerin değerlendirmelerine göre seçilir.

Liderlik-İşbirliği Yönetimi

Uyarlanabilir yönetim, Uyarlanabilir Yazılım Geliştirme için en uygun olanıdır. Yaklaşım kaynak yöneticilerine, yani insanlarla çalışabilen, insan müdahalelerine izin veren ve dostane bir ortam yaratabilen yöneticileri gerektirir.

Yazılım geliştirmede liderler genellikle bu sorumlulukları üstlenirler. Komutanlardan çok liderlere ihtiyacımız var. Liderler işbirlikçidir ve ekiple birlikte çalışır. İşbirlikçi Liderlik, Adaptif gelişimde en çok aranan uygulamadır.

Liderler aşağıdaki niteliklere sahiptir:

  • Kavrayın ve yönü ayarlayın.

  • İlgili kişileri etkileyin ve rehberlik sağlayın.

  • Ekipte işbirliği yapın, kolaylaştırın ve makro yönetin.

  • Yön vermek.

  • Yetenekli kişilerin yenilikçi, yaratıcı olabileceği ve etkili kararlar alabileceği ortamlar oluşturun.

  • Ara sıra komuta etmeleri gerektiğini anlayın, ancak bu onların baskın tarzı değildir.