Rolling Waves, Vertical Slice ve WIP Limitleri

Ajanik yapay zeka, bir insanın saatler içinde inceleyebileceğinden daha fazla işi dakikalar içinde başlatabilir. Aynı anda araştırabilir, yazabilir, test edebilir, görsel üretebilir, verileri dönüştürebilir, kodu değiştirebilir ve sonraki işleri başka ajanlara devredebilir. Bu onun en büyük güçlerinden biridir – ve aynı zamanda en önemli proje yönetimi risklerinden biridir.

Çünkü bir proje yalnızca çok az şey yapıldığı için başarısız olmaz. Aynı anda çok fazla iş başlatıldığı, uzun vadeli plan sahte bir kesinlikle doldurulduğu veya çok sayıda parçanın gerçekten çalışan bir bütüne dönüşüp dönüşmediği ancak çok geç fark edildiği için de başarısız olabilir.

Bu nedenle belirleyici soru şu değildir: Aynı anda kaç ajanı çalıştırabiliriz?

Asıl soru şudur: İşi nasıl keseriz ki öğrenme, tamamlama ve kontrol, yeni iş üretiminden daha hızlı kalabilsin?

Bu amaç için üç kavram özellikle güçlü bir kombinasyon oluşturur:

Rolling Waves, geleceğin ne kadar ayrıntılı planlanacağını belirler.

Vertical Slice, sistemin hangi tam ve test edilebilir bölümünün sıradaki kanıt olacağını belirler.

WIP Limitleri, başlatılmış ama tamamlanmamış işin aynı anda ne kadar açık kalabileceğini belirler.

Birlikte, ne mikro yönetime ne de sınırsız özerkliğe dayanan bir ajanik proje mimarisi ortaya çıkar. Yapay zeka hızlı çalışabilir. Ancak proje geometrisi, hızın kontrolsüz genişliğe dönüşmesini engeller.

Asıl sorun başlatılmış iştir

Klasik projelerde paralel çalışma pahalıydı. Yeni çalışanların koordine edilmesi, erişimlerin verilmesi, brifinglerin okunması ve toplantıların planlanması gerekiyordu. Ajanik yapay zekada bu başlangıç maliyetleri dramatik biçimde düşer. Bir araştırma ajanı daha, ikinci bir reviewer veya üç ek varyant yalnızca bir komut uzaklıktadır.

Böylece darboğaz değişir.

Kıt olan şey işi başlatmak değil, işi bitirmek, birleştirmek ve incelemek olur.

Basit bir senaryo düşünelim. Bir ajana yirmi ürün için üçer görsel varyant üretme görevi veriliyor. Subagent kullanımı nedeniyle görünüşte yönetilebilir bir talep, bir anda onlarca paralel iş akışına dönüşebilir. Her akış dosyalar, kararlar, durum mesajları ve yeni sorular üretir. Teknik olarak her şey çalışsa bile review ve entegrasyon yükü, gerçek öğrenme kazancından daha hızlı büyüyebilir.

Bu yüzden ajanik projeler birçok geleneksel dijital projeden farklı bir temel kurala ihtiyaç duyar:

Aktif ajan sayısını optimize etme. Tamamlanmış ve incelenebilir işin akışını optimize et.

Rolling Waves, Vertical Slice ve WIP Limitlerinin asıl önemi bu bağlamda ortaya çıkar.

Üç araç - üç farklı problem

Bu üç kavram kolayca birbirine karıştırılır. Oysa farklı kontrol problemlerini çözerler.

Bir proje bu alanlardan birinde güçlü, diğerlerinde zayıf olabilir.

Örneğin ekip Rolling Waves ile iyi plan yapabilir ama her dalgayı on paralel ajanla aşırı yükleyebilir. Ya da sert bir WIP limiti vardır fakat sadece yatay parçalar üretir; tek tek iyi görünen bu parçalar birlikte çalışmayabilir. Veya çok iyi bir Vertical Slice oluşturulur ama ardından tekrar altı aylık görev düzeyinde ayrıntılı plan yapılır ve ilk yeni bulguda çöken bir kesinlik illüzyonu oluşur.

Gerçek etki ancak üç yaklaşım birlikte kullanıldığında ortaya çıkar.

Rolling Waves: Daha az planlamak değil, bilginin bulunduğu yerde daha ayrıntılı planlamak

Rolling Wave Planning eksik planlamanın bahanesi değildir. Tam tersine, belirsizliğe verilen disiplinli bir cevaptır.

Temel fikir basittir. Yakın gelecek ayrıntılı planlanır. Daha uzaktaki işler daha yüksek seviyede bırakılır ve ancak yeterli yeni bilgi oluştuğunda ayrıntılandırılır.

Böylece farklı planlama ufukları ortaya çıkar:

1. Proje resmi: Hedef nedir, açıkça kapsam dışı olan nedir, hangi etki yaratılmalıdır?

2. Orta ufuk: Hangi büyük sonuç alanları, kilometre taşları veya planning package'lar muhtemelen gerekli olacaktır?

3. Mevcut dalga: Hangi somut Work-Package'lar şimdi işleniyor?

4. Sıradaki hareket: Hangi doğrudan sonraki aksiyon onaylı ve uygulanabilir?

Birçok yapay zeka proje planındaki hata, dört seviyenin de aynı anda maksimum ayrıntıyla doldurulmasıdır. Yapay zeka saniyeler içinde yüzlerce görev, rol, tarih ve bağımlılık içeren 90 günlük bir plan oluşturabilir. Biçimsel olarak etkileyicidir. Fakat bu ayrıntının büyük bölümü henüz test edilmemiş varsayımlara dayanır.

Sonuç planlama illüzyonudur: Belge kesin görünür, fakat gerçeklik henüz bu kesinliği desteklemez.

Rolling Waves, projenin başlangıçta daha az bilgiye sahip olduğunu kabul eder. Belirsizliği tabloların arkasına saklamak yerine görünür kılar.

Ayrıntı ufku bir kontrol değişkenidir

Bu nedenle önemli soru yalnızca Neyi planlıyoruz? değildir. Aynı zamanda Ne kadar ileriye kadar ayrıntılı planlıyoruz? sorusudur.

Uygun ayrıntı ufku teknik belirsizlik, değişiklik olasılığı, mevcut evidence, dış sistem bağımlılıkları, yanlış planlamanın maliyeti, yeni bilginin üretim hızı ve yaklaşan kararların geri döndürülebilirliği gibi etkenlere bağlıdır.

Stabil ve tekrar eden bir süreçte ayrıntılı ufuk daha ileriye uzanabilir. Deneysel bir ajanik prototipte gelecek hafta bile fazla uzak olabilir.

Bu, zayıf proje yönetimi değildir. Planlama çözünürlüğünün bilinçli kalibrasyonudur.

Gelecek ne kadar belirsizse, planı o kadar kaba kalabilir – yeter ki ne zaman ve hangi kanıtla ayrıntılandırılacağı belli olsun.

Progressive elaboration açık tetikleyiciler ister

Rolling Waves ancak "sonra planla" ifadesi "hiç planlama"ya dönüşmezse çalışır.

Bu nedenle her gelecekteki planlama biriminin ayrıntılandırma tetikleyicisi olmalıdır: prototip test edildi, bir slice Definition of Done'a ulaştı, temel bir varsayım doğrulandı veya yanlışlandı, maliyet aralığı netleşti, bir arayüz teknik olarak doğrulandı, dış bir paydaş karar verdi, veya bir risk eşiği aşağı çekildi.

Böylece sonraki dalga takvim refleksiyle değil, yeni bilgi temelinde planlanır.

İyi bir Wave Review şu soruları sorar:

1. Son planlamadan bu yana ne öğrendik?

2. Hangi varsayımlar artık yanlış veya daha belirsiz?

3. Hangi planning package'ları artık anlamlı biçimde bölebiliriz?

4. Neyi bilinçli olarak hâlâ kaba bırakmalıyız?

5. Sonraki dalgadan hangi işi çıkarmalıyız – yalnızca ne eklemeliyiz değil?

Özellikle beşinci soru kritiktir. Ajanik sistemler yeni optimizasyon fikirleri üretmede çok iyidir. Olgun planlama, yapmamayı da aynı ölçüde iyi öğrenmelidir.

Vertical Slice: Katman katman değil, uçtan uca etkiyi kanıtlamak

Rolling Waves zamanı yapılandırır. Vertical Slice ise kanıtı yapılandırır.

Vertical Slice, daha büyük bir sistemin küçük ama çalışan uçtan uca bölümüdür. Her şeyi yapmak zorunda değildir. Çekirdek yolun gerçekten çalıştığını göstermelidir.

Onu yatay parçalamadan ayıran budur.

Bir ekibin yapay zeka destekli danışmanlık workflow'u geliştirdiğini düşünelim. Yatay parçalama şöyle olabilir: 1. hafta veri modeli, 2. hafta prompt kütüphanesi, 3. hafta kullanıcı arayüzü, 4. hafta reviewer mantığı, 5. hafta export, 6. hafta her şeyi birleştirme.

Her katman ilerleme raporlayabilir. Fakat ekip beş hafta boyunca toplam akışın gerçekten taşıyıp taşımadığını bilmez.

Vertical Slice ise çok küçük bir uçtan uca yol oluşturur:

tek bir gerçek talep → tanımlı input → KI elaboration → review → görünür sonuç → export.

Belki bu slice yalnızca tek bir use case için çalışır. Sorun değil. Değeri genişlikte değil, taşınabilirlik kanıtında yatar.

Slice, çalıştırılabilir bir hipotezdir

İyi bir Vertical Slice yalnızca "Kod çalışıyor mu?" sorusunu cevaplamaz. Bir proje hipotezini test eder.

Örneğin:

Bu tam çekirdek akışı gerçekçi input ile çalıştırırsak, hedeflenen kalite, zaman ve maliyet çerçevesinde kullanılabilir bir sonuç üretebilir miyiz?

Böylece slice bir öğrenme aracına dönüşür.

Teknik soruları yanıtlayabilir: Arayüz güvenilir biçimde çağrılabiliyor mu? Model kalitesi yeterli mi? Export çalışıyor mu?

Organizasyonel soruları da yanıtlayabilir: Review yükü sürdürülebilir mi? İnsan output'u anlayabiliyor mu? Fazla rework oluşuyor mu? Gerçek kullanıcı için akış mantıklı mı?

Ekonomik sorular da vardır: Gerçek runtime ve token maliyeti nedir? Ne kadar insan zamanı gerekli kalıyor? Fayda, daha fazla geliştirmeyi haklı çıkaracak kadar büyük mü?

Bu nedenle slice, "tüm backlog'un küçük versiyonu" olarak anlaşılmamalıdır. O, uçtan uca sorumluluğu olan hedefli bir deneydir.

Slice Contract mini-monolitleri engeller

Vertical Slice da kontrolsüz büyüyebilir. "Bir çekirdek akışı test ediyoruz" hızla "madem buradayız login, dashboard, analytics ve üç rol modeli de ekleyelim"e dönüşebilir.

Buna karşı Slice Contract kullanışlıdır.

En önemli alan çoğu zaman Non-Scope olur. O olmadan Vertical Slice kolayca minyatür bir tam ürüne dönüşür ve öğrenme fonksiyonunu kaybeder.

Doğru slice boyutu trivial ile incelenemez arasında bulunur

Bir slice fazla küçük olabilir.

Yalnızca bir ajanın metin üretebildiğini kanıtlıyorsa çok az şey öğreniriz. Gerçek entegrasyon riskleri görünmez kalır.

Fazla büyük de olabilir.

Bir slice altı hafta, on iki tool ve elli alt görev gerektiriyorsa hangi varsayımın önce çöktüğünü çok geç öğreniriz.

Bu nedenle iyi slice boyutu tamamlanan özellik miktarını değil, öğrenme kazancı / çaba oranını maksimize eder.

Şu sorular yardımcı olur: Küçük bir uçtan uca yol ile hangi en büyük belirsizliği görünür kılabiliriz? Hangi arayüz projeyi ileride bloke edebilir? Hangi varsayım üç ay sonra yanlışlanırsa çok pahalı olur? Gerçekte gözlemleyebileceğimiz minimum kullanıcı etkisi nedir? Bu slice sonrasında hangi kararı öncesine göre daha iyi verebiliriz?

Böylece parçalama bir öğrenme tasarımına dönüşür.

WIP Limitleri: Başlatılmış iş bir stoktur

Vertical Slice neyi kanıtlayacağımızı söyler. WIP Limitleri ise bunun ne kadarının aynı anda açık olabileceğini belirler.

WIP, Work in Progress demektir – başlatılmış ama henüz tamamlanmamış iş.

Bilgi işinde başlatılmış iş kolayca görünmez olur. Açık browser tablarında, agent run'larında, branch'lerde, chat'lerde, review queue'larında, taslak dosyalarda ve yarım analizlerde bulunur. Ajanik sistemler bu problemi büyütür çünkü yeni işi çok hızlı üretebilirler.

WIP Limit bunu açık bir kapasite kararına dönüştürür.

Örneğin: maksimum 2 aktif slice, maksimum 3 açık araştırma paketi, maksimum 1 release edilmemiş teknik branch, aynı anda review bekleyen maksimum 4 sonuç, dış tool haklarına sahip maksimum 2 paralel agent run.

Somut sayılar bağlama göre değişir. Mantık daha geneldir:

Yeni iş yalnızca gerçek kapasite boşaldığında pull edilir.

Push ile pull arasındaki fark budur.

WIP yalnızca çalışan ajan sayısı değildir

Ajanik projelerde yalnızca aktif ajan sayısını sınırlamak fazla basit olur.

Tek bir ajan on açık alt görev oluşturabilir. Tersine, beş ajan tek bir net sınırlı slice üzerinde birlikte çalışabilir.

Bu nedenle WIP birden fazla seviyede düşünülmelidir:

Bu bakış yaygın bir hatayı önler: Ekip aktif ajan sayısını azaltır ama sistemde yirmi açık Work-Package bırakır. Darboğaz devam eder.

WIP Limit testi: Sistem açık olan her şeyi gerçekten bitirebilir mi?

Kullanışlı bir WIP Limit, ne kadar işin başlatılabileceğine göre değil, ne kadar işin güvenilir biçimde bitirilebileceğine göre belirlenir.

Beş soru özellikle yararlıdır:

1. Bir zaman biriminde kaç sonucu gerçekten ciddi biçimde review edebiliriz?

2. Kaç paralel akışı proje state'i içinde tutarlı tutabiliriz?

3. Sürekli context switching olmadan kaç açık bağımlılığı koordine edebiliriz?

4. Aynı anda ne kadar maliyet ve token tüketimini kabul ediyoruz?

5. Bir akış bloke olduğunda veya anlamsızlaştığında bunu ne kadar hızlı fark ediyoruz?

Bu sorulardan herhangi birinin cevabı "güvenilir değil" ise mevcut WIP muhtemelen fazladır.

Kontrollü paralellik maksimum paralellik değildir

Paralellik yine de önemlidir. Dört bağımsız kaynak araştırması aynı anda mantıklı biçimde çalışabilir. İki bağımsız test varyantı da öyle.

Sorun, iş yalnızca görünüşte bağımsız olduğunda başlar.

Tipik gizli bağlar şunlardır: tüm ajanlar aynı kararsız baseline'a ihtiyaç duyar, birden fazla akış aynı dosyalara yazar, tüm sonuçları aynı insan review etmek zorundadır, sonraki merge yol boyunca kaybolabilecek bilgilere bağlıdır, A akışındaki karar B akışının varsayımlarını değiştirir, veya tüm ajanlar aynı sınırlı tool / token havuzunu tüketir.

Kontrollü paralellik bu nedenle bir bağımlılık sorusuyla başlar:

Hangi iş gerçekten bağımsız olarak bitebilir – hangisi yalnızca paralel kuyruklar oluşturur?

Amaç tüm kaynakları yüzde yüz kullanmak değildir. Amaç toplam flow'u iyileştirmektir.

Utilization başarı metriği değildir

Bu ilk bakışta mantığa aykırı gelebilir. Ajanlar ucuz ve hazırsa neden sürekli çalışmasınlar?

Çünkü maksimum utilization çoğu zaman maksimum kuyruk üretir.

Her ajanın sürekli yeni bir şey başlattığı proje hızla şunları üretir: daha fazla açık sonuç, daha fazla review ihtiyacı, daha fazla context switching, daha fazla merge conflict, daha fazla eskimiş ara durum, artık öncelikli olmayan daha fazla iş.

Ajanik productivity bu nedenle "agent saatleri" veya "üretilen artefact sayısı" ile ölçülmemelidir.

Daha iyi sorular şunlardır: Gerçekten kaç değerli work item tamamlanıyor? Başlatılmış item'lar ne kadar süre açık kalıyor? Ne kadar rework oluşuyor? Kaç output kullanılmadan çöpe gidiyor? Bir sonraki savunulabilir proje kararına ne kadar hızlı ulaşıyoruz?

Daha çok bitir. Daha az başlat.

Gösterişli değildir. Ajanik sistemlerde radikal bir kontrol kuralıdır.

Work-Package'lar insan tarafından anlaşılabilir şekilde bitmelidir

Küçük iş paketlerinin bir başka avantajı anlaşılabilirliktir.

Bir ajan saatlerce otonom çalışıp sonunda yalnızca devasa bir final state gösterirse inceleme problemi doğar. İnsan sonucu görür ama oraya hangi varsayım, değişiklik ve kararlarla gelindiğini güvenilir biçimde takip edemez.

Bu nedenle her önemli Work-Package kısa bir completion report ile bitmelidir.