Bağımlılık Yönetimi: Blokajları Erken Görme ve Takip

Bağımlılık Yönetimi: Blokajları Erken Görme ve Takip

Bir görev bitmeden diğeri başlayamıyor. Bu zincir her projede var. Sorun zincirin kendinde değil, zincirin görünmemesinde.

Frontend API'yi bekliyor. API üçüncü parti servisi bekliyor. Üçüncü parti servis onay sürecinde. Bu bağımlılık zinciri hiçbir yerde yazılı değilse Cuma günü "bu bitmedi" sürprizi geliyor. Oysa Pazartesi'de görülseydi üç gün kurtarma penceresi açılırdı.

Blokaj yönetimi erken görmekle başlıyor. Erken görmek ise sisteme bakabilmekle.

Blokajlar Neden Geç Fark Ediliyor?

Blokajların geç görünmesinin üç temel sebebi var.

Bağımlılıklar yazılı değil. "A bitmeden B başlayamaz" bilgisi geliştiricinin kafasında. Sprint planlamasında söylenmedi, göreve not düşülmedi. A geciktiğinde B'nin de gecikeceği ancak A'nın deadline'ı geçince anlaşılıyor.

"Waiting" durumu yok. Çoğu ekip In Progress ve Done arasında bir durum kullanmıyor. Oysa görevlerin önemli bir kısmı aktif çalışılmıyor — bir şey bekleniyor. Bu bekleme "In Progress" etiketiyle gizleniyor. Görünürde iş devam ediyor, aslında bekleniliyor.

Blokaj bildirimi maliyetli hissettiriyor. "Bloke oldum" demek zayıflık gibi algılanıyor veya gereksiz yere alarm yaratıyor gibi hissettiriyor. Geliştirici beklerken başka şeylerle ilgileniyor, blokajı bildirmiyor. Ekip lideri hafta sonunda blokajı öğreniyor.

WAITING Durumu: Beklemeyi Görünür Kılmak

Alios'ta bağımlılık yönetiminin merkezinde WAITING durumu var. Standart akışa eklenen bu durum "aktif çalışılmıyor, bir şey bekleniyor" anlamına geliyor.

🔄 IN PROGRESS  → aktif çalışılıyor
⏳ WAITING      → bir şey bekleniyor, ilerlenemiyor
👀 REVIEW       → tamamlandı, onay bekleniyor
✅ DONE         → kapatıldı

WAITING ile REVIEW arasındaki fark kritik. REVIEW'da iş tamamlandı, başkasının onayı bekleniyor. WAITING'de iş devam etmek için dışarıdan bir girdi bekleniyor — ve bu bekleme nedeniyle görev ilerleyemiyor.

WAITING Node'una Geçerken

Görev WAITING'e geçtiğinde tek satır not yeterli değil. Şu bilgiler node açıklamasına ekleniyor:

⏳ WAITING — [Tarih / Saat]

Ne bekleniyor:
[Spesifik — "API dökümantasyonu" değil,
"Payment servis API key'i ve endpoint listesi"]

Kimden bekleniyor:
[İsim veya ekip — iç / dış]

Ne zaman gelmesi bekleniyor:
[Tarih veya "belirsiz"]

Gelmezse ne olur:
[Bu görevin deadline'ı: X — WAITING N günden
uzun sürerse sprint hedefi risk altına girer]

Alternatif var mı:
[ ] Evet — [Açıklama: mock data ile ilerlenebilir vb.]
[ ] Hayır — tamamen bloke

Bu beş alan blokajı yönetilebilir kılıyor. "Ne bekleniyor, kimden, ne zamana kadar, alternatif var mı?" sorularının cevabı node'da yazıyor. Ekip lideri durumu anlık görebiliyor, müdahale edebiliyor.

Bağımlılık Zincirini Node'lara Yazmak

Sprint planlamasında bağımlılıklar göreve not olarak işleniyor. Bu not sprint boyunca referans alınıyor.

📌 Frontend — Ödeme Geçmişi Sayfası
Durum: IN PROGRESS
Sorumlu: Mehmet
Deadline: Perşembe

Bağımlılık:
→ BEKLİYOR: "Ödeme API'si — Ali" — deadline: Salı öğlen
→ BEKLİYOR: "Tasarım onayı — Zeynep" — deadline: Pazartesi EOD

Not: API Salı öğlene kadar gelmezse bu görev
WAITING'e geçecek, Perşembe deadline'ı risk altında.

Bağımlılık zinciri bu şekilde yazıldığında iki şey oluyor: Mehmet neyi beklediğini biliyor ve ne zaman alarm vermesi gerektiğini biliyor. Ekip lideri ise Salı öğlen kontrol etmesi gerektiğini biliyor.

Bağımlılık Zinciri Örneği

📁 SPRINT 11 — Ödeme Modülü

📌 Stripe API Entegrasyonu
Sorumlu: Ali — Deadline: Salı
Bağımlılık: Dış → Stripe API key onayı (Pazartesi)
Durum: WAITING → API key gelince IN PROGRESS

     ↓ tamamlanınca başlayabilir

📌 Ödeme Geçmişi Backend
Sorumlu: Ali — Deadline: Çarşamba
Bağımlılık: İç → "Stripe API Entegrasyonu" — DONE olmalı
Durum: NOT STARTED

     ↓ tamamlanınca başlayabilir

📌 Ödeme Geçmişi Frontend
Sorumlu: Mehmet — Deadline: Perşembe
Bağımlılık: İç → "Ödeme Geçmişi Backend" — DONE olmalı
Durum: NOT STARTED

     ↓ tamamlanınca başlayabilir

📌 Ödeme Modülü QA
Sorumlu: Zeynep — Deadline: Cuma öğlen
Bağımlılık: İç → "Ödeme Geçmişi Frontend" — DONE olmalı
Durum: NOT STARTED

Bu zincir görünür olduğunda bir hesap yapılabiliyor: Stripe API key Pazartesi gelmezse zincirin tamamı kayıyor ve Cuma QA'sı tehlikeye giriyor. Bu hesap Pazartesi yapılabilirse Salı'ya kadar beklemeye gerek yok — Pazartesi akşamı alternatif plan devreye giriyor.

Haftalık Risk Kontrol Rutini

Bağımlılıkları yazmak yeterli değil. Düzenli kontrol edilmezse yazılan bilgi statik kalıyor, dinamik bir yönetim aracına dönüşmüyor.

Haftada iki kez, toplam 20 dakika:

📋 PAZARTESİ SABAHI — 10 DAKİKA

Soru 1: Bu hafta WAITING durumunda kaç node var?
→ Her WAITING node için:
  • Ne bekleniyor, ne zamana kadar?
  • Süre geçtiyse: neden hâlâ bekleniyor?
  • Bugün takip edilecek kişi belirlendi mi?

Soru 2: Bu hafta deadline'ı olan node'larda
bağımlılık var mı?
→ Bağımlılık tamamlandı mı, yoksa hâlâ bekliyor mu?
→ Tamamlanmamışsa: deadline risk altında mı?

Soru 3: Yeni blokaj sinyali var mı?
→ "Bakacağım" veya "haber veririm" gibi belirsiz
   yanıtlar WAITING'e dönüştürüldü mü?
→ Dönüştürülmediyse: bugün node güncelleniyor

📋 ÇARŞAMBA ÖĞLENI — 10 DAKİKA

Soru 1: Pazartesi'deki WAITING node'ları çözüldü mü?
→ Çözüldüyse: IN PROGRESS'e geçti mi?
→ Çözülmediyse: sprint hedefi etkileniyor mu?

Soru 2: Bu hafta yeni WAITING açıldı mı?
→ Yeni blokajlar için alternatif plan var mı?
→ Cuma'ya yetişmeyecek bir şey şimdi görünüyor mu?

Soru 3: Bağımlılık zincirinde kayma var mı?
→ Zincirin ilk halkası geciktiyse
   sonraki halkalar güncellendi mi?

Çarşamba kontrolü kritik. Cuma'da "bu bitmedi" demek yerine Çarşamba'da "bu yetişmeyebilir" demek iki günlük müdahale penceresi açıyor. Bu pencerede ya blokaj çözülüyor ya kapsam daraltılıyor ya da bir sonraki sprint'e bilinçli taşınıyor.

WAITING Node Yaşlanma Kuralı

WAITING durumunda kalan node'lar için yaşlanma kuralı uygulanıyor:

WAITING süresi 1 gün: Normal — takip ediliyor
WAITING süresi 2 gün: Sarı alarm — aktif takip
WAITING süresi 3 gün: Kırmızı — eskalasyon
WAITING süresi 5+ gün: Sprint hedefi tehlikede — alternatif plan devreye giriyor

Bu kural subjektif değerlendirmeyi ortadan kaldırıyor. "3 günden uzun WAITING" filtresi çalıştırıldığında eskalasyon gerektiren node'lar otomatik görünüyor.

Blokaj Bildirimi Kültürü

Sistem ne kadar iyi kurulursa kurulsun, blokaj bildirmek normalleşmezse WAITING durumu kullanılmıyor.

Blokaj bildirimi kültürünü kuran üç kural:

Kural 1: Blokaj = bilgi, başarısızlık değil. "Bloke oldum" demek "yapamıyorum" değil, "bu bilgiye ihtiyacım var" demek. Ekip liderinin bu ayrımı açıkça söylemesi ve blokajı erken bildireni takdir etmesi kültürü kuruyor.

Kural 2: WAITING bildirimi için izin gerekmez. Geliştirici beklediğinde node'u kendisi WAITING'e alıyor. Onay beklemiyor, toplantı beklemiyor. Node güncellemesi anlık yapılıyor.

Kural 3: Geç bildirilen blokaj değerlendirilir, yargılanmaz. "Neden daha önce söylemedin?" sorusu bir dahaki seferinde erken söylemeyi engelliyor. Bunun yerine "şimdi ne yapabiliriz?" sorusu sorularak çözüme odaklanılıyor.

Son Düşünce

Bağımlılık yönetimi ve blokaj takibi sprint sonunda sürpriz önlüyor. Sürpriz önlemenin yolu ise beklemeyi görünür kılmaktan geçiyor.

Alios'ta WAITING durumu, bağımlılık notları ve haftalık risk rutini bu görünürlüğü kuruyor. Blokaj Cuma günü değil, Pazartesi görünüyor. Görünen blokaj yönetilebilir blokaj.

Domino dizisi yıkılmadan önce ilk taşı yerinde tutmak mümkün — ama yalnızca o taşın sallandığını görebiliyorsan.