Humindx Docs

Appearance

ADR 002: Saf Scrum Yerine Dual-Track Geliştirme ​

  • Tarih: 2026-04-16
  • Durum: Kabul Edildi (Accepted)
  • İlgili Bileşen: Süreç / Ekip Ritmi
  • Bağlam Dosyaları: ../../CONTRIBUTING.md, ../testing-strategy.md, ../../psychometrics/llm-orchestration.md
  • Sahip: Simetri

1. Bağlam ve Problem ​

Humindx, klasik bir CRUD ürünü değil: psikometrik algoritma + LLM ajanı + vektör uzayı üçgeninde çalışır. Bu, iki farklı doğada işin aynı ekibin üzerinde birleşmesi demek:

  • Delivery işi (deterministik): endpoint, UI, migration, RLS testi, CI boru hattı — sprint'e sığar.
  • Discovery işi (stokastik / araştırma): prompt iterasyonu, eval seti tasarımı, skorlama katsayı kalibrasyonu, adversarial test — kaç gün süreceği gerçekten belli değil.

Saf Scrum ritmi (sabit 2 haftalık sprint, baştan taahhüt), discovery işini ya görünmez kılar ya da sahte bir taahhüde sokup sürekli "kaydırma"ya yol açar. Bu da hem ekibin motivasyonunu hem de paydaş güvenini bozar.

2. Karar ​

Dual-track Agile benimsenir:

  • Delivery track = Kanban + WIP limit. Linear'daki mevcut issue akışı, CONTRIBUTING.md branch stratejisi ve DoD (§8) bu track'a aittir.
  • Discovery track = ayrı Linear view ("Discovery"). "Time-boxed araştırma" mantığıyla, çıktı sonunda ya bir ADR ya bir eval raporu ya da "bu yön terk edildi" notu olur.

Her iki track aynı ekibi paylaşır; aynı kişi aynı anda tek track'ta çalışır (context switch maliyetini düşürmek için).

3. Değerlendirilen Alternatifler ​

3.1. Saf Scrum (2 haftalık sprint + taahhüt) ​

  • Artıları: Tanıdık; paydaş için öngörülebilir.
  • Eksileri: LLM/prompt işinde taahhütler sürekli kayar; "%85 accuracy" hedefini sprint sonuna garanti edemezsin.
  • Neden seçilmedi: Güvenilmezlik → güven kaybı.

3.2. Saf Kanban ​

  • Artıları: Esnek, discovery için uygun.
  • Eksileri: Araştırma işine özel ritim ve "bitti" tanımı zor; research tourism riski.
  • Neden seçilmedi: Tek başına yeterli değil, ayrı bir discovery ritmi gerek.

3.3. Shape Up (6 haftalık betting cycle) ​

  • Artıları: Büyük, belirsiz işler için güçlü.
  • Eksileri: 2-3 kişilik pre-MVP ekip için overhead; cycle sonu "shape" süreci yorucu.
  • Neden seçilmedi: Ekip büyüyünce tekrar değerlendirilebilir.

3.4. Hiçbir framework — ad-hoc ​

  • Artıları: Minimum prosedür.
  • Eksileri: Doğrulanabilir iş ritmi yok; yatırımcıya / B2B müşteriye "nasıl çalışıyorsunuz" sorusuna yanıt zor.
  • Neden seçilmedi: Pre-development fazında bile minimum bir ritim şart.

4. Gerekçeler ​

  1. Stokastik işi görünür kılar. Discovery track, "prompt'u iyileştiriyorum" işini sprint taahhüdünden kopararak gerçekçi bir ritim verir.
  2. Delivery güvenilirliğini korur. Kanban + WIP limit, taahhüt edilen işin zamanında merge edilmesine engel olacak "araştırma kaydırmalarını" önler.
  3. Operasyonel basitlik. Tek ekip, iki Linear view, tek CI. Shape Up veya SAFe gibi ağır modellerin overhead'i yok.
  4. Eval disiplini ile uyumlu. testing-strategy.md'deki "Katman 3: Regresyon" mantığı, discovery'den delivery'ye geçişte bir "çıkış kontrolü" görevi görür — saf Scrum'da bu kontrol genellikle atlanır.

5. Sonuçlar ve Gelecek Etkileri ​

  • Avantajlar: LLM/algoritma işi gerçekçi ritimde ilerler; delivery commit'leri daha az kaydırma yaşar; "research tourism" (sonsuz keşif) disiplinle sınırlandırılır.
  • Dezavantajlar ve Riskler:
    • İki track arasında iş sınıflandırması her zaman net olmayabilir ("bu iş discovery mi delivery mi?").
    • Aynı kişinin iki track'ta paralel çalışması yasaklanmazsa context switching maliyeti artar.
  • Hafifletme Stratejisi: Haftalık 15 dk triage — her yeni issue açılırken track etiketi verilir; tek kişi tek track kuralı Linear otomasyonu ile izlenir.
  • Ne Zaman Yeniden Değerlendirilir? Ekip 5+ kişi olduğunda (Shape Up tekrar değerlendirilir), ya da discovery yükü %30'un altına düştüğünde (saf Kanban'a dönülebilir).

Simetri tarafından inşa ediliyor.