Yapay Zekâ Projeleri için Scrumban — Sprint Ritmi ile Sürekli Akışı Birleştirmek

Scrum ve Kanban'ı yalnızca kartların biraz farklı hareket ettiği iki pano olarak görürsek, asıl farkı kaçırırız. Her iki yöntem de işi düzenler; fakat daha temelde zamanı, dikkati ve değişimi farklı biçimde düzenler. Scrum, ekibin seçilmiş bir iş miktarını sınırlı bir süre boyunca koruduğu bir ritim oluşturur. Kanban ise kapasite açıldığında yeni işin çekildiği bir akış kurar.

Yapay zekâ projelerinde çoğu zaman iki mantığa da aynı anda ihtiyaç duyulur. Bir özellik, prototip veya belirlenmiş entegrasyon aşaması, anlamlı bir değerlendirme yapılabilmesi için birkaç günlük kesintisiz odak gerektirebilir. Buna karşılık yeni bulgular, kullanıcı geri bildirimleri, veri problemleri, içerik işleri, hatalar, model testleri ve operasyonel talepler akmaya devam eder. Her şeyi sprintlere sıkıştırmak birikme ve gereksiz katılık üretir. Her şeyi açık bir akışa bırakmak ise ekibin odağını kaybetmesine ve önemli işleri bitirmeden yenilerini başlatmasına yol açabilir.

Scrumban'a giden pratik köprü tam da burada kuruluyor. Scrum ve Kanban burada birbirine rakip inanç sistemleri gibi ele alınmaz. Karşılaştırmanın ardından şu netleşir: Hiçbiri "altın kural" değildir, seçim projeye, faza ve göreve göre değişir. Pratikte önerilerin büyük bölümü zaten karışık modellere yaklaşır — Scrum ve Kanban karışımı, "Scrumban" olarak adlandırılan bir hibrit yaklaşım.

Bu nedenle bu seride Scrumban, dışarıdaki bir kural kitabından eksiksiz kopyalanması gereken katı bir çerçeve olarak ele alınmıyor. Önce pratikten türeyen bir proje kontrol mantığı olarak okunuyor: Nerede korumalı bir sprint ritmine, nerede sürekli pull mantığına dayanan akışa ihtiyacım var ve bu iki sistemin birbirini sabote etmesini nasıl engellerim?

Aynı projenin içinde iki saat

Scrum ile Kanban arasındaki fark özellikle işin sisteme ne zaman alındığı ve nasıl korunduğu üzerinden ortaya çıkar. Scrum; planlama, inşa etme, test etme ve review döngüsüne dayanan sprintli bir yaklaşımdır. Seçilmiş bir iş kümesi belirli bir süre boyunca odaklanarak yürütülür. Yeni gereksinimlerin devam eden sprinti sürekli yeniden kurmaması beklenir. Sprint sonunda review yapılır; sonuca göre iş kabul edilir, değiştirilir veya yeni bir sprint planlanır.

Kanban ise sürekli bir süreçtir. İş durumlar arasında ilerler ve kapasite açıldıkça yeni işler sisteme çekilir. Böylece hareket, önceden kapatılmış bir iş paketinden çok önceliğe, darboğazlara ve mevcut işlem kapasitesine göre şekillenir.

İki mantık farklı problemleri çözer. Sprint konsantrasyonu ve commitment'ı korur. Akış ise hareketi ve throughput'u korur.

Tablonun gösterdiği asıl fayda şudur: Hibrit mantık iki yöntemi yan yana yapıştırmaz. İki farklı zaman biçimini birbirine bağlar.

Özellik geliştirme ile içerik üretimi aynı şey değildir

Açıklayıcı bir örnek: Bir projede özellik geliştirme ve MVP mantığı için Scrum önerilmişti; çünkü burada net bir sprint ritmi anlamlıydı. Lansman çevresindeki içerik üretimi için ise Kanban daha uygun görülmüştü; sürekli işleyen bir pipeline ve hızlı iterasyon bu işin doğasına daha iyi oturuyordu.

Bu ayrım yapay zekâ projelerinde çok önemlidir. Bir özellik çoğu zaman birden fazla bağımlı adımın birlikte tamamlanmasını gerektirir. Bir arayüz, ajan workflow'u veya retrieval modülü her küçük ara adımın sonunda "bitmiş" sayılamaz. Ekibin işi bir bütün olarak inşa edip test edeceği ve sonunda değerlendireceği korumalı bir pencereye ihtiyacı vardır.

İçerik, destek, küçük veri düzeltmeleri veya tekrarlayan operasyonel işler ise farklı davranır. Sürekli gelirler, boyutları ve öncelikleri değişir ve yapay biçimde iki haftalık paketlere sıkıştırılmaları gerekmez. Burada sürekli akış daha doğal olabilir.

Scrumban, aynı proje içindeki farklı iş türleri farklı ritimler gerektirdiğinde değer kazanmaya başlar.

Sprint bir takvim ritüeli değil, koruma alanıdır

Scrum'u yalnızca iki haftalık takvime indirgemek yaygın bir hatadır. Asıl önemli olan sprintin koruma işlevidir. Ekip belirli işleri seçer ve onlara odaklanır. Yeni talepler otomatik olarak anlık yeniden önceliklendirmeye dönüşmez.

Bu koruma yapay zekâ projelerinde özellikle değerlidir; çünkü yapay zekâ çalışmasının tehlikeli bir özelliği vardır: Yeni olasılıklar, eskileri düzgün doğrulayabildiğimizden daha hızlı ortaya çıkar. Bir ajan workflow'u geliştirilirken yeni bir model keşfedilir. Model test edilirken başka bir araç fikri çıkar. Veri pipeline'ı stabilize edilirken bir Deep Research üç yeni mimari alternatifi getirir.

Her yeni olasılık devam eden işe anında girerse ortaya çeviklik çıkmaz. Sürekli bağlam değiştirme çıkar.

İyi bir sprint bu nedenle geçici bir karar koruması oluşturur. Sınırlı bir süre boyunca belirli bir hedef, hipotez veya teslimat gerçekten değerlendirilebilir seviyeye kadar işlenir. Yeni fikirler kaybolmaz. Düzenli bir giriş kanalına gider ve daha sonra ele alınır.

Kanban bağlantısı tam burada anlam kazanır.

Akış bir basınç tahliye kanalıdır, filtresiz gelen kutusu değil

Kanban, sürekli süreç, pull mantığı ve work-in-progress sınırlarına dayanır. Bu makale açısından en önemli nokta pull ilkesidir: Bir iş yalnızca var olduğu için başlatılmaz. Sistem onu sorumlu biçimde ileri taşıyacak kapasiteye sahip olduğu için başlatılır.

Bu fark büyüktür.

Kapasite mantığı olmayan açık görev havuzu bir flow sistemi değildir. Suçluluk hissi üreten bir kuyruktur.

Scrumban modelinde sürekli kanalın görevi bu yüzden nettir. Sprintin korunan odağını tekrar tekrar parçalamadan kısa, bağımsız veya operasyonel biçimde ele alınabilecek işleri taşır. Küçük düzeltmeler, içerik görevleri, dokümantasyon bakımı, sınırları belirli testler veya destek işleri öncelik ve kapasiteye göre bu kanalda ilerleyebilir.

WIP limitleri, rolling waves ve kontrol edilebilir iş paketleri bu serinin ilerleyen makalelerinde daha derin ele alınacak. Scrumban açısından şimdilik şu ilke yeterlidir: Akış, yalnızca gerçekten ilerletilebilecek kadar işi sisteme almalıdır.

En önemli Scrumban sınırı: Sprinti ne kesebilir?

Hibrit sistemin kalitesi panonun ne kadar şık olduğuyla anlaşılmaz. Sprint ile flow arasındaki sınır kuralıyla anlaşılır.

Her yeni flow işi sprinti kesebiliyorsa ortada fiilen sprint yoktur. Hiçbir acil bulgu sprinti etkileyemiyorsa sprint bu kez gerçekliğe karşı bir duvara dönüşür.

Bu yüzden yapay zekâ projelerinde açık bir kesinti mantığı gerekir. Yeni bir model fikri çoğunlukla mevcut işi durdurma gerekçesi değildir. Güzel bir optimizasyon önerisi de değildir. Buna karşılık bir güvenlik problemi, hatalı veri temeli veya sprintin ana varsayımını geçersiz kılan yeni kanıt gerçek bir eskalasyon olabilir.

Bu fark profesyonel biçimde şu soruyla ifade edilebilir:

Yeni bilgi yalnızca seçeneklerimizi mi genişletiyor, yoksa şu anda yaptığımız işin geçerliliğini mi ortadan kaldırıyor?

Sprinti kesme ihtimali ancak ikinci durumda ciddi biçimde değerlendirilmelidir.

Böylece proje yeni kanıta açık kalır fakat her yeni dürtünün yönettiği bir sisteme dönüşmez.

User story, review ve "küçük ama teslim edilebilir parça" mantığı

Bir fonksiyon daha küçük ve tarif edilebilir iş birimlerine ayrılır, zorluk veya efor kabaca değerlendirilir, uygulamadan sonra review yapılır ve geri bildirim sonucun kabul edilmesi, değiştirilmesi veya geliştirilmesi üzerinde etkili olur.

Bu önemlidir; çünkü Scrumban'ı yaygın bir yanlış anlamadan koruyor. "Küçük görev" otomatik olarak iyi iş birimi değildir. Önemli olan iş parçasının test edilebilir ve sonraki karara bağlanabilir olmasıdır.

Bir yapay zekâ projesinde "ajanı iyileştir" kötü bir iş birimidir. Açık uçludur, ölçülemez ve net bir review üretmez.

Daha güçlü bir örnek şöyle olabilir: "Araştırma ajanı, onaylanmış on kaynaktan yapılandırılmış bir taslak oluşturmalı ve her merkezi iddiayı bir kaynağa geri bağlayabilmelidir; ardından izlenebilirlik üç test vakasında doğrulanacaktır."