logo
Retrospektifler
Planlama Pokeri
Standuplar
BuzKırıcılar
Fiyatlandırma
Kontrol Paneli

Gönderiler

Sprint'inizde yapay zeka ajanları: copilot'lar story point'in anlamını nasıl değiştiriyor

Bir yapay zeka kodlama asistanıyla çalışan geliştirici çifti, bir ekranda kod üretilirken diğerinde story point tahminleri olan bir sprint panosu görüntüleniyor, yapay zeka hızı ile geleneksel tahmin arasındaki gerilimi yansıtıyor
Matt Lewandowski

Matt Lewandowski

Son güncelleme 10/02/20267 dk okuma

Ekibinizdeki bir backend mühendisi 5 puanlık bir story alıyor. Geçmişte bu, bir buçuk günlük işti. Cursor ve Claude ile bir saat içinde teslim ediyor. Bir sonraki sprint'te, ekip benzer bir ticket'a bakıyor ve biri soruyor: "Bu hala 5 mi?" Kimsenin iyi bir cevabı yok. Bu şu anda her yerde ekiplerin başına geliyor ve çoğu agile içeriği bu duruma henüz yetişmedi.

Sorun velocity enflasyonu değil

Açık tepki "harika, artık daha hızlıyız" olabilir. Ancak sorun büyük velocity rakamlarından daha derine iniyor. Story point'ler göreceli karmaşıklığı ölçmesi gerekiyor. Bir 5, kimin aldığına bakılmaksızın kabaca aynı miktarda çabayı temsil etmeli. Yapay zeka bu varsayımı iki şekilde bozuyor: Hızlanma eşit değil. Copilot kullanan bir junior geliştirici, rutin bir CRUD endpoint'inde 3 kat hız artışı görebilir. Karmaşık bir entegrasyon üzerinde, tanıdık olmayan API'lerle çalışan bir senior geliştirici hiç iyileşme görmeyebilir veya aslında yavaşlayabilir. 2025 ortalarındaki METR çalışması, deneyimli açık kaynak geliştiricilerin gerçek dünya görevlerinde yapay zeka yardımıyla %20 daha hızlı olduklarına inanırken aslında %19 daha yavaş olduklarını buldu. Aynı kişi bazı görevlerde daha hızlı ama diğerlerinde değil. Yapay zeka ajanları boilerplate ve iyi belgelenmiş kalıpları iyi idare eder. Mimari kararlar ve özel kod tabanınız hakkında derin bağlam gerektiren her şeyle mücadele ederler. Bir geliştirici sabah üç tane 3 puanlık story'yi hızla bitirebilir, ardından yapay zekanın makul ama yanlış çözümler üretmeye devam ettiği tek bir 5 puanlık story'de iki gün geçirebilir. Bu, tahmini son derece tutarsız hale getirir. Velocity grafiğiniz sismograf gibi görünmeye başlar.

Ekiplerin gerçekte deneyimledikleri

Yapay zeka destekli ekiplerle sprint yürüten mühendislik yöneticileriyle konuştuğunuzda aynı kalıpları duyarsınız: Hiçbir şey ifade etmeyen velocity rakamları. Bir ekip, sprint başına istikrarlı 45-60 puandan 55-65'e çıktıklarını bildirdi, ancak yapılan iş orantılı olarak farklı hissettirmiyordu. Daha hızlı kodlama, daha hızlı teslimat anlamına gelmiyordu çünkü kod inceleme, QA ve deployment zaman çizelgeleri aynı kaldı. İnceleme darboğazı. GitHub verileri, 2025 sonlarına kadar aylık kod gönderilerinin 82 milyonu aştığını ve yeni kodun %41'inin yapay zeka destekli olduğunu gösteriyor. Pull request'ler birikiyor. Ekipler incelemeler için 4+ gün beklediğini bildiriyor. Geliştirici kodu bir saatte yazdı, sonra inceleme kuyruğunda bir hafta bekliyor. Farklı şekilde biriken teknik borç. Yapay zeka tarafından üretilen kod çalışma eğilimindedir ancak mimari farkındalıktan yoksundur. Çalışmalar, yapay zeka destekli kod tabanlarında 4 kat daha fazla kod tekrarı ve %60 daha az refactoring olduğunu gösteriyor. 3 puanlık story hızla teslim edilir. Altı ay sonra bakımda bunun bedelini ödersiniz. Sprint panosu, çok hızlı tamamlanan ve kod incelemesinde takılı kalan karışık tamamlanmış ve takılı ticket'ları gösteriyor, yapay zeka destekli geliştirmenin düzensiz akışını gösteriyor Kağıt üzerinde senior gibi görünen junior geliştiriciler. İki yıllık deneyime sahip bir geliştirici artık on yıllık biriyle aynı çıktıyı üretebilir. Ancak her bir yapay zeka önerisini incelerken 1,2 dakika harcıyorlar, senior'ın 4,3 dakikasına kıyasla. Bu kalite farkı production'a kadar ortaya çıkmayacak.

Story point'ler bozuk değil, ama yeniden kalibrasyona ihtiyaç var

Story point'leri tamamen atmak için duyulan içgüdü erken. Point'ler hala ekip uyumu ve sprint planlama konuşmaları için işe yarıyor. Değişmesi gereken şey ekiplerin bunları nasıl kalibre ettiğidir.

"Kodlama çabasını" "teslimat çabasından" ayırın

Yapay zekanın hızlandırdığı kısım (kod yazma) bir story'nin yaşam döngüsünün sadece bir parçası. Daha dürüst bir dağılım:
AşamaYapay zeka etkisi
Gereksinimleri anlamaMinimal
Kod yazmaYüksek (rutin işlerde 2-10 kat daha hızlı)
Kod incelemeNegatif (incelenecek daha fazla kod, genellikle daha düşük kalite)
Test etmeOrta (yapay zeka testler üretebilir ama birinin doğrulaması gerekir)
Entegrasyon ve deploymentMinimal
Ekibiniz story'leri öncelikle kodlama süresine göre tahmin ettiyse, point'leriniz artık yanlış kalibre edilmiş. Toplam teslimat çabasına göre tahmin ettiyseniz, muhtemelen doğruluğa daha yakındır.

Referans story'lerinizi yeniden kalibre edin

Her ekibin çapa story'leri vardır: "O ödeme entegrasyonunu hatırlıyor musun? O bir 8'di." Bu çapalar yapay zeka öncesinde belirlendi. Güncelleyin. Son iki sprint'ten 5-10 tamamlanmış story'yi yeniden tahmin ettiğiniz bir yeniden kalibrasyon oturumu yapın. Planning poker aracınızı kullanın ve sorun: "Yapay zekanın bu tür işleri nasıl etkilediği hakkında bildiklerimizi bilerek, bunu ne tahmin ederdik?" Eski ve yeni tahminler arasındaki boşluklar size kalibrasyonunuzun nerede yanlış olduğunu tam olarak söyleyecektir.

Ölçmenin diğer yolları

Bazı ekipler story point'lerden tamamen uzaklaşıyor ve yapay zeka benimsenmesi bu değişimi hızlandırıyor. Cycle time, bir ticket'ın başlangıçtan bitişe kadar ne kadar sürdüğünü ölçer. Sadece birinin kodu ne kadar hızlı yazdığını değil, inceleme darboğazını ve deployment pipeline'ını içerir. Cycle time'ı takip eden ekipler, kodlama hızı iki katına çıksa bile yapay zekanın genel teslimat hızında iğneyi zar zor hareket ettirdiğini buluyor. Throughput, ekibin boyutu ne olursa olsun sprint başına kaç öğeyi tamamladığını sayar. Ekibiniz geçen sprint 12 story ve bu sprint 14 story teslim ettiyse, bu bir "point"in ne anlama geldiğini tartışmadan faydalı bir bilgidir. DORA metrics (deployment sıklığı, lead time, change failure rate, restore etme süresi) çıktı yerine sonuçlara odaklanır. Yapay zeka kodlamayı daha hızlı yaptığında ancak daha az dikkatli inceleme nedeniyle change failure rate'ler yükseldiğinde, DORA, velocity rakamlarının gizlediği ödünleşimi gösterir. Farklı metrikleri yan yana gösteren dashboard, geleneksel velocity grafiği ile cycle time ve throughput grafikleri karşılaştırılıyor, ekip performansı hakkında farklı kalıpları ortaya çıkarıyor Story point'leri icat ettiği için sıklıkla anılan Ron Jeffries şöyle dedi: "Story point'leri icat etmiş olabilirim ve eğer yaptıysam, şimdi pişmanım." Endişesi, point'lerin bir planlama aracı yerine bir üretkenlik ölçüsü olarak yanlış kullanılmasıydı. Yapay zeka bu kötüye kullanımı daha da kötüleştiriyor.

Şu anda gerçekten işe yarayan şey

2026 başlarında ekiplerin bildirdiklerine dayanarak: Planning poker'i sürdürün, ama konuşmayı değiştirin. Tahmin toplantısı hala değerli. Bir story'de neyin yer aldığı hakkındaki tartışma, atadığınız sayıdan daha önemli. Ancak soruları güncelleyin: "Yapay zeka bunda yardımcı olacak mı?" konuşmanın bir parçası olmalı. Bir story çoğunlukla boilerplate ise, söyleyin. Yapay zekanın yanıltıcı çözümler üreteceği karmaşık bir entegrasyon ise, bunu da işaretleyin. Yapay zeka tarafından üretilen kodu tamamlanmış iş değil, ilk taslak olarak değerlendirin. İnceleme süresini tahminlerinize dahil edin. Yapay zekanın kodun %80'ini yazdığı bir story, bir geliştiricinin her satırı yazdığı bir story'den daha fazla inceleme süresi gerektirebilir, çünkü inceleyenin sadece kalite yerine niyeti doğrulaması gerekir. Algı farkına dikkat edin. O METR bulgusunu hatırlayın: geliştiriciler aslında %19 daha yavaşken %20 daha hızlı olduklarına inanıyorlardı. Yapay zeka kullanmak daha üretken hissettiriyor çünkü kod üretmek sıfırdan yazmaktan bilişsel olarak daha hafif. Bu his her zaman saatle eşleşmiyor. Sprint taahhütlerinizi şişirmesine izin vermeyin. Kodladığınızı değil, teslim ettiğinizi ölçün. Daha hızlı kodlamaya rağmen ekibinizin cycle time'ı iyileşmediyse, darboğaz başka bir yerde. Story point'ler hakkında endişelenmeden önce bunu düzeltin. Yeniden kalibre ederken farklı tahmin ölçekleriyle denemeler yapmak isteyen ekipler için, Kollabe, ekibiniz yapay zeka destekli iş akışında neyin işe yaradığını çözerken uyarlayabileceğiniz Fibonacci, T-shirt boyutları ve özel ölçekleri destekler.

Bu bir süreç problemi

Bunu iyi idare eden ekipler bir yapay zeka tahmin aracı satın almadı. Yapay zekanın işlerinin nasıl yapıldığını değiştirdiğini fark ettiler ve süreçlerini ayarladılar. Bu, yapay zekanın nerede yardımcı olduğu ve nerede olmadığı hakkında dürüst konuşmalarla başlar. Altı ay önceki velocity'niz artık faydalı bir taban çizgisi değil. Ve kodlama çıktısı ile gerçek teslimat arasındaki boşluk hiç bu kadar geniş olmadı, bu yüzden teslimat tarafına odaklanın.

Zorunlu değil. Story point'ler hala ekip tartışması ve sprint planlaması için göreceli bir boyutlandırma aracı olarak işe yarıyor. Yapmanız gereken şey referans story'lerinizi yeniden kalibre etmek ve tahmin yaparken ekibinizin yapay zekanın düzensiz etkisini hesaba kattığından emin olmak.

Sadece kodlama süresini değil, toplam teslimat çabasını tahmin edin. Kodlamak 10 dakika ama incelemek ve test etmek 2 saat süren bir story hala anlamlı bir iş parçasıdır. Düşüncenizi implementasyon ve doğrulama arasında bölün.

Rutin, iyi tanımlanmış görevlerde, fark önemli ölçüde daralıyor. Mimari yargı gerektiren karmaşık işlerde, senior'lar hala daha iyi performans gösteriyor çünkü yapay zeka önerilerinin ne zaman yanlış olduğunu biliyorlar. Gerçek risk, junior'ların ince sorunları yakalayacak deneyimi olmadan yapay zeka tarafından üretilen kodu teslim etmeleri.

Cycle time ve throughput, kalibrasyon baş ağrıları olmadan teslimat performansının daha net bir resmini sunar. DORA metrics (deployment sıklığı, lead time, change failure rate) hızın yanında kaliteyi de yakalar. Çoğu ekip, velocity'yi tamamen değiştirmek yerine üçünü de velocity ile birlikte takip etmekten fayda görür.