AI Geliştirmede Scope Creep Önleme: Değişiklik Talebi

AI Geliştirmede Scope Creep Önleme: Değişiklik Talebi

AI araçlarıyla geliştirme hızlandığında bir yan etki ortaya çıkıyor: scope creep de hızlanıyor.

Mantık şöyle işliyor: "AI zaten yazıyor, bir şey daha eklemek ne kadar sürer ki?" Kullanıcı profil sayfası yapılıyor, "bir de bildirim tercihleri ekleyelim" deniyor. AI yazıyor. "Hep buradayken şifre değiştirme de olsun" deniyor. AI yazıyor. Sprint sonunda profil sayfası dört feature'a dönüşmüş, ikisi yarım kalmış, teslim tarihi kaçmış.

AI'ın hızı "eklemek kolay" hissini yaratıyor. Ama eklenen her şey test gerektirir, review gerektirir, entegrasyon gerektirir, dokümantasyon gerektirir. Bu maliyet görünmüyor çünkü AI'ın yazdığı satırlar görünüyor.

AI ile Scope Creep Neden Farklı Büyüyor?

Geleneksel geliştirmede scope creep yavaş büyürdü çünkü her ekleme "bunu kim yazacak, ne kadar sürer?" sorusunu tetiklerdi. Bu soru doğal bir frenleme mekanizmasıydı.

AI bu freni kaldırıyor. "Kim yazacak?" sorusu ortadan kalkınca "ne kadar sürer?" sorusu da önemsizleşiyor. Geriye yalnızca "ekleyelim mi?" sorusu kalıyor. Ve bu sorunun cevabı çoğu zaman "evet" oluyor.

Görünmez maliyet birikimi: Her "küçük ekleme" test kapsamını genişletiyor, QA süresini uzatıyor, review yükünü artırıyor. AI kodu yazıyor ama bu yan maliyetleri yazmıyor.

Bağlam kayması: Orijinal görevin ne olduğu unutuluyor. Sprint sonunda "biz ne yapmaya çalışıyorduk?" sorusu geliyor. Cevap dağınık.

Yarım kalan işler: Birden fazla şey aynı anda başlandı çünkü AI hepsini yazabilirdi. Ama hiçbiri tam bitmedi çünkü her birinin testi, review'u, entegrasyonu ayrı iş.

Deadline kayması görünmüyor: Görevler "In Progress" durumunda duruyor ama aslında kapsam üç katına çıkmış. Kapsam büyüdüğünü takip eden sistem olmadığı için gecikme sürpriz geliyor.

Değişiklik Talebi Sürecinin Mantığı

Scope creep'i sıfırlamak mümkün değil — ve gerekli de değil. Bazı değişiklikler gerçekten değer katıyor. Sorun değişikliğin kendinde değil, kontrolsüz girmesinde.

Değişiklik talebi süreci şunu yapıyor: her yeni isteği "hemen yap" yerine "önce değerlendir" kanalına yönlendiriyor. Değerlendirme 10 dakika alıyor. Bu 10 dakika "eklemeyelim" kararını değil, "bilinçli ekleyelim veya eklemeyelim" kararını mümkün kılıyor.

Alios'ta bu süreç dört adımda kuruluyor: talep → etki analizi → onay → değişiklik günlüğü.

Adım 1 — Değişiklik Talebi Node'u

Sprint ortasında veya görev sırasında gelen her yeni istek — nereden gelirse gelsin — önce bir değişiklik talebi node'u olarak açılıyor. Doğrudan mevcut göreve eklenmeden.

📌 DEĞİŞİKLİK TALEBİ — [Numara]: [Kısa başlık]
Durum: Değerlendiriliyor
Tarih: [Talep tarihi]
Talep Eden: [İsim / Rol]
İlgili Sprint: [Sprint numarası]
Bağlantılı Node: [Değişikliğin etkilediği görev]

📋 TALEP DETAYI

Ne isteniyor:
[Tek paragraf — ne değişmeli veya eklenmeli]

Neden isteniyor:
[İş gerekçesi — hangi problemi çözüyor,
hangi değeri katıyor]

AI rolü:
[ ] AI bu talebi önerdi
[ ] AI bu talebi kolaylaştırıyor
[ ] AI bu taleple doğrudan ilgili değil

Aciliyet:
[ ] Bu sprint'e girmeli — sebep: [Neden bekleyemez]
[ ] Sonraki sprint — uygun
[ ] Backlog — zaman alabilir

Neden Ayrı Node?

Değişiklik talebi mevcut görevin açıklamasına eklenmediğinde iki şey oluyor: orijinal görevin kapsamı korunuyor, ve talep değerlendirilmeden önce göreve girmemiş oluyor.

Bu ayrım küçük görünüyor ama kritik. "Eklendi, sonra değerlendirelim" yerine "değerlendirildi, sonra eklendi" düzenini kuruyor.

Adım 2 — Etki Analizi

Değişiklik talebi açıldıktan sonra etki analizi yapılıyor. Bu adım değişikliğin gerçek maliyetini görünür kılıyor.

🔍 ETKİ ANALİZİ

Efor tahmini:
[ ] Küçük — yarım günden az
[ ] Orta — 1-2 gün
[ ] Büyük — 3+ gün
[ ] Belirsiz — spike gerekiyor

Etkilenen node'lar:
- [Node adı 1] — nasıl etkileniyor
- [Node adı 2] — nasıl etkileniyor
- [Node adı 3] — nasıl etkileniyor

Sprint etkisi:
[ ] Mevcut sprint kapasitesi içinde kalıyor
[ ] Mevcut sprint'ten bir şey çıkarılması gerekiyor
    → Çıkarılacak: [Node adı]
[ ] Bu sprint'e sığmıyor — sonraki sprint'e alınmalı

Test etkisi:
[Yeni değişiklik hangi test senaryolarını etkiliyor,
hangi yeni testler gerekiyor]

Teknik borç riski:
[ ] Yok
[ ] Var — [Açıklama]

AI maliyet notu:
AI bu değişikliği hızlı yazabilir ama şu ek maliyetler
görünmez kalmamalı:
- [ ] Review süresi: [Tahmini]
- [ ] Test yazımı: [Tahmini]
- [ ] Entegrasyon kontrolü: [Tahmini]
- [ ] Dokümantasyon: [Tahmini]

"AI maliyet notu" bölümü bu şablonun en kritik kısmı. AI kodunu dakikalarda yazıyor ama review, test, entegrasyon ve dokümantasyon maliyetleri değişmiyor. Bu maliyetler görünür kılınmadan "küçük ekleme" yanılgısı kırılamıyor.

Adım 3 — Onay Adımı

Etki analizi tamamlandıktan sonra onay alınmadan değişiklik uygulanmıyor. Onay veren kişi değişikliğin gerçek maliyetini görmüş olarak karar veriyor.

✅ ONAY KARARI

Karar:
[ ] ONAYLANDI — bu sprint'e alındı
[ ] ONAYLANDI — sonraki sprint'e alındı
[ ] ONAYLANDI — backlog'a eklendi
[ ] REDDEDİLDİ — gerekçe: [Neden]
[ ] ERTELENDİ — ne zaman: [Koşul]

Onaylayan: [İsim] — Tarih: [Tarih]

Onay notu:
[Varsa ek koşul veya bağlam —
"Bu sprint'e alınabilir ama X node'u sonraki sprint'e
taşınacak" gibi]

Eğer reddedildiyse müşteri/talep eden bilgilendirildi mi?
[ ] Evet — [Tarih / Kanal]
[ ] Hayır — gerekmiyor

Onay adımı bürokratik değil. 5 dakika alıyor. Ama "hızla ekledik, sonra baktık" yerine "bilerek ekledik" kültürünü kuruyor.

Adım 4 — Değişiklik Günlüğü

Onaylanan her değişiklik sprint veya proje node'unun değişiklik günlüğüne işleniyor. Bu günlük scope'un nasıl evrildiğini gösteriyor.

📋 DEĞİŞİKLİK GÜNLÜĞÜ — Sprint [N] / [Proje Adı]

[Tarih] — CR-001: [Başlık]
Karar: Onaylandı — bu sprint'e alındı
Efor: Orta (1.5 gün)
Etkilenen: [Node adı]
Neden: [1 cümle gerekçe]

[Tarih] — CR-002: [Başlık]
Karar: Reddedildi
Neden: Sprint kapasitesi dolu, Q3 roadmap'e alındı

[Tarih] — CR-003: [Başlık]
Karar: Onaylandı — sonraki sprint
Efor: Büyük (3 gün)
Not: AI bu değişikliği hızlı yazabilir ama
entegrasyon testi 2 günlük ek iş gerektiriyor

Bu günlük sprint retrospektifinde "kapsam neden kaydı?" sorusunun cevabı oluyor. Aynı zamanda "ne sıklıkla ve neden değişiklik talebi geldi?" sorusunu yanıtlıyor — bu pattern ileride daha iyi planlama yapılmasını sağlıyor.

Kopyalanabilir Change Request Şablonu

Alios'ta her değişiklik talebi için kopyalanıp kullanılacak tam şablon:

📌 DEĞİŞİKLİK TALEBİ — CR-[Numara]: [Başlık]
Durum: Değerlendiriliyor
Tarih: [Tarih]
Talep Eden: [İsim]
İlgili Sprint: [Sprint N]
Bağlantılı Node: [Node adı]

📋 TALEP

Ne isteniyor:
[Açıklama]

Neden isteniyor:
[Gerekçe]

AI rolü:
[ ] AI önerdi  [ ] AI kolaylaştırıyor  [ ] İlgisiz

Aciliyet:
[ ] Bu sprint  [ ] Sonraki sprint  [ ] Backlog

🔍 ETKİ ANALİZİ

Efor: [ ] Küçük  [ ] Orta  [ ] Büyük  [ ] Belirsiz

Etkilenen node'lar:
- [Node] — [etki]

Sprint etkisi:
[ ] Kapasitede kalıyor
[ ] Şunu çıkarmak gerekiyor: [Node]
[ ] Bu sprint'e sığmıyor

AI maliyet notu:
- Review: [Tahmini]
- Test: [Tahmini]
- Entegrasyon: [Tahmini]
- Dokümantasyon: [Tahmini]

✅ ONAY

[ ] Onaylandı — bu sprint
[ ] Onaylandı — sonraki sprint
[ ] Onaylandı — backlog
[ ] Reddedildi — gerekçe: [Neden]
[ ] Ertelendi — koşul: [Ne zaman]

Onaylayan: [İsim] — [Tarih]
Not: [Varsa]

📋 DEĞİŞİKLİK GÜNLÜĞÜNE EKLENDİ
[ ] Sprint [N] değişiklik günlüğüne işlendi

Scope Creep Sinyalleri: Bunları Görünce Dur

Change request süreci her zaman başlatılmayabilir — özellikle AI hızıyla ilerlenirken. Şu sinyaller görüldüğünde durulması gerekiyor:

"Hep buradayken..." cümlesi: Yapılan iş tamamlanmadan yeni bir şey ekleme dürtüsü. Bu cümle scope creep'in en klasik başlangıcı.

"AI yazıyor zaten, ne kadar sürer ki?": Yazma süresinin sıfırlanması diğer maliyetleri de sıfırladığı anlamına gelmiyor.

Orijinal görev tanımından uzaklaşma: Açıklama alanına bakıldığında yapılan iş artık orijinal görevle örtüşmüyor.

Etkilenen node sayısı artıyor: Bir değişiklik beşten fazla node'u etkiliyorsa bu küçük bir ekleme değil, yeni bir epik.

Sprint kapasitesi doldu ama "bir şey daha" isteniyor: Bu noktada change request süreci değil, sprint'ten çıkarılacak şeyin belirlenmesi gerekiyor.

Son Düşünce

AI ile geliştirme hızı değerli. Ama hız kontrol olmadan büyüyen kapsamla birleşince sprint sonunda yarım kalan işler, kaçan deadlinelar ve "ne yapmaya çalışıyorduk?" sorusu geliyor.

Alios'ta scope creep önleme ve değişiklik talebi süreci bu kontrolü kuruyor. Her yeni istek önce değerlendiriliyor, etki analizi yapılıyor, bilinçli onaylanıyor. AI hızını kaybetmeden kapsam disiplini korunuyor.

"Ekleyelim mi?" sorusu artık "hemen" yerine "ne maliyetle?" sorusuyla birlikte soruluyor.