Yazılım Mühendisliği

Çevik Yazılım Geliştirme

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

Giriş

Classroom

Sınıf Kodu: xog7rwhi
classroom.google.com → Sınıfa katıl → kodu girin (kurumsal hesapla).

Öğrenme Kazanımları

Bu dersin sonunda:

Çevik yaklaşımın ortaya çıkış nedenlerini ve Çevik Manifesto’nun temel değerlerini açıklayabilecek,
Plan odaklı ve çevik geliştirmeyi proje koşullarına göre karşılaştırabilecek,
Bir kullanıcı ihtiyacını küçük öykülere, kabul kriterlerine ve geliştirme görevlerine ayırabilecek,
XP’nin kullanıcı öyküsü, yeniden düzenleme, test odaklı geliştirme ve eşli programlama pratiklerini örnekleyebilecek,
Çevik yöntemleri büyük sistemlere ölçeklendirmenin zorluklarını ve temel stratejilerini açıklayabilecek.

Derse Genel Bakış

İşlenecek Konular

Çevik Yöntemler: Neden ortaya çıktı? Temel felsefesi nedir?
Plan Odaklı ve Çevik Geliştirme: Temel farklar ve hibrit yaklaşımlar.
Çevik Geliştirme Teknikleri: Ekstrem Programlama (XP) ve temel pratikleri (Kullanıcı Öyküleri, Yeniden Düzenleme, Test Odaklı Geliştirme, Eşli Programlama).
Scrum: Çerçeveye kısa bir giriş; ayrıntısı ayrı bir derstir.
Çevik Yöntemleri Ölçeklendirme: Büyük projelerde ve kurumsal yapılarda çeviklik.

Çevik Süreçlerin Doğuşu

Çevik Yöntemlerden Önce

Günümüz iş dünyası, küresel, rekabetçi ve hızla değişen bir yapıdadır.
Pazar fırsatlarına anında yanıt vermek ve rekabet avantajı sağlamak kritik öneme sahiptir.
Yazılım, bu dinamik ortamın merkezindedir ve bu nedenle hızlı geliştirme ve teslimat en temel gereksinim haline gelmiştir.

Geleneksel Yöntemlerin Sınırları

İşletmelerin gereksinimleri sürekli değiştiği için, projenin başında tüm gereksinimleri eksiksiz ve kararlı bir şekilde belirlemek neredeyse imkansızdır.
Plan odaklı (plan-driven) süreçler (örn. Şelale Modeli), gereksinimlerin baştan tamamen belirlendiği varsayımına dayanır.
Değişiklikler, tasarımın ve kodun yeniden işlenmesini gerektirir, bu da süreci yavaşlatır ve maliyeti artırır.
Yazılım teslim edildiğinde, orijinal iş ihtiyacı ortadan kalkmış veya radikal bir şekilde değişmiş olabilir.

Not

Bu memnuniyetsizlik, 1980’ler ve 1990’larda yazılım süreçlerindeki genel giderleri (bürokrasi, dokümantasyon vb.) azaltmayı ve değişime daha hızlı yanıt vermeyi amaçlayan Çevik Yöntemlerin doğuşunu hazırlamıştır.

Çevik Yöntemler (Agile Methods)

Çevik Yöntemlerin Temel Felsefesi

Çevik yöntemlerin amacı, yazılım sürecindeki genel giderleri azaltmak (örneğin, dokümantasyonu sınırlandırarak) ve aşırı yeniden çalışma yapmadan değişen gereksinimlere hızla yanıt verebilmektir.

Bu yöntemler:

Tasarımı tek seferde tamamlamaya çalışmak yerine, tasarım kararlarını çalışan yazılım ve geri bildirimle birlikte geliştirir.
Yazılım geliştirmeye yinelemeli (iterative) bir yaklaşım benimser.
Çalışan yazılımı hızlı bir şekilde sunmayı ve bunu değişen gereksinimleri karşılayacak şekilde hızla geliştirmeyi hedefler.

Hızlı Yazılım Geliştirmenin Karakteristikleri

Şartname (specification), tasarım (design) ve uygulama (implementation) süreçleri iç içe geçmiştir.
Sistem, paydaşların düzenli olarak değerlendirebildiği artımlar (increments) halinde geliştirilir; her artımın hemen yayımlanması gerekmez.
Kullanıcı arayüzleri gibi bileşenler, genellikle IDE’ler ve grafik araç setleri kullanılarak hızlıca geliştirilir.

Çevik Manifesto

1990’ların sonunda yazılım projeleri geç teslim, yüksek maliyet ve değişime uyumsuzluk sorunlarıyla boğuşuyordu.
Bu duruma tepki olarak farklı hafif yöntemleri savunan uzmanlar, Şubat 2001’de ABD’nin Utah eyaletindeki Snowbird’de bir araya geldi.
Aralarında Scrum, XP, Crystal, DSDM gibi yaklaşımların öncüleri bulunan 17 kişi, ortak değerleri tanımlayarak “Çevik Manifesto (Agile Manifesto)yu yayımladı.
Amaç: Yazılım geliştirmeyi daha insan merkezli, işbirliğine açık ve değişime uyumlu hale getirmekti.

Toplantı Görseli

Çevik Manifesto (Agile Manifesto)

Önemli

“Bizler daha iyi yazılım geliştirme yollarını uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz. Bu çalışmaların sonucunda:”

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dokümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir planı takip etmekten ziyade değişime karşılık vermeye

“Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.”

Kaynak: http://agilemanifesto.org

Çevik Yöntemlerin İlkeleri

Çevik yöntemler, çalışan yazılımı küçük adımlarla geliştirmeyi ve sık geri bildirim almayı önemser. Artım geliştirmek ile artımı kullanıcıya yayımlamak farklı kararlardır.

Prensip	Açıklama
Müşteri Katılımı	Müşteriler, geliştirme süreci boyunca takımla yakın çalışır. Yeni gereksinimleri sağlar, önceliklendirir ve artımları değerlendirir.
Değişimi Benimseme	Sistem gereksinimlerinin değişimi kaçınılmazdır. Sistem, bu değişiklikleri kabul edecek esnek bir şekilde tasarlanmalıdır.
Küçük Artımlar ve Geri Bildirim	Yazılım küçük artımlarla geliştirilir; uygun olduğunda kullanıcıya sunularak geri bildirim alınır.
Süreçler Değil, İnsanlar	Takımın yetenekleri bilinmeli ve bu yeteneklerden faydalanılmalıdır. Takım üyeleri, detaylı süreçleri takip etmek yerine kendi çalışma yaklaşımlarında özgür bırakılmalıdır.
Sadeliğin Korunması	Hem geliştirilen yazılımda hem de geliştirme sürecinde sadeliğe odaklanılmalıdır. Gereksiz karmaşıklık aktif olarak azaltılmalıdır.

Çevik Yöntemlerin Uygulanabilirliği

Çevik yöntemlerin uygulanmasını kolaylaştıran koşullara iki örnek:
- Bir yazılım şirketinin küçük ya da orta ölçekli ürünler geliştirmesinde
- Organizasyon içerisinde geliştirilen, müşterinin kesin bir biçimde süreçlere katılmayı taahhüt ettiği, az sayıda dış paydaşın yer aldığı uygulamalar

Çevik Yöntemlerin Avantajları ve Sorunları

Avantajları

Hızlı Teslimat: Kısa iterasyonlar ve sürekli teslimat, yazılımın hızlıca kullanıma sunulmasını sağlar.
Kaliteyi Destekleme: Sık geri bildirim ve düzenli test, sorunları erken görmeye yardımcı olur.
Esneklik: Değişen gereksinimlere kolayca adapte olabilir.
Risk Azaltma: İteratif yaklaşım, risklerin erken tespit edilmesini ve yönetilmesini sağlar.
Müşteri Memnuniyeti: Müşterinin sürece dahil olması memnuniyeti artırır.
Geliştirilmiş Ekip Çalışması ve Motivasyon: İletişimi teşvik eder ve geliştiricilerin katılımını artırır.

Karşılaşılan Sorunlar

Müşteri İlgisini Korumak: Müşterilerin süreç boyunca sürekli ve aktif katılımı zor olabilir.
Ekip Uygunluğu: Yoğun katılım ve iletişim, her ekip üyesinin karakterine uygun olmayabilir.
Önceliklendirme Zorlukları: Birden fazla paydaşın olduğu durumlarda değişikliklere öncelik vermek karmaşıklaşabilir.
Sadeliği Korumak: Sadeliği korumak ve teknik borçlanmadan kaçınmak ekstra çaba gerektirir.
Yazılım Bakımı: Minimum dokümantasyon, orijinal geliştirme ekibi dağıldığında bakım sürecini zorlaştırabilir.

Plan Odaklı ve Çevik Geliştirme

Temel Farklılıklar

Plan Odaklı Geliştirme:
- Önceden planlanan ayrı geliştirme aşamalarına (analiz, tasarım, kodlama, test) dayanır.
- Her aşamanın sonunda üretilen formel dokümanlar, bir sonraki aşamanın girdisi olur.
- Yineleme (iteration), genellikle bir faaliyetin içinde gerçekleşir (örn. gereksinimleri netleştirmek için yapılan döngüler).

Çevik Geliştirme:
- Spesifikasyon, tasarım, uygulama ve test faaliyetleri iç içe geçmiştir.
- Yineleme, faaliyetler arasında gerçekleşir. Gereksinimler ve tasarım birlikte geliştirilir.
- İletişim, formal dokümanlar yerine gayriresmi ve sık diyaloglarla sağlanır.

Hangi Yaklaşımı Seçmeli? (1/2)

Çoğu proje, plan odaklı ve çevik süreçlerin unsurlarını bir arada barındırır. Doğru dengeyi bulmak için aşağıdaki teknik, insani ve organizasyonel sorunları değerlendirmek gerekir:

Sistemin Büyüklüğü ve Türü:
- Küçük ve orta ölçekli sistemler için çevik yöntemler idealdir.
- Büyük, karmaşık ve dış düzenlemelere (örn. havacılık, tıp (FAA)) tabi sistemler daha fazla planlama ve dokümantasyon gerektirir.
Beklenen Sistem Ömrü:
- Uzun ömürlü sistemlerde, bakım ekiplerine bilgi aktarmak için tasarım dokümantasyonu daha önemli hale gelir.

Hangi Yaklaşımı Seçmeli? (2/2)

Geliştirme Ekibinin Yetkinliği ve Organizasyonu:
- Çevik yöntemler, yüksek becerili ve kendi kendini organize edebilen ekiplerle daha etkilidir.
- Dağınık (distributed) veya dış kaynak kullanan ekipler arasında iletişim kurmak için tasarım belgeleri gerekebilir.
Kurum Kültürü:
- Geleneksel mühendislik organizasyonları, plan tabanlı kültüre daha yatkındır ve çevik yöntemlere karşı kültürel bir direnç gösterebilirler.

Çevik Geliştirme Teknikleri: Ekstrem Programlama (XP)

En bilinen ve en çok kullanılan çevik yöntemlerden biridir.
Adını, iyi bilinen yazılım geliştirme pratiklerini (örn. yinelemeli geliştirme, test etme) “ekstrem” seviyelere taşımasından alır.
Örneğin:
- Yeni sürümler günde birkaç kez oluşturulabilir.
- Ürün sürümleri her 2 haftada bir müşterilere teslim edilir.
- Tüm testler her derlemede çalıştırılmalı ve yapı yalnızca tüm testler başarılı olursa kabul edilmelidir.

XP Sürüm Döngüsü

XP’nin Temel Pratikleri (1/2)

Pratik	Açıklama
Artımlı Planlama	Gereksinimler “kullanıcı öyküleri” olarak kartlara yazılır. Sürüme dahil edilecek öyküler, öncelik ve zamana göre belirlenir.
Küçük Yayımlar	İş değeri sağlayan en küçük fonksiyonellik öncelikli olarak geliştirilir ve sistem sık aralıklarla yayımlanır.
Sade Tasarım	Sadece mevcut gereksinimleri karşılayacak kadar tasarım yapılır, gelecekteki olası ihtiyaçlar için fazladan tasarım yapılmaz.
Önce Test Geliştirme	Fonksiyonun kodu yazılmadan önce, o fonksiyonu test edecek otomatik birim testleri yazılır.
Yeniden Düzenleme (Refactoring)	Kodun işlevselliğini değiştirmeden, yapısını ve okunabilirliğini iyileştirmek için sürekli olarak yeniden düzenlenir.

XP’nin Temel Pratikleri (2/2)

Pratik	Açıklama
Eşli Programlama (Pair Programming)	Yazılım geliştiriciler, tek bir bilgisayarda çiftler halinde çalışarak birbirlerinin kodunu sürekli denetler ve destek olurlar.
Ortak Sahiplik	Kodun tamamından tüm ekip üyeleri sorumludur. Herkes, sistemin herhangi bir bölümünü değiştirebilir.
Sürekli Bütünleştirme	Bir görev tamamlanır tamamlanmaz sistemle bütünleştirilir ve tüm testler çalıştırılır.
Sürdürülebilir Hız	Fazla mesai, kod kalitesini ve orta vadeli üretkenliği düşürdüğü için kabul edilmez. Haftada 40 saatlik çalışma hedeflenir.
Yerinde Müşteri	Müşteri temsilcisi, geliştirme ekibinin bir parçası olarak tam zamanlı hazır bulunur, soruları yanıtlar ve gereksinimleri netleştirir.

XP Pratiği: Kullanıcı Öyküleri (User Stories)

XP’de gereksinimler, kullanıcının sistemle yaşayabileceği bir senaryoyu anlatan kısa öyküler olarak ifade edilir.
Bu öyküler kartlara yazılır ve planlama için kullanılır. Geliştirme ekibi bu öyküleri daha küçük uygulama görevlerine böler.
Müşteri, önceliklerine göre bir sonraki sürüme eklenecek hikayeleri seçer.

Örnek: ‘İlaç Reçeteleme’ Hikayesi

‘İlaç Reçeteleme’ Hikayesi

“Kate, bir kliniğe giden bir hastaya ilaç yazmak isteyen bir doktordur. Hasta kaydı zaten bilgisayarında görüntülendiğinden, ilaç tedavisi alanına tıklar ve ‘mevcut ilaç’, ‘yeni ilaç’ veya ‘formüler’ seçeneklerinden birini seçebilir.”

Eğer ‘mevcut ilaç’ seçerse, sistem dozu kontrol etmesini ister. Dozu değiştirirse, yeni dozu girer ve reçeteyi onaylar.
Eğer ‘yeni ilaç’ seçerse, ilaç adının ilk birkaç harfini yazar. Sistem olası ilaçları listeler. Kate ilacı seçer, dozu girer ve onaylar.
Sistem her zaman dozun onaylanmış aralıkta olup olmadığını kontrol eder.
Onaydan sonra, Kate ‘Tamam’ veya ‘Değiştir’ seçeneğine tıklar. ‘Tamam’ tıklanırsa reçete veritabanına kaydedilir.
(…)

Öyküden Görev Kartlarına

Bu öykü, aşağıdaki gibi görev kartlarına bölünebilir:

Vaka Analizi: E-Ticaret Sitesi Yorum Özelliği

İlk istek: Kullanıcılar ürün yorumlarını okuyabilsin, yorum yazıp puan verebilsin ve fotoğraf ekleyebilsin.

Bu istek birkaç ayrı kullanıcı öyküsü içerir. Her birini bağımsız olarak değerlendirmek ve önceliklendirmek daha kolaydır.

İsteği Küçük Öykülere Ayırma

Yorumları okuma: Bir ziyaretçi olarak ürün yorumlarını görmek istiyorum; böylece satın almadan önce diğer kullanıcıların deneyimlerini öğrenebilirim.
Yorum ve puan ekleme: Giriş yapmış bir kullanıcı olarak ürüne yorum ve puan eklemek istiyorum; böylece deneyimimi paylaşabilirim.
Fotoğraf ekleme: Yorum yazan bir kullanıcı olarak yorumuma fotoğraf eklemek istiyorum; böylece ürünün durumunu gösterebilirim.

İlk artımda yorumları okumayı, sonraki artımlarda yorum yazma ve fotoğraf eklemeyi ele alabiliriz.

İlk Öykünün Kabul Kriterleri

Ürün sayfasında o ürüne ait yorumlar gösterilir.
Yorumlar en yeniden eskiye sıralanır.
Henüz yorum yoksa kullanıcıya anlaşılır bir mesaj gösterilir.

Bu kriterler ne beklediğimizi söyler; teknik görevler ise nasıl yapacağımızı planlar.

İlk Öykü İçin Olası Görevler

Veri: Yorumları ürün ve oluşturulma tarihiyle ilişkilendirecek veri yapısını hazırla.
Servis: Bir ürüne ait yorumları en yeniden eskiye döndüren uç noktayı geliştir.
Arayüz: Ürün sayfasına yorum listesini ve boş durum mesajını ekle.
Test: Listeleme sırasını ve yorum bulunmayan ürün davranışını doğrula.

Kullanıcı Öykülerinin Temel Sorunları

Tam olmamaları
Yeterli miktarda kullanıcı öyküsü oluşturulup oluşturmadığını yorumlamanın zorluğu
İşine aşina kişilerin anlatımda detayları atlaması

XP Pratiği: Yeniden Düzenleme (Refactoring)

Geleneksel Yaklaşım: Değişimi öngörerek tasarım yap. Bu, gelecekteki değişikliklerin maliyetini düşürür.
XP Yaklaşımı: Değişimi öngörmek genellikle boşa harcanan bir çabadır. Bunun yerine, değişiklikleri kolaylaştırmak için kodu sürekli olarak iyileştir.

Yeniden Düzenleme Nedir?

Kodun dış davranışını (işlevselliğini) değiştirmeden, iç yapısını iyileştirme sürecidir.

Programlama ekibi, acil bir ihtiyaç olmasa bile yazılımda olası iyileştirmeleri arar ve uygular.
Bu, yazılımın anlaşılırlığını artırır ve dokümantasyon ihtiyacını azaltır.
İyi yapılandırılmış kod üzerinde değişiklik yapmak daha kolaydır.

Not

Örnekler: Yinelenen kodu kaldırmak için bir sınıf hiyerarşisi oluşturmak, anlaşılırlığı artırmak için değişken ve metot adlarını yeniden adlandırmak, satır içi kodu bir kütüphane metodu çağrısıyla değiştirmek.

XP Pratiği: Önce Test Geliştirme (Test-First Development)

Test, XP’nin merkezindedir. Her değişiklik yapıldıktan sonra programın tamamı test edilir.
Felsefe: Kodu yazmadan önce o kodu doğrulayacak testleri yaz (TDD).
Bu yaklaşım, uygulanacak gereksinimleri açıklığa kavuşturur ve belirsizlikleri giderir.

Süreç

Uygulanacak küçük bir işlevsellik belirlenir.
Bu işlevselliğin başarısız olacağı bir otomatik test yazılır (çünkü kod henüz yok) (RED).
Testin başarılı olmasını sağlayacak en basit kod yazılır (GREEN).
Kod, kalite standartlarını karşılayacak şekilde yeniden düzenlenir (refactor edilir) (REFACTOR).
Yeni işlevsellik eklendiğinde, tüm eski ve yeni testler otomatik olarak çalıştırılır. Bu, yeni eklenen kodun mevcut sistemi bozmamasını (regresyon) sağlar.

Önemli

Test otomasyonu bu sürecin temelidir. Junit (Java), PyTest (Python) gibi çerçeveler, yürütülebilir testler yazmayı ve çalıştırmayı kolaylaştırır.

Müşteri ve Test Süreci

Müşterinin test sürecindeki rolü, sistemin bir sonraki sürümünde uygulanacak hikayeler için kabul testleri geliştirmeye yardımcı olmaktır.
Ekibin bir parçası olan müşteri, geliştirme ilerledikçe testler yazar. Bu nedenle, tüm yeni kodlar, müşterinin ihtiyaç duyduğu şey olduğundan emin olmak için doğrulanır.
Müşteri rolünü benimseyen kişilerin sınırlı zamanı vardır. Gereksinimleri sağlamanın yeterli bir katkı olduğunu düşünebilirler ve bu nedenle test sürecine dahil olma konusunda isteksiz olabilirler.

Test Sürecinin Zorlukları

Programcılar programlamayı teste tercih ederler ve bazen test yazarken kestirme yollar kullanırlar. Örneğin, oluşabilecek tüm olası durumları kontrol etmeyen eksik testler yazabilirler
Bazı testleri aşamalı olarak yazmak çok zor olabilir. Örneğin, karmaşık bir kullanıcı arayüzünde, ekranlar arasında ‘görüntüleme mantığını’ ve iş akışını uygulayan kod için birim testleri yazmak genellikle zordur.
Testlerin yeterli olup olmadığına karar vermek zordur.

XP Pratiği: Eşli Programlama (Pair Programming)

İki programcı, tek bir iş istasyonunda (bilgisayarda) birlikte çalışır.
Genellikle bir kişi (“sürücü”) klavyede kodu yazarken, diğeri (“gözlemci” veya “navigator”) stratejiyi düşünür, olası hataları arar ve anlık geri bildirimde bulunur.
Roller sık sık değiştirilir. Çiftler dinamik olarak oluşturulur, böylece tüm ekip üyeleri birbiriyle çalışma fırsatı bulur.

Eşli Programlamanın Avantajları

Daha İyi Kod Kalitesi: Her kod satırı en az iki kişi tarafından incelendiği için gayriresmi bir kod gözden geçirme (code review) görevi görür ve hatalar anında bulunur.
Daha İyi Bilgi Paylaşımı: Bilgi ve deneyim ekibe yayılır. Bu, bir ekip üyesi ayrıldığında projeye yönelik riski azaltır.
Kolektif Sahipliği Destekler: Kod, bireylerin değil, ekibin malı olur.
Yeniden Düzenlemeyi Teşvik Eder: Geliştiriciler, bir başkasıyla çalışırken kodu iyileştirmek için daha motive olurlar.

Not

Araştırmalar, eşli programlamanın verimliliğinin, tek başına çalışan iki programcının toplam verimliliğine yakın olduğunu göstermektedir. Bunun nedeni, daha az hata yapılması, daha az yeniden işleme ve daha iyi tasarım kararlarıdır.

Eşli Programlamanın Dezavantajları

Daha yüksek maliyet: Sürekli iki geliştiricinin aynı probleme bakması gereksinimi
Uyum sorunları: Geliştiricilerin bir arada çalışmasının ortaya çıkarabileceği uyum problemleri
Eğitim ihtiyacı: Ekibin bu konuda bilgili ve tecrübeli olması
Zaman kaybı: Ayrı iki işi ortaya koyabilecek geliştiricilerin tek bir problem üzerinden ilerlemesi

Scrum

Scrum, çevik yaklaşımın en yaygın kullanılan çerçevesidir. Sprint’ler, sorumluluklar, etkinlikler ve eserler tanımlar; kodlama ve test tekniklerini zorunlu kılmadığı için XP pratikleriyle birlikte kullanılabilir.

Scrum’ı ayrıntılı olarak ayrı bir derste, Scrum dersinde işliyoruz.

Çevik Yöntemleri Ölçeklendirme

Çevik yöntemler, küçük ve aynı yerde bulunan ekipler için geliştirilmiştir. Ancak günümüzde büyük sistemler ve büyük kurumsal yapılar için de kullanılmaktadır. Bu, “ölçeklendirme” sorununu ortaya çıkarır.

Büyük Sistem Geliştirmenin Zorlukları

“Sistemlerin Sistemi” Olmaları: Büyük sistemler, genellikle farklı ekipler tarafından geliştirilen, birbiriyle iletişim halindeki birçok alt sistemden oluşur.
“Kahverengi Alan” (Brownfield) Projeleri: Genellikle mevcut sistemlerle entegre olmaları gerekir, bu da esnekliği sınırlar.
Çok Sayıda Paydaş: Farklı ve bazen çelişkili beklentilere sahip çok sayıda paydaşı sürece dahil etmek neredeyse imkansızdır.
Dış Düzenlemeler: Geliştirme süreçlerini sınırlayan dış kurallar (regülasyonlar) olabilir.
Dağınık Ekipler: Ekipler genellikle farklı coğrafi konumlarda ve saat dilimlerinde çalışır.

Ölçeklendirme Stratejileri

Büyük sistemlere çevik yöntemleri uygularken, “saf” çeviklikten ödün vermek ve bazı plan odaklı pratikleri entegre etmek gerekir:

Daha Fazla Ön Tasarım: Sistemin genel mimarisini belirlemek için daha fazla ön analiz ve tasarım gereklidir. Sadece koda odaklanmak yeterli değildir.
Ekipler Arası İletişim: Ekipler arası iletişim mekanizmaları (örn. düzenli video konferanslar, ortak dokümantasyon) tasarlanmalı ve kullanılmalıdır.
Sürekli Bütünleştirme Zorlukları: Tüm sistemi her değişiklikte derlemek pratik olmayabilir. Ancak, sık sistem kurulumları ve düzenli sürüm entegrasyonları kritik öneme sahiptir.

Kurumsal Direnç: Büyük şirketlerdeki yerleşik kültür, bürokrasi ve standartlar, çevik yöntemlerin benimsenmesine karşı bir direnç oluşturabilir.
Çözüm: SAFe, LeSS gibi ölçeklendirme çerçeveleri bu sorunlara yapısal çözümler sunar.

Özet ve Anahtar Noktalar

Çevik yöntemler, küçük artımlarla çalışan yazılım geliştirmeyi, geri bildirim almayı ve değişime uyum sağlamayı önemser.
Plan odaklı veya çevik yaklaşım kararı; yazılımın türüne, ekibin yeteneklerine ve kurumun koşullarına bağlıdır. Bazı projelerde iki yaklaşımın pratikleri birlikte kullanılabilir.
Ekstrem Programlama (XP), kullanıcı öyküleri, sürekli yazılım iyileştirmesi (refactoring) ve müşteri katılımı gibi bir dizi iyi programlama uygulamasını entegre eden iyi bilinen bir çevik yöntemdir.

Test Odaklı Geliştirme, bir program özelliği oluşturulmadan önce otomatik testlerin geliştirilmesini içeren güçlü bir XP pratiğidir.
Scrum, karmaşık ürün çalışmalarını ardışık Sprint’lerle düzenleyen hafif bir çerçevedir; Scrum Takımı her Sprint’te kullanılabilir bir artım üretir (ayrıntısı Scrum dersinde).
Büyük sistemler için çevik yöntemleri ölçeklendirmek zordur. Bu sistemler, daha fazla ön tasarıma, dokümantasyona ve ekipler arası koordinasyona ihtiyaç duyar.