Agile ve Scrum: Çevik Yazılım Geliştirme Metodolojileri

Agile Manifesto ve Temel Prensipleri

Çevik (Agile) yazılım geliştirme, 2001 yılında 17 yazılım uzmanının bir araya gelerek imzaladığı Agile Manifesto ile resmi olarak doğmuştur. Manifesto, geleneksel şelale (waterfall) modelinin ağır süreçlerine bir alternatif olarak ortaya çıkmış ve yazılım dünyasını temelden değiştirmiştir.

Agile Manifesto dört temel değer üzerine kuruludur:

• Bireyler ve etkileşimler, süreçler ve araçlardan önce gelir
• Çalışan yazılım, kapsamlı dokümantasyondan önce gelir
• Müşteri iş birliği, sözleşme pazarlığından önce gelir
• Değişime yanıt vermek, bir planı takip etmekten önce gelir

Bu değerler, sağ taraftaki maddelerin değersiz olduğu anlamına gelmez; sol taraftakilerin daha değerli görüldüğünü ifade eder.

Agile'ın 12 Prensibi

Manifesto'nun arkasında, çevik geliştirmeyi yönlendiren 12 temel prensip yer alır:

1. Değerli yazılımın erken ve sürekli teslimiyle müşteri memnuniyetini sağlamak
2. Değişen gereksinimleri geliştirme sürecinin geç aşamalarında bile kabul etmek
3. Çalışan yazılımı sık aralıklarla teslim etmek (haftalar veya aylar)
4. İş insanları ve geliştiriciler proje boyunca günlük olarak birlikte çalışmalıdır
5. Projeleri motive olmuş bireyler etrafında inşa etmek
6. En verimli iletişim yöntemi yüz yüze konuşmadır
7. Çalışan yazılım, ilerlemenin birincil ölçüsüdür
8. Çevik süreçler sürdürülebilir geliştirmeyi destekler
9. Teknik mükemmelliğe ve iyi tasarıma sürekli özen göstermek
10. Sadelik — yapılmayan işin miktarını en üst düzeye çıkarma sanatı — esastır
11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden çıkar
12. Ekip, düzenli aralıklarla nasıl daha etkili olabileceğini değerlendirir ve davranışlarını buna göre ayarlar

Scrum Framework

Scrum, Agile metodolojilerinin en yaygın kullanılanıdır. State of Agile Report'a göre Agile uygulayan organizasyonların %87'si Scrum veya Scrum tabanlı bir framework kullanmaktadır. Scrum, karmaşık ürün geliştirme süreçlerini yönetmek için hafif, anlaşılması kolay ancak uygulanması zor bir çerçeve sunar.

Scrum Rolleri

Product Owner (Ürün Sahibi)

Product Owner, ürün değerini en üst düzeye çıkarmaktan sorumlu tek kişidir. Product Backlog'u yönetir, kullanıcı ihtiyaçlarını anlar ve iş önceliklerini belirler. Product Owner'ın temel sorumlulukları:

• Product Backlog item'larını oluşturma ve net şekilde ifade etme
• Backlog item'larını değer ve önceliğe göre sıralama
• Geliştirme ekibinin backlog'u anladığından emin olma
• Paydaş beklentilerini yönetme
• Sprint sonunda yapılan işi kabul etme veya reddetme

Scrum Master

Scrum Master, Scrum framework'ünün doğru uygulanmasından sorumlu servant-leader'dır. Ekibin önündeki engelleri kaldırır, Scrum değerlerini ve pratiklerini korumasını sağlar ve sürekli iyileştirmeyi teşvik eder.

Scrum Master bir yönetici veya proje müdürü değildir. Ekibe komut vermek yerine, kendi kendini organize etmesine yardımcı olur. Kolaylaştırıcı, koç ve engel kaldırıcı rollerini üstlenir.

Development Team (Geliştirme Ekibi)

Geliştirme ekibi, her Sprint'te potansiyel olarak dağıtılabilir bir ürün artışı (increment) oluşturmaktan sorumlu profesyonellerden oluşur. Ekip kendi kendini organize eder; işin nasıl yapılacağına ekip karar verir.

İdeal Scrum ekip büyüklüğü 3-9 kişidir. Ekip çapraz fonksiyoneldir; yani Sprint hedefini gerçekleştirmek için gerekli tüm yetkinliklere sahiptir (geliştirme, test, tasarım, veritabanı vb.).

Scrum Seremonileri (Events)

Sprint

Sprint, Scrum'ın kalbidir. Genellikle 1-4 hafta süren zaman kutulu (time-boxed) bir iterasyondur. Her Sprint sonunda potansiyel olarak kullanılabilir bir ürün artışı üretilir. Sprint süresi sabittir ve proje boyunca değiştirilmez.

Sprint Planning (Sprint Planlama)

Her Sprint'in başında yapılan Sprint Planning toplantısında, Sprint'te ne yapılacağı ve nasıl yapılacağı planlanır. Product Owner, en öncelikli backlog item'larını sunar; geliştirme ekibi bu item'ları değerlendirir ve Sprint Backlog'u oluşturur.

Sprint Planning'in iki bölümü:

1. Ne yapılacak? Product Owner backlog'dan item'ları sunar, ekip Sprint hedefini belirler
2. Nasıl yapılacak? Ekip, seçilen item'ları alt görevlere böler ve uygulama planı oluşturur

Daily Scrum (Günlük Toplantı)

Her iş günü aynı saatte, aynı yerde yapılan maksimum 15 dakikalık stand-up toplantıdır. Her ekip üyesi üç soruyu yanıtlar:

• Dün Sprint hedefine ulaşmak için ne yaptım?
• Bugün Sprint hedefine ulaşmak için ne yapacağım?
• Sprint hedefine ulaşmamı engelleyen bir şey var mı?

Daily Scrum bir durum raporu toplantısı değildir. Ekibin kendi arasında senkronize olması ve engelleri hızla tespit etmesi için tasarlanmıştır.

Sprint Review

Sprint sonunda yapılan Sprint Review'da, ekip Sprint boyunca tamamladığı işi paydaşlara gösterir. Demo formatında yapılan bu toplantıda geri bildirim alınır ve Product Backlog güncellenir.

Sprint Review bir sunum değil, bir iş birliği toplantısıdır. Paydaşların aktif katılımı ve geri bildirimi beklenir.

Sprint Retrospective

Her Sprint'in sonunda yapılan Retrospective, ekibin kendi sürecini değerlendirdiği ve iyileştirme fırsatlarını belirlediği toplantıdır. "Neyi iyi yaptık?", "Neyi geliştirebiliriz?" ve "Bir sonraki Sprint'te ne deneyeceğiz?" soruları etrafında yapılandırılır.

Retrospective formatları:

• Start-Stop-Continue: Başlamak, durdurmak ve devam etmek istediğimiz pratikler
• Mad-Sad-Glad: Kızdıran, üzen ve sevindiren konular
• 4L's: Liked, Learned, Lacked, Longed for
• Sailboat: Rüzgar (iticiler), çapa (engelleyiciler), kaya (riskler)

Scrum Eserleri (Artifacts)

Product Backlog

Product Backlog, ürün için yapılması gereken her şeyin önceliklendirilmiş listesidir. Product Owner tarafından yönetilir ve sürekli olarak güncellenir (refinement). Her item, bir değer taşımalı ve net kabul kriterleri içermelidir.

Sprint Backlog

Sprint Backlog, Sprint için seçilen Product Backlog item'ları ve bunları tamamlamak için oluşturulan planın birleşimidir. Sprint boyunca geliştirme ekibi tarafından güncellenir.

Increment (Artış)

Increment, Sprint boyunca tamamlanan tüm Product Backlog item'larının ve önceki Sprint'lerin increment'larının toplamıdır. Her increment, "Done" tanımına uygun ve kullanılabilir durumda olmalıdır.

Kanban Metodu

Kanban, Toyota Üretim Sistemi'nden esinlenen çevik bir iş yönetimi metodudur. Scrum'dan farklı olarak sabit iterasyonları yoktur; iş sürekli akış prensibine göre yönetilir.

Kanban'ın Temel Prensipleri

1. İşi görselleştirin: Kanban board ile tüm iş akışını görsel olarak temsil edin
2. WIP (Work in Progress) limitlerini belirleyin: Eş zamanlı yapılan iş miktarını sınırlayın
3. Akışı yönetin: İş akışını optimize edin, darboğazları tespit edin
4. Süreç politikalarını açık hale getirin: Her aşamanın giriş ve çıkış kurallarını tanımlayın
5. Geri bildirim döngüleri uygulayın: Düzenli gözden geçirme toplantıları yapın
6. İş birliği ile geliştirin, deneyler ile evrimleşin: Sürekli ve kademeli iyileştirme

Kanban Board Tasarımı

Temel bir Kanban board'u şu sütunlardan oluşur:

Sütun	WIP Limit	Açıklama
Backlog	-	Yapılacak tüm işler
Ready	5	Başlamaya hazır, önceliklendirilmiş işler
In Progress	3	Aktif olarak üzerinde çalışılan işler
Review	2	Kod inceleme veya test aşamasında
Done	-	Tamamlanan işler

Scrum vs Kanban

Özellik	Scrum	Kanban
İterasyon	Sabit Sprint süreleri	Sürekli akış
Roller	PO, SM, Dev Team	Zorunlu rol yok
Planlama	Sprint bazlı	Sürekli, ihtiyaca göre
WIP Limiti	Sprint kapasitesi	Sütun bazlı WIP limit
Değişiklik	Sprint içinde değişiklik önerilmez	Her an değişiklik yapılabilir
Uygun Durum	Ürün geliştirme projeleri	Destek, bakım, operasyon ekipleri

User Story Yazımı ve Tahminleme

User Story Formatı

User story, kullanıcı perspektifinden yazılan kısa gereksinim ifadesidir. Standart format şu şekildedir:

Bir [kullanıcı rolü] olarak,
[bir hedefe ulaşmak] istiyorum,
böylece [bir fayda elde edeyim].

Örnek:
Bir müşteri olarak,
siparişlerimin durumunu takip etmek istiyorum,
böylece kargomun ne zaman geleceğini bileyim.

INVEST Kriterleri

İyi bir user story, INVEST kriterlerini karşılamalıdır:

• I - Independent (Bağımsız): Diğer story'lerden bağımsız olarak geliştirilebilir
• N - Negotiable (Pazarlık Edilebilir): Detaylar tartışmaya açıktır
• V - Valuable (Değerli): Son kullanıcıya veya müşteriye değer sağlar
• E - Estimable (Tahmin Edilebilir): Ekip tarafından büyüklüğü tahmin edilebilir
• S - Small (Küçük): Tek Sprint'te tamamlanabilecek kadar küçük
• T - Testable (Test Edilebilir): Kabul kriterleri net ve test edilebilir

Tahminleme Teknikleri

Story Points

Story point, bir user story'nin karmaşıklığını, riski ve eforunu birleştiren göreceli bir ölçü birimidir. Fibonacci dizisi (1, 2, 3, 5, 8, 13, 21) yaygın olarak kullanılır. Bir referans story belirlenerek diğer story'ler buna göre puanlanır.

Planning Poker

Planning Poker, ekip üyelerinin aynı anda bağımsız tahminlerini açıkladığı bir tahminleme tekniğidir. Büyük farklılıklar tartışılarak uzlaşıya varılır. Bu yöntem, ankraj etkisini (anchoring bias) önler ve ekibin kolektif bilgisinden faydalanır.

T-Shirt Sizing

XS, S, M, L, XL gibi göreceli büyüklükler kullanılarak yapılan hızlı tahminleme yöntemidir. Özellikle backlog refinement oturumlarında ve yüksek seviye tahminleme için uygundur.

Velocity ve Burndown Chart

Velocity (Hız)

Velocity, ekibin bir Sprint'te tamamladığı toplam story point miktarıdır. Son 3-5 Sprint'in ortalaması alınarak gelecek Sprint'lerin kapasitesi tahmin edilir. Velocity, ekip karşılaştırması için değil, ekibin kendi planlaması için kullanılmalıdır.

Burndown Chart

Sprint Burndown Chart, Sprint boyunca kalan iş miktarını gösteren grafiktir. İdeal çizgi ile gerçek ilerleme karşılaştırılarak Sprint'in zamanında tamamlanıp tamamlanamayacağı görselleştirilir.

Diğer Çevik Metrikler

Metrik	Açıklama	Kullanım Amacı
Velocity	Sprint başına tamamlanan story point	Kapasite planlaması
Lead Time	İsteğin alınmasından teslime kadar geçen süre	Teslimat süresi iyileştirme
Cycle Time	İşe başlamadan tamamlanana kadar geçen süre	Süreç verimliliği
Throughput	Belirli sürede tamamlanan iş sayısı	Üretkenlik ölçümü
Cumulative Flow	Her aşamadaki iş miktarının zaman içindeki değişimi	Darboğaz tespiti
Sprint Burndown	Sprint içindeki kalan iş miktarı	Sprint ilerleme takibi

Agile'ı Ölçeklendirme

Büyük organizasyonlarda birden fazla ekibin koordineli çalışması gerektiğinde, çevik pratiklerin ölçeklendirilmesi ihtiyacı doğar.

SAFe (Scaled Agile Framework)

SAFe, en yaygın kullanılan ölçeklendirme çerçevesidir. Team, Program, Large Solution ve Portfolio olmak üzere dört seviyede çevik pratikler sunar. Agile Release Train (ART), Program Increment (PI) Planning ve System Demo gibi SAFe'e özgü kavramlar içerir.

LeSS (Large-Scale Scrum)

LeSS, Scrum'ı en az değişiklikle ölçeklendirmeyi hedefleyen minimalist bir yaklaşımdır. Birden fazla ekip tek bir Product Owner ve tek bir Product Backlog ile çalışır. Tek fark, bazı seremonilerin (Sprint Planning, Sprint Review) birden fazla ekiple yapılmasıdır.

Spotify Model

Spotify'ın kendi organizasyonunda geliştirdiği model, Squad, Tribe, Chapter ve Guild kavramlarına dayanır. Resmi bir framework olmamakla birlikte, birçok organizasyon bu modelden ilham almaktadır.

Sık Karşılaşılan Anti-Pattern'lar

Agile ve Scrum uygulamalarında sıkça karşılaşılan anti-pattern'lar ve çözümleri:

• Zombie Scrum: Tüm seremoniler yapılıyor ancak sürekli iyileştirme ve müşteri odağı yok. Çözüm: Sprint Review'a gerçek kullanıcıları davet edin, geri bildirimi aksiyona dönüştürün
• Sprint 0 Tuzağı: Aylarca süren "hazırlık Sprint'leri" ile çalışan yazılım üretmeden zaman kaybetmek. Çözüm: İlk Sprint'ten itibaren değer üreten, küçük de olsa çalışan yazılım teslim edin
• Scrum but...: "Scrum yapıyoruz ama Retrospective yapmıyoruz" gibi seçici uygulama. Çözüm: Scrum'ı bütünüyle uygulayın veya bilinçli olarak Kanban gibi alternatif bir yöntem tercih edin
• Estimation Theater: Story point tahminlerinin performans ölçütü olarak kullanılması. Çözüm: Velocity'yi baskı aracı değil, planlama aracı olarak kullanın
• Daily Scrum'ın Durum Toplantısına Dönmesi: Ekip üyelerinin birbirine değil yöneticiye rapor vermesi. Çözüm: Scrum Master, toplantıyı kolaylaştırarak ekip odaklı tutmalı
• Backlog Grooming Problemi: Product Backlog'un şişmesi ve yönetilemez hale gelmesi. Çözüm: Düzenli backlog refinement oturumları ile eski ve düşük öncelikli item'ları temizleyin

Agile vs Waterfall

Çevik ve şelale yaklaşımları arasındaki temel farklar:

Boyut	Waterfall	Agile
Yaklaşım	Sıralı, aşamalı	İteratif, artımlı
Gereksinimler	Başta sabitlenir	Sürekli evrilir
Teslimat	Proje sonunda tek seferde	Her Sprint sonunda
Değişiklik	Maliyetli ve zor	Beklenen ve desteklenen
Risk	Geç aşamada ortaya çıkar	Erken tespit edilir
Müşteri Katılımı	Başlangıç ve sonuç	Sürekli
Dokümantasyon	Kapsamlı	Yeterli düzeyde
Uygun Durum	Sabit gereksinimler, düzenleyici projeler	Değişken gereksinimler, yenilikçi projeler

Çevik Proje Yönetimi Araçları

Jira

Atlassian'ın Jira'sı, çevik proje yönetiminde dünya genelinde en yaygın kullanılan araçtır. Scrum board, Kanban board, backlog yönetimi, Sprint planlama, raporlama ve entegrasyon yetenekleri sunar.

Jira'nın güçlü yönleri:

• Esnek iş akışı özelleştirmesi
• JQL (Jira Query Language) ile güçlü sorgulama
• Confluence, Bitbucket ve diğer Atlassian ürünleriyle entegrasyon
• 3.000'den fazla marketplace eklentisi
• Advanced Roadmaps ile portföy yönetimi

Azure DevOps

Microsoft Azure DevOps (eski adıyla TFS/VSTS), özellikle .NET ekosisteminde çalışan ekipler için kapsamlı bir çevik proje yönetimi ve DevOps platformudur. Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans ve Azure Artifacts bileşenlerinden oluşur.

Azure DevOps'un avantajları arasında Visual Studio ile doğal entegrasyon, güçlü CI/CD pipeline'ları ve Microsoft ekosistemiyle uyum sayılabilir.

Diğer Araçlar

• Trello: Basit ve görsel Kanban board aracı, küçük ekipler için ideal
• Monday.com: Esnek proje yönetimi platformu, çevik şablonlarla
• Linear: Modern, hızlı ve developer-friendly issue tracker
• Asana: Görev ve proje yönetimi ile Agile desteği
• Shortcut (eski Clubhouse): Yazılım ekipleri için tasarlanmış çevik araç
• ClickUp: Çok yönlü proje yönetimi ve Agile desteği

Sonuç ve Öneriler

Agile ve Scrum, doğru uygulandığında yazılım geliştirme süreçlerini dönüştüren güçlü metodolojilerdir. Ancak çevik dönüşüm, sadece araç ve süreç değişikliği değil, aynı zamanda bir kültür değişimidir.

Çevik yolculuğunuza başlarken şu tavsiyeleri dikkate alın:

• Scrum Guide'ı okuyarak temel kavramları öğrenin; çerçeveyi tam olarak anlayın
• Küçük bir pilot ekiple başlayın ve deneyim kazanın
• Retrospective'i asla atlamayın; sürekli iyileştirme Agile'ın kalbidir
• Araçlardan önce pratiklere odaklanın; Jira kullanmak sizi çevik yapmaz
• Üst yönetim desteğini sağlayın; çevik dönüşüm organizasyon genelinde etki yaratır
• Mükemmeliyetçilikten kaçının; çevik olmayı öğrenmek de çevik bir süreçtir

Ekolsoft olarak, yazılım projelerimizde Agile ve Scrum metodolojilerini aktif olarak kullanmaktayız. Ekibinizin çevik dönüşümünde koçluk, eğitim ve danışmanlık hizmetleri sunuyoruz. Çevik yolculuğunuzda size eşlik etmek için bizimle iletişime geçin.