Giriş

Bu rehber, küçük ekipler için uygulanabilir ve pratik adımlarla Yazılım Geliştirme Süreçlerini açıklar. İçerik Scrum çerçevesine dayalıdır ve sprint planlama, günlük iş akışı, sürüm yönetimi ve performans ölçümleri için somut öneriler içerir. Scrum hakkında temel bilgiler için resmi olmayan ve öğretici kaynaklara bakabilirsiniz (örnek: Agile ve Scrum - Invictus Wiki).

Neden Agile ve Scrum küçük ekiplerde işe yarar?

Küçük ekipler genellikle hızlı karar alma, sık iletişim ve değişime çabuk uyum sağlama avantajına sahiptir. Çevik yaklaşımlar, kısa iterasyonlar ve düzenli geri bildirim sayesinde bu avantajları güçlendirir. Sprint planlamanın rolü ve etkinliği hakkında daha fazla bilgi için bir referans kaynağına bakabilirsiniz: Sprint Planlama Toplantısı - Sonix ve sprint planlamasının çevik süreçlerdeki önemini anlatan bir değerlendirme: UDNApps.

Scrum'un temel yapı taşları

• Roller: Product Owner (ürün sahibi), Scrum Master (kolaylaştırıcı) ve Geliştirme Ekibi.
• Etkinlikler: Sprint Planlama, Günlük Stand-up, Sprint İncelemesi (Review), Retrospektif.
• Eserler: Product Backlog, Sprint Backlog, Potansiyel Yayınlanabilir Ürün Artışı (increment).

Scrum çerçevesi, roller, etkinlikler ve eserlerle yapılandırılmıştır ve sprintler genellikle 1–4 hafta arasında sabit uzunlukta seçilir (kaynak: Invictus Wiki).

Sprint uzunluğu ve hedef belirleme

Genel kural olarak sprint uzunluğu 1–4 hafta arasındadır. Küçük ekipler için 1 veya 2 haftalık sprintler daha sık geri bildirim almayı, riskleri erkenden yakalamayı ve öncelikleri hızlıca değiştirmeyi kolaylaştırır. Sprint hedefi (Sprint Goal) her sprintin yönünü belirler; sprint sonunda potansiyel olarak yayınlanabilir bir ürün artışı hedeflenmelidir (Invictus Wiki).

Adım Adım Sprint Planlama (Pratik Rehber)

1. Ön hazırlık: Backlog temizliği ve önceliklendirme

   Product Owner backlog öğelerini önceliklendirir ve her bir öğe için kabul kriterlerini hazırlar. Bu adım sprint planlama verimliliğini artırır.

2. Kapasite ve hız (velocity) hesaplama

   Kapasite, sprintteki toplam kullanılabilir kişisel çalışma saatlerinin toplamıdır. Basit bir yaklaşım: ekip üyelerinin kullanılabilir günlerini toplayın, sprint gün sayısı ve günlük çalışma saati ile çarpın, toplantı ve beklenmeyen işler için %15–25 arası bir pay ayırın. Ekip daha önce sprint yapmışsa, geçmiş hız (velocity) kullanarak hikâye puanları ile uyumlu hale getirin.

3. Sprint hedefinin (Sprint Goal) belirlenmesi

   Kısa, açık ve ölçülebilir bir hedef seçin. Örnek: “Kullanıcıların ödeme işlemini tamamlayabilmesi için ödeme akışında 3 kritik hatayı düzeltmek ve ödeme sayfasını test etmek.”

4. Backlog öğelerinin seçilmesi ve işlere bölünmesi

   Seçilen kullanıcı hikâyelerini (user stories) görevlere (tasks) bölün. Her görev için tahmini süre (saat) veya göreli büyüklük (story point) verin. Kabul kriterlerini netleştirin.

5. İş dağılımı ve önceliklendirme

   Her görevin sahibi (owner) atanır. Kritik bağımlılıklar sprint başında görünür olmalıdır.

6. Test ve sürüm planı

   QA adımları, otomasyon gereksinimleri ve olası yayın (release) adımlarını sprint içinde planlayın. CI/CD adımlarını sprint backloguna ekleyin.

7. Sprint taahhüdü ve kickoff

   Ekip seçilen işler için taahhütte bulunur ve sprint kickoff ile çalışmaya başlar.

Kısa bir kapasite hesaplama örneği (örnek)

Ekibiniz 4 kişiden oluşsun, sprint 10 iş günlüğü (2 hafta). Her kişi günlük 6 kullanılabilir saat ayırabiliyorsa:

• Toplam kullanılabilir saat = 4 kişi × 10 gün × 6 saat = 240 saat
• Toplantılar ve beklenmeyen işler için %20 pay = 48 saat
• Net kullanılabilir = 192 saat

Bu saati hikâye puanlarına çevirmek için ekibin ortalama hızını (geçmiş sprintlerdeki ortalama tamamlanan hikâye puanı) kullanın veya her işi görev bazında saatle tahmin edin.

Örnek 2 Haftalık Sprint Planı (Küçük Ekip İçin)

Aşağıdaki tablo örnek amaçlıdır; somut bir 2 haftalık sprintin nasıl yapılandırılabileceğini gösterir.

Günlük Stand-up, Review ve Retrospektif

Günlük stand-up (maksimum 15 dakika): her üyenin ne yaptığı, ne yapacağı ve engeller. Sprint Review: tamamlanan işler demo edilir ve paydaşlardan geri bildirim alınır. Retrospektif: süreç iyileştirmeleri belirlenir ve bir sonraki sprint için aksiyonlar tanımlanır. Bu etkinlikler Scrum çerçevesinde yer alır ve sprint planlamayla birlikte çalışır (Sonix - Sprint Planlama).

Sürüm Yönetimi (Sürüm / Release) ve CI/CD Önerileri

• Sürüm stratejisi: Küçük ekipler için sık ve küçük yayınlar genellikle daha az risklidir. Semantic Versioning (MAJOR.MINOR.PATCH) gibi basit bir adlandırma tercih edilebilir.
• CI/CD: Kod her ana dal (main/master) için otomatik test ve deploy pipeline'ı kurun. Release adımlarını sprint backloguna ekleyin.
• Rollback planı: Yayın öncesi basit bir geri alma prosedürü tanımlayın (örnek: hızlı revert veya feature flag kullanan strateji).

İş Akışı (Workflow) ve Araçlar

Küçük ekipler için önerilen temel iş akışı sütunları: Backlog → Selected for Sprint → In Progress → Code Review → QA → Done. Popüler araçlar arasında Jira, GitHub Projects, GitLab veya Trello/Notion gibi hafif işler için çözümler vardır; hangi aracı kullandığınız, ekibin büyüklüğüne ve mevcut altyapınıza bağlıdır.

Ölçümler ve KPI'lar

• Velocity: Tamamlanan hikâye puanlarının sprint başına ortalaması.
• Burndown: Sprint içindeki işin azalma grafiği (günlük takip için faydalı).
• Cycle Time / Lead Time: Bir işin başlangıcından tamamlanmasına kadar geçen süre.
• Escaped Defects: Üretime çıkan hatalar sayısı (sprint sonrası kalite göstergesi).

Bu ölçümler süreç iyileştirmesi içindir; tek başına amaç olmamalıdır. KPI'ları ekibin bağlamına göre yorumlayın.

Pratik Kontrol Listeleri

Planlama Öncesi

• Product Backlog önceliklendirildi mi?
• Her seçilecek hikâyenin kabul kriterleri net mi?
• Gerekli tasarım ve teknik kararlar alındı mı?

Sprint Başlangıcı

• Sprint Goal tanımlandı mı?
• Kapasite hesaplandı mı?
• Her görev sahibi atandı mı?

Yayıma Hazır Öncesi

• Tüm kabul kriterleri karşılandı mı?
• Otomatik testler çalışıyor mu? Manual smoke test yapıldı mı?
• Deployment adımları ve rollback prosedürü hazır mı?

Yaygın Tuzaklar ve Çözüm Önerileri

• Aşırı taahhüt: Geçmiş velocity'e göre taahhüt verin; ekstra işler için tampon bırakın.
• Belirsiz kabul kriterleri: Her hikâyenin net kabul kriterleri olmalı; belirsizlikleri planlama öncesi giderin.
• Test geri planı yok: QA ve otomasyon görevlerini sprintin bir parçası yapın.
• İletişim eksikliği: Günlük kısa toplantılar ve görünür bir sprint board iletişimi sağlar.

Sonuç

Küçük ekipler için Scrum temelli bir yaklaşım, kısa sprintler, net sprint hedefleri ve iyi hazırlanmış planlama ile etkili çalışır. Yukarıdaki adımlar, kontrol listeleri ve örnek sprint planı, kendi takımınıza uyarlamanız için bir temel sağlar. Sprint planlamanın önemi ve etkinliğine dair kapsamlı açıklamalar için kaynakları inceleyebilirsiniz: Sonix, UDNApps, Invictus Wiki.