Scrum, Kanban ve Scrumban: Yapay Zeka Destekli Ekipler

Yapay zeka asistanları artık kodun giderek büyüyen bir kısmını yazıyor. Mühendislik liderleri ise hâlâ Scrum mı, Kanban mı, başka bir çevik çerçeve mi seçecekleri konusunda haftalarca tartışıyor; sonra başka bir şirketin törenlerini kopyalayıp neden hiçbir şeyin daha hızlı akmadığına şaşırıyor. Tuzak, çerçevenin ismini kararın kendisi sanmaktır. Görüşüm şudur: yapay zeka destekli bir ekibin neredeyse hiç markalı bir metodolojiye ihtiyacı yoktur. İhtiyacı olan, bağlamına göre ayarlanmış dört geri besleme döngüsüdür: işin nasıl aktığı, ne sıklıkla yeniden yön belirlediğiniz, paralelde ne kadar iş yürüdüğü ve çıktının nasıl incelendiği. Bu karar merceği, bir sonraki çerçeve modasından sonra da geçerli kalır ve yapay zekanın darboğazı kod yazmaktan uzaklaştırdığını hesaba katar.

Karar, ekibi yöneten kişiye aittir: mühendislik yöneticileri, kurucular, teknik liderler. Argüman birincil kaynaklara (Scrum Guide, Kanban Guide, Çevik prensipler, DORA araştırması) ve her döngünün nereye ayarlanması gerektiğine dair savunulabilir bir varsayılana dayanıyor.

Akış, tempo, WIP, inceleme#

Her döngünün kendi ayarları ve kendi başarısızlık modu var; bu yüzden onları açıkça adlandırmakta fayda var.

Akış, bir iş biriminin fikirden sevkiyata nasıl ilerlediğidir. Onu bir panoda görünür kılar, lead time ve cycle time ile ölçersiniz. DORA’nın teslimat metrikleri burada kalıcı tanımları verir (değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı, başarısız dağıtımdan kurtulma süresi ve yeniden çalışma oranı), throughput ve kararsızlık olarak ikiye ayrılır. Adlandırmaya dair bir not: DORA artık bunlara teslimat metrikleri diyor. Eski “dört anahtar” etiketi, yeniden çalışma oranı eklenmeden ve kurtulma süresi yeniden adlandırılmadan önceye ait.

Yeniden yön belirleme temposu, ekibin ne sıklıkla durup incelediği ve yeniden planladığıdır. Scrum bunu sabit uzunlukta bir Sprint olarak paketler, “one month or less” (bir ay veya daha az), Scrum Guide’ın deyimiyle “ensure inspection and adaptation of progress toward a Product Goal at least every calendar month” amacıyla var olan kalp atışıdır. Kanban aynı döngüyü sürekli akış artı bilinçli tempolar ve geri besleme döngüleri olarak paketler, sabit bir yineleme olmadan.

WIP limitleri, yeni işler başlamadan önce işlerin bitmesi için devam eden işi sınırlar. Bu Kanban’ın özüdür: Kanban Guide “effective systems focus more on flow of work and less on worker utilization” der ve bir çekme sistemi üzerinden “limit the WIP to balance utilization and still ensure the flow of work” gerektiğini söyler. Scrum, WIP kontrolünü Sprint Backlog üzerinden örtük şekilde taşır; açık bir limit koymaz.

İnceleme, bitmiş çıktının “tamamlandı” sayılmadan önce nasıl denetlendiğidir. Yapay zeka asistanlarından önce bu, kod incelemesi artı QA demekti. Asistanlar uygulamanın giderek büyüyen bir kısmını üretirken inceleme döngüsü daha fazla ağırlık taşıyor, çünkü üretmek ucuzladı ama doğrulamak ucuzlamadı. DORA’nın kendisi, kod incelemelerinin ne kadar sürdüğünü öncü bir gösterge olarak ölçmeyi öneriyor.

Scrum, Kanban ve ölçekleme çerçeveleri#

Scrum, yeniden yön belirlemeyi taahhüt edilmiş bir iş yığınıyla birlikte paketleyen sabit bir tempo (Sprint) belirler. Üç sorumluluk (Product Owner, Scrum Master, Developers) ve beş etkinlik döngüleri resmileştirir. Scrum Guide ne olduğu konusunda alışılmadık derecede açık sözlüdür: Scrum’ı “a lightweight framework” olarak adlandırır, “purposefully incomplete, only defining the parts required to implement Scrum theory” der ve şunu ekler: “Scrum wraps around existing practices or renders them unnecessary.”

Kanban, açık WIP limitleri, bir çekme sistemi ve geri bildirim için planlı tempolarla sürekli akış belirler. Genel pratikleri bir ayar kontrol listesi gibi okunur: işi görselleştir, WIP’i sınırla, akışı yönet, politikaları açık hale getir, geri besleme döngüleri uygula ve birlikte iyileştir. Başlangıç talimatı “start with what you do now” (şu an yaptığınızla başlayın).

Scrumban, bir Scrum ekibini akışa doğru çekmek için bir geçiş tekniği olarak başladı. Extreme Programming, sıkı mühendislik döngülerini (eşli programlama, test güdümlü geliştirme, sürekli entegrasyon) aynı akış-ve-inceleme omurgasının üstüne sarar; SAFe ve LeSS gibi ölçekleme çerçeveleri ise çoğunlukla birçok ekip arasına koordinasyon döngüleri ekler. Kniberg ve Skarin’in yapay zeka tabloya girmeden çok önce yazılmış klasik karşılaştırması, Scrum ve Kanban’ı aynı kadranları farklı varsayılanlarla ayarlayan araçlar olarak ele alır.

Yapay zeka destekli ekiplerde değişen kısıt#

Asistanın değiştirdiği şey, kısıtın nerede durduğudur. Uygulama süresini sıkıştırıyorsa, uygulamayı (ucuzlayan kısmı) optimize etmek pek fayda sağlamaz. Kısıt inceleme, entegrasyon ve ne inşa edileceğine karar vermeye kayar; yatırımın yeri de burasıdır.

Belirleyici olan toplu iş boyutudur ve varsayılan olarak yanlış yöne iter. Ucuz üretim daha fazla kod yazmayı kolaylaştırır, bu da değişiklik setlerini büyütür ve daha büyük değişiklik setleri DORA’nın tutarlı risk sinyalidir. DORA teslimat rehberi açıktır: “Teams should make each change as small as possible to make the delivery process fast and stable.” Yani daha hızlı üretim, daha küçük toplu işleri ve daha sıkı incelemeyi gerektirir. Liderler burada verimlilik manşetlerine de direnmeli, çünkü kanıtlar gerçekten çelişiyor.

Sürekli akış varsayılanı#

İsimli bir çerçeveyi benimsemeden önce sürekli akış varsayılanlarına yönelin: işi görselleştirin, WIP’i sınırlayın, kısa bir yeniden yön belirleme temposu tutun ve inceleme döngüsünü güçlendirin.

Çoğu küçük-orta ölçekli yapay zeka destekli ekip için, açık bir inceleme döngüsüne sahip hafif, Kanban tadında bir akış, törensel Scrum’ı geride bırakır. Bu, yapay zeka iş akışının zaten atlamayı ucuzlaştırdığı toplu iş ve tahmin yükünü kaldırır ve dikkati yapay zekanın kritik hale getirdiği döngüye (incelemeye) yöneltir.

Scrum’ın sabit temposu bir geçersiz kılma durumudur. Ekibin dışsal bir taahhüt ritmine ihtiyacı olduğunda yükünü hak eder: programlı paydaş demoları, düzenlemeye tabi bir sürüm treni ya da isimli etkinliklerin iskelesinden fayda gören kıdem açısından genç bir ekip. Aşağıdaki karar ağacı varsayılanda köklenir ve yalnızca bir geçersiz kılmanın gerçekten karşılığını verdiği yerlerde dallanır.

Bir geçersiz kılma daha adlandırmayı hak ediyor. Halihazırda ağır bir çerçeve yürütüyorsanız ve törenler tiyatro gibi geliyorsa, daha hafif metodu bir geçiş olarak ele alın. Scrumban aslında tam da buydu: bir Scrum ekibini akışa doğru çekmenin bir yolu. Hedef durumu başlamadan önce adlandırın; yoksa hibrit kendiliğinden kalıcılaşır.

Her ayarın bedeli#

Her ayarın bir başarısızlık modu vardır; seçim yapmadan önce bunları bilmek gerekir.

Ayar	Kazandığınız	Dikkat edilecek başarısızlık modu
Sürekli akış varsayılanı	Düşük tören yükü, dikkat akış ve incelemede	Görünmez önceliklendirme ve inceleme tempolarını bilinçli planlamadıkça doğal bir “dur ve düşün” anının olmaması; tepkisel yangın söndürmeye kayabilir
Scrum sabit tempo	Öngörülebilir ritim, yerleşik bir retrospektif, dışsal bir taahhüt anı	Tahmin tiyatrosu, velocity oyunlama, toplu iş gecikmeleri, kendi hatırına tutulan tören
Geçiş olarak daha hafif bir metot (ör. Scrumban)	Ağır törenden geçişi kolaylaştırır	Hedefi olmayan kalıcı bir varış noktası olarak ele alınırsa “iki dünyanın da kötüsü”
Yapay zeka inceleme yatırımı	Yeni risk yüzeyini yakalar (yapay zeka kaynaklı hatalar, uydurma API’ler)	İnceleme yükü kısıt haline gelir; onu adlandırın ve kadro ayırın

Yapay zekanın teslimat hızına dair kanıtlar#

Kanıtlar çelişiyor ve her çalışma bir liderin aynı anda tutması gereken çekinceler taşıyor.

DORA’nın 2024 Accelerate State of DevOps Report’u, yapay zeka benimsemenin bireysel verimliliği, akışı ve iş tatminini artırdığını, ancak yapay zeka benimsemedeki birim artış başına teslimat throughput’unda yaklaşık %1,5 düşüş ve teslimat kararlılığında yaklaşık %7,2 düşüş tahmin ettiğini bildirdi. Çekince yöntemde: bu, çok sayıda ekip üzerinden kendi beyanına dayalı bir anket korelasyonudur; ilişkiyi gösterir, nedeni ortaya koyamaz. DORA’nın okuması mekaniktir. Yapay zeka daha fazla kod yazmayı kolaylaştırır, toplu iş boyutu büyür, daha büyük değişiklik setleri daha fazla risk taşır ve temeller (küçük toplu işler, sağlam test) hâlâ geçerlidir. 2025 takip baskısı, “State of AI-assisted Software Development,” yapay zekayı bir yükselteç olarak yeniden çerçeveler: throughput yükselebilir, ancak ekibin güçlü testi, olgun sürüm kontrolü ve hızlı geri besleme döngüleri yoksa kararlılık aşağı akışta bozulur. Çözüm olarak yine küçük toplu işlere işaret eder.

METR’nin randomize kontrollü denemesi ters yöne çıktı. Kendi depolarında çalışan on altı deneyimli açık kaynak geliştiricisinde, erken 2025 yapay zeka araçlarını kullanmak görevleri yaklaşık %19 uzattı; oysa aynı geliştiriciler yaklaşık %20 daha hızlı olduklarına inanıyordu. METR çekinceleri de belirtiyor: kümelenmiş standart hatalarla küçük örneklem, zaten bildikleri kod tabanlarında çalışan uzman geliştiriciler ve sürekli değişen erken 2025 araçları.

GitHub’ın kendi deneyi çok daha dar bir görevde tersini gösteriyor. Bir JavaScript HTTP sunucusu yazan 95 profesyonel geliştiriciyle yapılan deneyde, Copilot kullanan grup yaklaşık %55 daha hızlı bitirdi, %95 güven aralığı %21 ila %89. Çekinceler de aynı derecede yük taşıyor: çalışmayı ürünün sahibi yürüttü, yani bir çıkar çatışması var; görev belirsiz mimari iş değil, tek ve iyi sınırlanmış bir sıfırdan problemdi; ve başarı oranındaki fark istatistiksel olarak anlamlı değildi.

Üçünü bir arada tutunca tablo yeterince netleşiyor. Hızlanma, var olduğu yerde üretimde yoğunlaşıyor; teslimat ise toplu iş boyutuna, entegrasyona ve incelemeye bağlı kalıyor.

Adlandırmaya değer daha küçük ikinci bir anlaşmazlık var, çünkü liderlerin Scrum’ı nasıl okuduğunu şekillendiriyor. Scrum Guide, Scrum’ı hafif ve bilinçli olarak eksik diye çerçeveler; akış ve post-agile uygulayıcıları, pratikteki Scrum’ın törene dönüşüp katılaştığını savunur ve Ladas’ın kendisi “could not tolerate another round of sprint planning” yazdı ve Scrum tahmin yaklaşımını bir “bad practice” olarak değerlendirdi. Ekibe bağlı olarak ikisi de doğru. Test şu: her tören sizin bağlamınızda hâlâ bir döngüye hizmet ediyor mu?

Tören tuzakları#

• Törenleri kimlik olarak benimsemek. Her ritüel için hizmet ettiği döngüyü adlandırın; hiçbiri yoksa onu kesin.
• Katılımı ve story point’leri başarı olarak izlemek. DORA’nın teslimat metriklerini (değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı) ve kendi panonuzdaki WIP’i izleyin.
• “Yapay zeka bizi hızlandırdı” diye sprintleri uzatmak. Daha hızlı üretim, daha küçük toplu işleri ve daha sıkı incelemeyi gerektirir. Döngüyü uzatmak yanlış değişkeni optimize eder.
• Yapay zeka verimlilik manşetlerini kesinleşmiş saymak. Çalışmalar çelişiyor. Onları aktarın, çekinceleri tutun ve üreticinin iddiası yerine kendi akış metriklerinizi izleyin.
• Başka bir şirketin sürecini olduğu gibi kopyalamak. Döngü niyetini kopyalayın, sonra kendi döngü parametrelerinizi belirleyin.

Varsayılanın geçerli olmadığı durumlar#

Varsayılan, çoğu küçük-orta ölçekli yapay zeka destekli ekip için geçerlidir: dört döngüyü ayarlayın, hafif sürekli akıştan başlayın ve serbest kalan dikkati inceleme döngüsüne yöneltin. Dışsal bir tarafa öngörülebilir bir ritim borçlu olduğunuzda, yeni kurulmuş veya kıdem açısından genç bir ekibin iskeleye ihtiyacı olduğunda ya da düzenlemeye tabi bir sürüm treni temposu sizin yerinize belirlediğinde Scrum’ın sabit temposuna yönelin. Scrumban gibi bir geçiş metoduna yalnızca bir köprü olarak, aklınızda bir hedef durumla yönelin.

Sonraki adım küçük. Şu an yürüttüğünüz bir töreni seçin, hizmet ettiği döngüyü adlandırın ve hiçbirine hizmet etmiyorsa bu hafta onu bırakın.

Kaynaklar#

• The 2020 Scrum Guide (yeni sekmede açılır) - Scrum etkinlikleri, üç sorumluluk ve “lightweight” ile “purposefully incomplete” çerçevelemesi için Schwaber ve Sutherland’dan birincil kaynak.
• The Official Guide to The Kanban Method (Kanban University) (yeni sekmede açılır) - Kanban’ın genel pratikleri (görselleştir, WIP’i sınırla, akışı yönet, politikaları açık hale getir, geri besleme döngüleri) ve çekme sistemi gerekçesi için birincil kaynak.
• Principles behind the Agile Manifesto (yeni sekmede açılır) - On iki prensip; aralarında “the team reflects, then tunes and adjusts its behavior” ve “maximizing the amount of work not done” maddeleri var.
• DORA: Software delivery performance metrics (yeni sekmede açılır) - Değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı, başarısız dağıtımdan kurtulma süresi ve yeniden çalışma oranının tanımları, artı küçük toplu iş rehberi.
• DORA: Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - Yapay zeka trade-off bulgusu (bireysel verimlilik artar; teslimat throughput’u ve kararlılığı düşer) ve toplu iş boyutu mekanizması.
• DORA: State of AI-assisted Software Development 2025 (yeni sekmede açılır) - Yapay zekayı mevcut mühendislik güçlü ve zayıf yanlarının bir yükselteci olarak çerçeveleyen güncel takip baskısı, çözüm olarak küçük toplu işlerle.
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (yeni sekmede açılır) - Deneyimli geliştiricilerin tanıdık depolarda yapay zeka ile yaklaşık %19 daha yavaş olduğunu bulan rastgele kontrollü deneme, artı algı farkı çekincesi.
• GitHub: Quantifying GitHub Copilot’s impact on developer productivity and happiness (yeni sekmede açılır) - %55 daha hızlı sonucu gösteren, ürünün sahibi tarafından yürütülen kontrollü deney; çıkar çatışması ve tek görev çekinceleriyle birlikte. Makale: arXiv 2302.06590 (yeni sekmede açılır).
• Kniberg ve Skarin: Kanban and Scrum, Making the Most of Both (yeni sekmede açılır) - İki yaklaşımı karşılaştıran uygulayıcı klasiği; ikisinin aynı kadranları farklı varsayılanlarla ayarladığı görüşünü destekler.
• Corey Ladas: Remarks on the Original Scrumban Essay (yeni sekmede açılır) - Scrumban’ın mucidi kendi sözleriyle: sınırlı WIP, sürekli teslimat ve olay güdümlü planlamayla Scrum’ın bir geçişi ve modernizasyonu olarak kökeni.
• Scrum Alliance: What is Scrumban? (yeni sekmede açılır) - Scrumban’ı bağımsız bir çerçeve olarak pazarlama eğilimini gösterir; ismin, ayarlaması gereken döngülerden uzun yaşadığı kalıp.