AI ile Roadmap Epik Task: Planı Koddan Önce Kur

AI ile Roadmap Epik Task: Planı Koddan Önce Kur

AI araçlarıyla kod yazmak kolaylaştığında "hemen başlayalım" cazip geliyor. Claude mimari öneriyor, Cursor boilerplate yazıyor, Copilot fonksiyonları tamamlıyor. Neden plan yapılsın ki, AI zaten yazıyor?

Çünkü AI neyin yazılması gerektiğini bilmiyor.

AI nasıl yazılacağını biliyor. Hangi pattern, hangi kütüphane, hangi yaklaşım — bunlarda güçlü. Ama "bu sprint'te ne yapılmalı, bu epik hangi iş hedefine bağlı, bu task'ın başarısı nasıl ölçülüyor" sorularının cevabı AI'da değil.

Plan olmadan AI hızlı ama yanlış yönde gidiyor. Ya da doğru yönde ama koordinasyonsuz — her geliştirici kendi anladığı şeyi yazıyor, sprint sonunda parçalar birleşmiyor.

Plan Olmadan AI ile Ne Oluyor?

AI destekli geliştirmede plansız başlamanın üç tipik sonucu var.

Kapsam belirsizliği büyüyor. "Kullanıcı yönetimi yap" deniyor, AI bir şeyler üretiyor. Ama "kullanıcı yönetimi" ne demek? RBAC mı, toplu import mu, davet sistemi mi? Her geliştirici farklı anlıyor, AI farklı üretiyor. Sprint sonunda koordinasyon kopuk.

Tamamlanma tanımı yok. "Bitti mi?" sorusu geldiğinde herkes farklı cevap veriyor. Geliştirici "yazdım" diyor, ürün "test edilmedi" diyor, müşteri "istediğim bu değildi" diyor. Kabul kriteri baştan yazılmamış.

Owner belirsiz. AI kodu herkes için yazıyor ama o kodun sorumlusu kim? Review kim yapacak, test kim yapacak, canlıya kim alacak? Sahiplik tanımlanmadığında iş yarım kalıyor — herkes bir başkasının tamamladığını sanıyor.

Üç Seviyeli Hiyerarşi: Üst Hedef → Epik → Task

Alios'ta plan üç seviyede kuruluyor. Her seviyenin kendine özgü sorusu ve çıktısı var.

📁 ÜST HEDEF
"Ne başarmak istiyoruz?" — iş çıktısı

    └── 📁 EPİK
        "Bunu yapmak için hangi iş grupları gerekiyor?"
        — teslim edilebilir parça

            └── 📌 TASK
                "Bu epik için bugün ne yapılmalı?"
                — atanabilir, kapatılabilir görev

Her seviyede üç şey zorunlu: çıktı tanımı, kabul kriteri, owner.

Bu üç şey olmadan node sprint'e alınmıyor. "Yazılacak" değil — "kim yazacak, ne zaman bitecek, bitti sayılması için ne gerekiyor" net olacak.

Örnek: SaaS Ürünü — Ekip Yönetimi Modülü

Gerçekçi bir ürün üzerinden tam hiyerarşi:

📁 ÜST HEDEF — Q3: Kurumsal Müşteri Self-Serve Onboarding
Owner: Ürün Müdürü — Selin
Deadline: 30 Eylül
Başarı kriteri:
- Kurumsal müşteri admin hesabı açıp ekibini
  davet edebiliyor — destek ekibi müdahalesi olmadan
- Ortalama onboarding süresi 5 günden 1 güne inecek
- İlk ayda 3 kurumsal müşteri bu akışı kullanacak

Bağlam:
Mevcut durumda kurumsal müşteri kaydı manuel —
CS ekibi her adımda yardım ediyor. Bu hem ölçeklemiyor
hem müşteri memnuniyetini düşürüyor.
Q2 NPS anketinde "kayıt süreci karmaşık" ilk 3
şikayette. Bu hedef doğrudan o şikayetin çözümü.

 📁 EPİK 1 — Rol Bazlı Erişim Kontrolü (RBAC)
    Owner: Backend Lead — Ali
    Deadline: 15 Eylül
    Bağlı üst hedef: Q3 Kurumsal Onboarding

    Çıktı tanımı:
    Admin kullanıcı ekip üyelerine rol atayabiliyor.
    Roller: Admin, Editor, Viewer. Her rolün erişim
    sınırları tanımlı ve uygulanıyor.

    Kabul kriteri:
    • Admin başka kullanıcıya rol atayabiliyor
    • Editor içerik düzenleyebiliyor, ayarlara erişemiyor
    • Viewer yalnızca okuyabiliyor, düzenleyemiyor
    • Rol değişikliği anında uygulanıyor, logout gerekmez
    • Yetkisiz erişim denemesi 403 dönüyor ve loglanıyor

    AI kullanım planı:
    RBAC middleware ve permission check fonksiyonları
    Claude ile yazılacak. Prompt'a şu bağlam verilecek:
    mevcut auth yapısı, kullanıcı modeli şeması,
    rol enum değerleri.

📌 TASK 1.1 — RBAC veri modeli tasarımı
        Owner: Ali
        Deadline: 2 Eylül
        Efor: Küçük (yarım gün)

        Çıktı tanımı:
        Role ve Permission tabloları tasarlandı,
        migration hazır, seed data oluşturuldu.

        Kabul kriteri:
        • Role tablosu: id, name, permissions (JSON)
        • UserRole junction tablosu: user_id, role_id,
          assigned_by, assigned_at
        • 3 varsayılan rol seed'i var: Admin, Editor, Viewer
        • Migration çalışıyor, rollback test edildi
        • Ali'nin review'undan geçti

        AI notu:
        Şema tasarımı Claude ile yapılacak. Mevcut
        User modeli ve ilişkileri prompt'a verilecek.

     
 📌 TASK 1.2 — RBAC middleware implementasyonu
        Owner: Ali
        Deadline: 5 Eylül
        Efor: Orta (2 gün)
        Bağımlılık: TASK 1.1 DONE olmalı

        Çıktı tanımı:
        Her API endpoint'i için permission kontrolü
        yapan middleware yazıldı ve entegre edildi.

        Kabul kriteri:
        • requirePermission('resource', 'action') middleware
          çalışıyor
        • Yetkisiz istek 403 + hata mesajı dönüyor
        • Yetki kontrolü her endpoint'te tek satırda
          uygulanabiliyor
        • Unit test coverage: kritik permission
          senaryoları için %80+
        • Code review: Mehmet onayladı

        AI notu:
        Middleware Claude ile yazılacak. Prompt'a
        şu bilgiler verilecek: Express middleware
        yapısı, mevcut auth middleware örneği,
        permission enum listesi.

  
 📌 TASK 1.3 — Frontend permission kontrolleri
        Owner: Mehmet
        Deadline: 9 Eylül
        Efor: Orta (2 gün)
        Bağımlılık: TASK 1.2 DONE olmalı

        Çıktı tanımı:
        UI elementleri kullanıcının rolüne göre
        gösteriliyor veya gizleniyor. Viewer için
        düzenleme butonları görünmüyor.

        Kabul kriteri:
        • usePermission() hook çalışıyor
        • Admin paneli menüsü role göre filtreleniyor
        • Düzenleme formları Editor ve Admin'e açık,
          Viewer'a gizli
        • Gizleme CSS ile değil, render koşuluyla yapılıyor
          (kaynak kodda da görünmemeli)
        • Mehmet'in kendi review'u + Ali cross-check


 📌 TASK 1.4 — Admin panel rol yönetimi UI
        Owner: Mehmet
        Deadline: 12 Eylül
        Efor: Orta (1.5 gün)
        Bağımlılık: TASK 1.3 DONE olmalı

        Çıktı tanımı:
        Admin kullanıcı listesinden herhangi bir
        üyenin rolünü değiştirebiliyor. Değişiklik
        anında uygulanıyor.

        Kabul kriteri:
        • Kullanıcı listesinde her satırda rol dropdown var
        • Rol değişikliği kaydet butonuna gerek yok —
          seçimde anında kaydediliyor
        • Başarı/hata toast bildirimi gösteriliyor
        • Admin kendi rolünü değiştiremiyor
        • Mobil görünüm düzgün çalışıyor

     
   📌 TASK 1.5 — RBAC entegrasyon testi
        Owner: Zeynep
        Deadline: 15 Eylül
        Efor: Orta (2 gün)
        Bağımlılık: TASK 1.4 DONE olmalı

        Çıktı tanımı:
        Tüm rol senaryoları uçtan uca test edildi,
        edge case'ler kapsandı, staging'de onaylandı.

        Kabul kriteri:
        • Admin → Editor → Viewer rol değişim senaryoları
          test edildi
        • Yetkisiz erişim denemeleri test edildi — 403
        • Aynı anda rol değişikliği (race condition)
          test edildi
        • 0 Kritik, 0 Yüksek açık bug
        • Test senaryoları node'a yazıldı, tekrarlanabilir

  📁 EPİK 2 — Ekip Davet Sistemi
    Owner: Mehmet
    Deadline: 22 Eylül
    Bağlı üst hedef: Q3 Kurumsal Onboarding

    Çıktı tanımı:
    Admin e-posta adresiyle ekip üyesi davet edebiliyor.
    Davet linki 48 saat geçerli. Kabul edince hesap
    oluşuyor, rol otomatik atanıyor.

    Kabul kriteri:
    • Toplu davet: virgülle ayrılmış e-postalar
    • Davet e-postası 2 dakika içinde gidiyor
    • Süresi dolmuş link "yeniden davet al" yönlendiriyor
    • Davet bekleyen kullanıcılar admin panelinde görünüyor
    • RBAC ile entegre — davet sırasında rol seçilebiliyor

        └── [TASK 2.1 — 2.4 aynı formatta devam eder]

📁 EPİK 3 — Onboarding Wizard
    Owner: Mehmet
    Deadline: 29 Eylül
    Bağlı üst hedef: Q3 Kurumsal Onboarding

    Çıktı tanımı:
    Yeni admin ilk girişte 4 adımlı wizard ile
    karşılanıyor: şirket adı → ilk ekip üyesi daveti
    → rol atama → tamamlandı ekranı.

    Kabul kriteri:
    • Wizard tamamlanma oranı izleniyor — analytics event
    • Her adım bağımsız kaydediliyor — yarıda
      çıkılırsa kaldığı yerden devam
    • Mobil uyumlu
    • Wizard tamamlama süresi ortalama 3 dakikanın altı
    • Destek talebi olmadan tamamlanabiliyor

        └── [TASK 3.1 — 3.3 aynı formatta devam eder]

Hiyerarşiyi Kurmak: Adım Adım

Adım 1 — Üst hedefi yaz, sayısal kriter ekle. "Kurumsal onboarding'i iyileştir" değil, "onboarding süresi 5 günden 1 güne inecek." Sayı olmadan başarı ölçülemiyor.

Adım 2 — Epikleri bağımsız teslim edilebilir parçalara böl. RBAC olmadan davet sistemi yazılabilir ama çalışmaz. Bu bağımlılık epik sırasına yansıtılıyor.

Adım 3 — Task'ları tek kişinin 1-3 günde biteceği büyüklükte tut. Daha büyükse parçalanmalı. "RBAC implementasyonu" tek task değil — veri modeli, middleware, frontend, UI, test: beş ayrı task.

Adım 4 — Her task için kabul kriteri yaz, sonra AI'a ver. "RBAC middleware yaz" prompt değil. "RBAC middleware yaz — şu kabul kriterleri karşılanmalı: [liste]" prompt. AI çıktısı kabul kriterlerine göre değerlendiriliyor.

Adım 5 — Bağımlılıkları node'a yaz. "TASK 1.2, TASK 1.1 DONE olmadan başlamaz" bilgisi node'da yazıyor. Sprint planlamasında sözlü değil, yazılı.

Son Düşünce

AI kod yazıyor. Plan yazmıyor.

Roadmap → epik → task hiyerarşisi kurulmadan AI hızı dağılıyor. Herkes bir şeyler üretiyor ama sprint sonunda parçalar birleşmiyor, tamamlanma tanımı yok, sahiplik belirsiz.

Alios'ta çıktı tanımı, kabul kriteri ve owner ile kurulan bu hiyerarşi AI'ın ürettiği kodu anlam taşıyan bir sisteme dönüştürüyor. Kod hızlı yazılıyor — ama doğru şey, doğru sırayla, doğru kişi tarafından.