Sprint Öncesi Teknik Analiz: Mid-Sprint Felaketlerini Önleyen 'Mutfak Hazırlığı'

Agile dünyasında tehlikeli bir yanlış anlaşılma var: “Kervan yolda düzülür, kodlarken çözeriz.”

Deneyimli mühendislik liderleri ise gerçeği iyi bilir: Planlama yapılmadan başlanan işin sonu kaos, teknik borç ve kaçan deadline’lardır. Teknik Analiz, yazılım dünyasının “mise en place”idir (profesyonel mutfaktaki ön hazırlık). Nasıl ki şefler ocağı yakmadan önce tüm malzemelerini doğrayıp hazırlar; yazılım ekibi de kod yazmaya başlamadan önce veri yapılarını, API uçlarını ve iş kurallarını netleştirmelidir. Bu süreç, “dökümantasyon yazmak” demek değildir; Sprint başladığında ekibin önünde engel kalmamasını sağlamaktır.

Agile Serisi — Kopya Kağıdı’nın 4. Bölümü.

Süreç: Direksiyon Takımda

Bu aşama tamamen yazılım mühendisleri ve QA ekibinin sorumluluğundadır. Ürün Yöneticisi (PO) masada olmak zorunda değildir; sadece çok spesifik iş kuralları soruları olursa çağrılır.

Temel Hedef: Planlama toplantısına girmeden önce tüm teknik bilinmezleri ortadan kaldırmak.

1. Teknik Parçalama (Technical Decomposition)

Ekip, iş gereksinimini alır ve teknik yapılacaklar listesine dönüştürür:

• Veritabanı Hareketleri: “‘Orders’ tablosuna ‘status’ kolonu eklenecek.” -> Bu detayı ilgili Jira kaydına teknik not olarak ekleyin.
• Refactoring İhtiyacı: “Ödeme servisi çok karmaşıklaşmış, buraya girmeden önce temizlememiz lazım.” -> Hemen bir Teknik Borç alt görevi (sub-task) açın.
• Kontratlar: API hangi JSON’ı dönecek, hangi HTTP kodunu verecek? Şimdiden belirleyin.

2. QA Entegrasyonu: Test Senaryoları

Modern ekiplerde QA, kod bittikten sonra “bug avlayan” kişi değildir. Kod henüz ortada yokken Test Senaryolarını yazan kişidir.

• Bu senaryolar, geliştirici daha tek satır kod yazmadan masaya konur.
• Böylece geliştirici, “Kodum bu testten geçmeli” diyerek geliştirmeye başlar (TDD mantığına benzer).

3. Bilinmezi Yönetmek: Spike ve POC

Eğer ekip bir iş için “Şu kütüphane bunu destekliyor mu, emin değiliz” diyorsa, o işe tahmin (estimate) verilmez.

• Hemen bir Spike (araştırma görevi) açılır.
• Bir geliştirici, hızlıca “at-gitsin” (throwaway) bir kod yazarak durumu doğrular.
• Eğer Spike sonucu olumsuzsa, o iş Sprint’e alınmaz.

Eleştiri & Gerçeklik: Bu “Mini-Waterfall” Değil Mi?

Agile tutucuları (purists) bu yöntemi duyunca irkilebilir: “Kodlamadan önce tasarım yapmak Waterfall değil midir?”

Yanıtımız: “Risk yönetimi” yapmak Waterfall değildir; mühendisliktir.

• İhtiyaç Halinde: Domain’i avcunun içi gibi bilen kıdemli bir ekip, bu aşamayı 10 dakikada zihnen yapıp geçebilir.
• Zaman Sınırlı (Time-Boxed): Bu, haftalar süren hantal bir tasarım süreci değildir. Sprint başına sadece 1-2 saattir. Amacı, 5. günün sonunda “Aa biz bunu düşünmemiştik” sürprizini engellemektir.
• Esnek: Amaç “kusursuz mimari” kurmak değil, ekibin önünü görmesini sağlamaktır. Sprint içinde doğaçlama yapmak “Agile” değil, kumardır.