Scrum ve Agile: Solo Developer ve Küçük Takımlar İçin Pratik Uyarlama
Agile ve Scrum denince akla hep 8-10 kişilik takımlar, sprint planning toplantıları ve duvarları dolu sticky note'lar geliyor. Peki ya tek başına çalışan bir developer veya 2-3 kişilik küçük bir ekip için bu metodolojiler gerçekten işe yarar mı? Yıllarca hem büyük ekiplerde hem de solo projelerimde Scrum'ı uyarlamaya çalıştım. Bu yazıda, gereksiz seremonileri budayıp faydalı disiplinleri korumanın yollarını paylaşacağım.
Agile Manifesto: Özünü Anlamak
2001'de yayınlanan Agile Manifesto aslında 4 temel değer üzerine kurulu:
- Bireyler ve etkileşimler > Süreçler ve araçlar
- Çalışan yazılım > Kapsamlı dokümantasyon
- Müşteri işbirliği > Sözleşme pazarlığı
- Değişime yanıt verme > Plana bağlı kalma
Bu değerlerin hiçbiri "büyük takım gerektirir" demiyor. Solo developer olarak da bu prensipleri benimseyebilirsiniz. Aslında tek başınıza çalışırken "değişime yanıt verme" çok daha kolay -- kimseyi ikna etmeniz gerekmiyor.
Scrum Framework: Temel Bileşenler
Scrum'ın temel yapı taşlarını kısaca özetleyelim:
Sprint: 1-4 haftalık sabit süreli çalışma dönemleri. Her sprint sonunda çalışan bir ürün artışı (increment) olmalı.
Sprint Planning: Sprint başında yapılacak işlerin belirlenmesi.
Daily Standup: Her gün 15 dakikalık durum toplantısı. Üç soru: Dün ne yaptım? Bugün ne yapacağım? Engelim var mı?
Sprint Review: Sprint sonunda paydaşlara demo.
Sprint Retrospective: Sprint sonunda "ne iyi gitti, ne kötü gitti, ne değiştirelim" analizi.
Solo Developer'a Uyarlama
İşte gerçek dünyada bu framework'ü tek kişilik projelere nasıl uyarladığımı anlatayım.
1. Sprint Süresi: 1 Hafta
Büyük takımlarda 2 haftalık sprint yaygın ama solo çalışırken 1 haftalık sprint çok daha etkili. Kısa döngüler motivasyonu yüksek tutuyor ve "bu hafta ne bitirdim" sorusuna net cevap verebiliyorsunuz.
## Sprint 12 (10-16 Şubat 2026)
### Sprint Goal
Blog modülünün SEO özelliklerini tamamla
### Backlog
- [x] Meta title/description alanları ekle
- [x] Sitemap.xml generator yaz
- [x] Open Graph tag desteği
- [ ] Structured data (JSON-LD) --> Sonraki sprint'e taşındı
2. Daily Standup: Günlük Not
Kimseyle toplantı yapmıyorsunuz ama her gün 2 dakika ayırıp şu notu yazın:
## 12 Şubat 2026
- Dün: Sitemap generator'ın temel yapısını kurdum
- Bugün: Blog post'ları için XML çıktısını tamamlayacağım
- Engel: Cache invalidation stratejisine karar vermem lazım
Bu notları bir CHANGELOG.md veya günlük dosyasında tutuyorum. Hafta sonunda retrospective yaparken bu notlar çok işe yarıyor.
3. Retrospective: Haftalık 15 Dakika
Her cuma günü sprint bittiğinde kendime şu soruları soruyorum:
- Bu hafta tahminimdeki doğruluk oranı neydi?
- Hangi task beklenenden uzun sürdü ve neden?
- Hangi tool veya alışkanlık beni yavaşlattı?
- Gelecek hafta neyi farklı yapacağım?
Bu disiplini korumak zor ama en çok faydası dokunan kısım bu. Kendi kalıplarınızı ve darboğazlarınızı fark etmeye başlıyorsunuz.
Kanban Board: Görselleştirme Şart
Scrum kullanın ya da kullanmayın, bir Kanban board şart. İşleri görselleştirmek, kafanızdaki "yapılacaklar listesi" kaosunu ortadan kaldırıyor.
GitHub Projects
Zaten GitHub kullanıyorsanız en doğal seçim. Issue'ları sürükle-bırak ile yönetebiliyorsunuz:
| Backlog | In Progress | Review | Done |
|-------------|-------------|-----------|------------|
| JSON-LD | OG Tags | | Sitemap |
| RSS Feed | | | Meta Tags |
| Schema.org | | | |
GitHub Projects'in güzel yanı issue'larla doğrudan entegre olması. Her task bir issue, her issue bir branch, her branch bir PR. Düzgün bir workflow.
Linear
Son zamanlarda Linear'a bayıldım. GitHub Projects'e göre çok daha hızlı, klavye kısayolları mükemmel. Solo developer'lar için free planı yeterli. Cycle kavramı sprint ile birebir örtüşüyor.
Trello
Basitlik istiyorsanız Trello hala iyi bir seçenek. Ama büyük projelerde yetersiz kalabiliyor. Kişisel projeler ve freelance işler için gayet yeterli.
Estimation: Story Points vs Time-Based
Bu tartışma hiç bitmiyor. Büyük ekiplerde story point mantıklı çünkü herkesin hızı farklı ve göreceli tahmin daha isabetli. Ama solo developer olarak benim yaklaşımım şu:
Küçük projeler: Saat bazlı tahmin. "Bu task 2 saat" demek, tek kişiyken yeterli.
Büyük projeler: T-shirt sizing. XS (30 dk), S (1-2 saat), M (yarım gün), L (1 gün), XL (sprint'e sığmaz, böl).
## Sprint Backlog
| Task | Size | Actual |
|------------------------|------|--------|
| Sitemap generator | M | M |
| OG meta tags | S | S |
| JSON-LD structured | L | XL | <-- Tahmini tutmadı
| RSS feed | S | S |
XL çıkan task'ları mutlaka bölün. "JSON-LD structured data" yerine "Blog post JSON-LD", "Breadcrumb JSON-LD", "Organization JSON-LD" gibi parçalayın.
Definition of Done
Bu kavram solo developer'lar için de kritik. "Bitti" ne demek? Herkesin kendi Definition of Done listesi olmalı. Benimki şöyle:
## Definition of Done
- [ ] Kod yazıldı ve çalışıyor
- [ ] En az temel validasyon var
- [ ] Migration varsa geri alınabiliyor (down metodu)
- [ ] Route'lar test edildi (en azından manuel)
- [ ] Commit mesajı anlamlı
- [ ] Gerekiyorsa CLAUDE.md güncellendi
Bunu bir checklist olarak sprint board'unuza ekleyin. Her task'ı "Done" sütununa taşımadan önce bu listeyi kontrol edin. Zamanla bu refleks haline geliyor.
Gereksiz Seremoni vs Faydalı Disiplin
Solo developer olarak Scrum'ın her kuralını uygulamaya çalışmak saçmalık. Ama hiçbirini uygulamamak da kaos demek. İşte benim "al/bırak" listem:
Koru (Faydalı Disiplin)
- Sprint döngüsü: İşleri zaman kutusuna koymak odak sağlıyor
- Backlog grooming: Haftalık 15 dakika backlog'u temizlemek
- Retrospective: Kendi kendini değerlendirme altın değerinde
- Definition of Done: "Bitti" standardı olmazsa yarım işler birikir
- Kanban board: Görselleştirme her zaman faydalı
Bırak (Gereksiz Seremoni)
- Daily standup toplantısı: Tek kişiyken toplantı absürt. Günlük not yeterli
- Story point estimation: T-shirt sizing veya saat daha pratik
- Sprint review toplantısı: Demo'yu kendinize yapın, 5 dakika yeter
- Velocity tracking: 1-2 sprint sonra doğal olarak hızınızı öğreniyorsunuz
- Burndown chart: Solo projede gereksiz overhead
Pratik: GitHub ile Haftalık Sprint
Projelerimde kullandığım basit workflow:
# Pazartesi: Sprint planning
gh issue create --title "Sprint 12 Goal: SEO özellikleri" --label "sprint-12"
gh issue create --title "Sitemap generator" --label "sprint-12" --assignee "@me"
gh issue create --title "OG meta tags" --label "sprint-12" --assignee "@me"
# Her gün: Branch aç, çalış, PR aç
git checkout -b feature/sitemap-generator
# ... çalış ...
git push -u origin feature/sitemap-generator
gh pr create --title "Sitemap generator" --body "Closes #45"
# Cuma: Sprint review + retrospective
gh issue list --label "sprint-12" --state all
GitHub Projects'te bir board oluşturun, label'larla sprint'leri ayırın. Basit ama etkili.
Sonuç
Scrum ve Agile büyük takımlar için tasarlandı ama özündeki fikirler evrensel: kısa döngülerle çalış, düzenli geri bildirim al, adapte ol. Solo developer olarak tüm seremonileri uygulamak yerine, size gerçekten fayda sağlayan disiplinleri seçin ve onları tutarlı şekilde uygulayın.
Benim deneyimimde en kritik üç şey: haftalık sprint döngüsü, bir Kanban board ve cuma günü 15 dakikalık retrospective. Bu üçünü yaparsanız, geri kalanı zamanla oturur. Önemli olan mükemmel bir sistem kurmak değil, tutarlı bir ritim yakalamak.
Unutmayın, metodoloji bir araç. Araç sizi yönetmeye başladığında bir şeyler yanlış gidiyor demektir.