Sprint planlama her zaman sessiz bir varsayıma dayanmıştır: kapasite, sahip olduğunuz kişi sayısının zaman kutusuyla çarpımıdır. İşi tahmin edersiniz, ekibin son döngüde tamamladıklarıyla karşılaştırırsınız ve sığan bir kapsam için taahhüt verirsiniz.
Ekibe AI coding Agent'ları eklediğinizde ise denklem gerçekliği tanımlamayı bırakır. Bir Agent, bir Task hazır olduğu anda onu üstlenebilir, diğer tüm Agent'larla paralel çalışabilir ve siz onu konuşmayı planladığınız standup'tan önce bir diff ve test sonuçlarıyla geri dönebilir. Yürütme kapasitesi çarpıcı biçimde şişer. Cazip gelen yanıt daha fazla kapsam taahhüt etmektir ve bunu yapan ekipler genellikle başarısızlık modunu ilk döngünün sonunda keşfeder: Sprint, bol miktarda bitmiş kod ve kimsenin kabul etmeye vakti olmadığı bir duvar dolusu incelenmemiş değişiklikle kapanır.
Bu yazının ortaya koyduğu argüman şudur: ekipte Agent'lar varken yürütme artık Sprint kısıtı olmaktan çıkar ve insan incelemesi Sprint kısıtı haline gelir. Planlamayı ne kadar kod üretilebileceğine göre değil, kabul kapasitesine göre yapın. Somut mekanizma olarak Sharkly'deki Sprint'leri kullanacağız ve planlama argümanını ürün gerçeklerinden net biçimde ayrı tutacağız.
TL;DR
Sharkly'de bir Sprint, tek bir Space'e ait, zaman kutulu bir Task kümesidir; Task'lar yürütmenin ve tartışmanın kaynağı olarak kalırken Sprint bunların üzerine takvim, kapsam ve raporlama ekler. Sprint'ler isteğe bağlıdır ve iki moddan birinde çalışır: takvimi Sharkly'nin yönettiği ve tamamlanmamış işi ileriye taşıdığı Otomatik tempo ya da Sprint'leri açıkça Kişilerin oluşturduğu, başlattığı ve tamamladığı Manuel mod. Raporlama; kapsamı, başlatılan ve tamamlanan işi, tamamlanma oranını, kapasiteyi ve burnup geçmişini kapsar. İnsan-Agent karma ekipler için planlama kayması şudur: Agent'lar yürütme kapasitesini şişirir ama kabul etme işi Kişilerde kalır; dolayısıyla dürüst Sprint taahhüdü, Agent'larınızın ne kadar üretebileceğiyle değil, inceleyicilerinizin ne kadar bitmiş işi kabul edebileceğiyle sınırlıdır.
Sharkly'de Sprint nedir
Sprint tek bir Space'e ait, zaman kutulu bir Task kümesidir. Bir ekibin odaklanmış bir kapsam planlamasına, ilerlemeyi takip etmesine ve zaman kutusu bittiğinde tamamlanmamış işe ne olacağına karar vermesine yardımcı olur. Task'lar yürütmenin ve tartışmanın kaynağı olarak kalır; bir Sprint bunların üzerine takvim, kapsam ve raporlama ekler.
Dokümantasyon Sprint terimini kullanıyor ve bu terim sektörde ne anlama geliyorsa onu ifade ediyor. Scrum Guide, Sprint'leri fikirlerin değere dönüştüğü sabit uzunlukta kaplar olarak tanımlar ve Sharkly'nin sürümü de bu soyu korur. Sharkly'nin değiştirdiği şey, bu pencere içinde yürütmeyi kimin yaptığıdır.
Kavramı temiz tutan üç sınır var:
- Bir Sprint tam olarak tek bir Space'e aittir. Bir Task'ı bir Sprint'e koymak onun sahipliğini değiştirmez.
- Sprint'ler isteğe bağlıdır ve Space bazında etkinleştirilir. Sürekli akışla düşünen bir Space bunları hiç açmayabilir.
- Bir Sprint ne bir Project'tir ne de bir View. Soru, belirli bir zaman kutusunda neyin tamamlanması gerektiğiyse Sprint kullanın. Birkaç Sprint'e veya Space'e yayılabilecek bir sonuç için Project kullanın. Task'ları incelemek için kaydedilmiş bir yol istiyorsanız View kullanın.
Bu son ayrım karma bir ekipte gerçek anlam taşır: sonucu Project tutar, yakın vadeli taahhüdü Sprint tutar ve View'lar her kişinin gündelik olarak ihtiyaç duyduğu dilimleri tutar.
Otomatik tempo mu, Manuel mod mu
Bir Space için Sprint'leri etkinleştirdiğinizde iki yaşam döngüsü modundan birini seçersiniz. Bu seçim yaşam döngüsü davranışını değiştirir, Task sahipliğini değiştirmez.
Otomatik tempo takvimi Sharkly'ye teslim eder. Sprint süresini, isteğe bağlı bir bekleme süresini (cooldown), başlangıç gününü, kaç gelecek Sprint'in korunacağını, saat dilimini ve seçili durum kategorilerine girdiklerinde Task'ları otomatik olarak ekleyen kuralları yapılandırırsınız. Sharkly ardından gelecek Sprint'leri oluşturur, zamanında başlatıp tamamlar ve tamamlanmamış işi ileriye taşır. Yaklaşan bir Sprint'i erken başlatmak önce mevcut olanı tamamlar ve tamamlanmamış işini başlatılan Sprint'e aktarır.
Manuel mod yaşam döngüsü kontrolünü ekipte bırakır. Kişiler gerektiğinde planlanmış Sprint'ler oluşturur, yapılandırılmış tarihlerini değiştirmeden onları başlatır, aynı anda birden fazla aktif Sprint çalıştırır ve tamamlandığında tamamlanmamış Task'ların nereye gideceğini seçer. Manuel modda otomatik oluşturma, devretme, bekleme süresi ve durum tabanlı ekleme kuralları etkin kalmaz.
| Automatic cadence | Manual mode | |
|---|---|---|
| Takvim | Sharkly, Sprint'leri yapılandırılmış bir ritimle oluşturur, başlatır ve tamamlar | Kişiler Sprint'leri açıkça oluşturur, başlatır ve tamamlar |
| Tamamlanmamış iş | Otomatik olarak bir sonraki Sprint'e aktarılır | Tamamlanmada yönlendirilir: Sprint yok, başka bir Sprint veya yeni bir Sprint |
| Paralel aktif Sprint'ler | Tempo başına bir güncel Sprint | Birden fazla aktif Sprint'e izin verilir |
| Task girişi | Durum kategorisi kuralları pencere sırasında Task ekleyebilir | Task'lar Kişiler tarafından planlama, listeler veya Sprint alanı üzerinden eklenir |
| En uygun olduğu durum | Ekibin tören olmadan sürdürülmesini istediği istikrarlı bir tempo | Düzensiz döngüler, sürüm odaklı pencereler veya örtüşen çalışmalar |
Dürüst karar ikilisi: ekibiniz istikrarlı bir ritimle çalışıyorsa ve mekaniğin kendileri adına sürdürülmesini istiyorsa Otomatik tempoyu kullanın. Döngüleriniz düzensizse, pencerelerinizi takvimler değil sürümler tanımlıyorsa ya da aynı anda iki aktif Sprint'e ihtiyaç duyuyorsanız Manuel'i kullanın. Manuel'e geçmek mevcut Sprint'leri korur ama otomatik planlamayı durdurur. Sprint'leri tamamen devre dışı bırakmak aktif olanları tamamlar, gelecekte olanları kaldırır ve raporlama için tamamlanmış verileri saklar.
Task'lar Sprint'lere nasıl girer, çıkar ve atlar
Sprint'ler beş görüntüleme durumunda görünür: Current, Upcoming, Planned, Completed ve Canceled. Tamamlanmış ve iptal edilmiş Sprint'ler, aktif planlama listesini kalabalıklaştırmak yerine Space arşivine taşınır.
Bir Task'ı Sprint alanı üzerinden, bir Task listesinden veya Sprint planlaması sırasında ekler ya da taşırsınız. İki kural göründüğünden daha önemlidir.
Birincisi, bir Task'ın hiç Sprint'i olmayabilir. Bu, Backlog işleri ve herhangi bir zaman kutusuna taahhüt edilmemiş Task'lar için normal durumdur.
İkincisi, bir Task'ı bir Sprint'e eklemek durumunu değiştirmez. Bu, karma ekiplerin içselleştirmesi gereken kuraldır; çünkü Sharkly'de Backlog durum kategorisi bir park durumudur: Task Backlog'da dururken bir Task oluşturmak veya bir Agent atamak yürütmeyi başlatmaz. Task'ı Backlog'dan çıkarıp hazır bir duruma taşımak, atanmış Agent'ı başlatabilir. Yani Sprint planlaması ile yürütmenin serbest bırakılması iki ayrı koldur. Pazartesi günü tüm Sprint'i planlayabilir, Agent'ları şimdiden atayabilirsiniz ve her Task kasten hazır bir duruma taşınana kadar hiçbir şey çalışmaz. Durum değişikliği Automation'ları ardından standartlaştırmak istediğiniz geçişleri üstlenebilir.
Bir kural daha geçmişinizi korur: önceki bir Sprint'e yalnızca tamamlanmış Task'lar eklenebilir. Bu, tamamlanmamış işi hiçbir zaman kapanmış bir döneme koymadan geçmişe dönük düzeltmeye olanak tanır.
Tarihler açısından, planlanmış bir Sprint'in hem başlangıcı hem bitişi düzenlenebilir; aktif bir Sprint'in başlangıcı sabittir ama bitişi değiştirilebilir.
Sprint raporlaması size ne söyler
Sprint raporlaması Task sayılarını ve Space'te tahminler etkinse altı ölçüm genelinde tahmin puanı toplamlarını içerir: kapsam, başlatılan iş, tamamlanan iş, tamamlanma oranı, kapasite ve burnup geçmişi.
Kapasite daha yakından bakmayı hak ediyor çünkü planlama konuşmalarının demir attığı sayı odur. Sharkly bunu, yeterli geçmiş varsa son tamamlanan Sprint hızından türetir; aksi halde Space büyüklüğüne dayalı bir tahmine geri döner. Dokümantasyon, bunun bir garanti değil planlama girdisi olarak ele alınmasını söylüyor ve karma bir ekip için bu uyarı kalıplaşmış bir ifade değil: yalnızca insanlardan oluşan bir grupta ölçülen hız, üç Agent eklediğiniz hafta hiçbir şeyi öngörmeyi bırakır. Burnup geçmişi genellikle daha çok şey anlatır. Kapsam erken bir patlamayla tamamlanıp sonra çizgi düzleşiyorsa, Agent'larınız yürütmeyi bitirmiş ve inceleyicileriniz Sprint'in geri kalanını yetişmekle geçirmiştir.
Karma ekip kısıtı: yürütme için değil, inceleme için planlayın
Bu bölümdeki her şey bir planlama argümanıdır, bir ürün özelliği değil. Sharkly size yukarıdaki Sprint mekaniklerini verir; Sprint'i nasıl yükleyeceğiniz bir muhakeme kararıdır.
İş bölümünden başlayın. Agent'lar araştırır, yürütür, test eder ve raporlar. Kişiler yön belirler, yetki verir ve sonucu kabul eder. Agentic coding'de yön belirleme ile kabul arasındaki her şey devredilebilir ama kabul insanda kalır. Bir Task'ı bitiren bir Agent, Sprint'inizin sayması gereken hiçbir anlamda onu bitirmiş olmaz: diff, doğrulama sonuçları ve bilinen sınırlar Task'a geri döner ve bir kişi hâlâ bunları okuyup kabul etmek, değişiklik istemek ya da merge'e karar vermek zorundadır.
Şimdi hesabı yapalım. Beş kişilik bir ekibin Agent'lar eklediğini ve yürütme veriminin üçe katlandığını varsayalım. İnceleme verimi üçe katlanmadı; onu aynı beş kişi yürütüyor ve kabul edilen her değişiklik gerçek bir dikkat maliyeti getiriyor. Sprint'i yürütme kapasitesine göre planlarsanız, artan kısım sevk edilmiş değere dönüşmez. İncelenmemiş işlerden oluşan bir kuyruğa dönüşür ve incelenmemiş bir değişiklik ilerleme değil stoktur. Daha kötüsü, kapanmakta olan bir Sprint inceleyicileri Agent yoğun geliştirmeyi tehlikeli kılan tam da o kestirmeye iter: çıktıyı okumadan kabul etmek.
Öyleyse planlama sorusunu tersine çevirin. Ekip iki haftada ne kadar iş yürütebilir diye sormak yerine, Kişileriniz iki haftada ne kadar bitmiş Agent işini kabul edebilir diye sorun. Pratikte bu dört alışkanlığı değiştirir:
- Yalnızca üretim maliyetini değil, inceleme maliyetini de tahmin edin. Bir Agent için yürütmesi önemsiz olan bir Task'ın kabul edilmesi yine de pahalı olabilir.
- Aynı anda tamamlanmış ama kabul edilmemiş işe bir üst sınır koyun. Her inceleyicinin Sprint başına gerçekten kaç Task kabul edebileceğine karar verin ve toplamın ötesini planlamayı bırakın. Bu bir Sharkly ayarı değil, bir çalışma anlaşmasıdır; yine de tamamlanma metrikleri aştığınızı size söyleyecektir.
- Yürütmeyi bilinçli olarak serbest bırakın. Backlog yürütmeyi park ettiği için başlangıçları kademelendirebilirsiniz; böylece bitmiş iş, ikinci gün hepsi birden gelmek yerine inceleyicilerin sindirebileceği bir hızda ulaşır.
- Tamamlanma oranını bir inceleme sayısı olarak okuyun. Agent'lar boş beklerken burnup düzleşiyorsa kısıt kendini duyurmuş demektir. Bu, Agent eklemek için değil, inceleyici eklemek ya da daha az taahhüt etmek için bir işarettir.
Bunların hiçbiri Agent'ları yavaşlatmaz. Onları hedefe yöneltir. Kabul kapasitesi etrafında planlanan bir Sprint, taahhüt ettiği her şeyi sevk eder ve hiçbir zaman bir kişiden okumaya vakti olmadığı kodu onaylamasını istemez.
Karma bir Sprint'i adım adım planlamak
- Space için Sprint'leri etkinleştirin ve bir mod seçin. İstikrarlı bir ekip ritmi Otomatik tempoyu, sürüm odaklı iş ise Manuel'i işaret eder.
- Kapsamı şekillendirin. Aday Task'ları Sprint planlaması veya Sprint alanı üzerinden yaklaşan Sprint'e çekin. Taahhüt edilmemiş işi Sprint'siz bırakın.
- Her Task'ın iki yarısını da atayın. Sharkly, insan sorumluluğunu Agent yürütmesinden ayırır: Kişiler atananlar kümesine girer, bir Agent veya Crew ise tek yürütme yuvasına girer. Birini değiştirmek diğerini asla değiştirmez.
- Bir Agent'ın üzerinde işlem yapabileceği Task'lar yazın. Açıklama, yeni bir kişinin veya Agent'ın ilerlemek için ihtiyaç duyacağı hedefi, kısıtları ve kabul kriterlerini taşımalıdır.
- İşi inceleme hızında serbest bırakın. İnceleyici kapasitesi boşaldıkça Task'ları Backlog'dan çıkarın.
- Kapanışı bilinçli yapın. Manuel modda her tamamlanmamış Task'ın nereye gideceğini seçin. Otomatik tempoda neyin ileriye taşındığını kontrol edin ve kapsamının çok mu büyük tutulduğunu yoksa çok mu yavaş incelendiğini sorgulayın.
İşi bu şekilde yürütmenin daha geniş disiplini, AI agent project management konulu ana yazımızda ele alınıyor; Sprint bu sistemin zaman kutulu dilimidir.
Sprint'leriniz bugün Jira'da yaşıyorsa
Bunların herhangi birini denemek için sürecinizi baştan kurmak zorunda değilsiniz. Sharkly'nin Jira entegrasyonu Jira Sprint verilerini içe aktarabilir ve Sprint içe aktarma etkinleştirildiğinde hedef Space, Jira Sprint moduna geçirilebilir; böylece ekibinizin hâlihazırda yürüttüğü tempo sıfırdan başlamak yerine olduğu gibi taşınır. Bir Jira ticket'ını bir AI Agent'a atama konulu adım adım anlatım aynı fikri tek ticket düzeyinde gösteriyor ve Sharkly dokümantasyonu Sprint yapılandırmasını ve Jira entegrasyonunu derinlemesine ele alıyor.
Bir geçişten daha küçük başlayın: bir Space'te Sprint'leri etkinleştirin, inceleyicilerinizin gerçek kabul kapasitesine göre iki haftalık tek bir pencere planlayın ve burnup'ı son yalnızca insanlı döngünüzle karşılaştırın.
SSS
Sharkly'de Sprint'leri kullanmak zorunda mıyım?
Hayır. Sprint'ler isteğe bağlıdır ve Space bazında etkinleştirilir. Sürekli akışı tercih eden bir Space bunları tamamen kapalı bırakabilir ve Sprint'ler etkin olsa bile bir Task'ın hiç Sprint'i olmayabilir; bu, Backlog işleri için normal durumdur.
Bir Sprint bittiğinde tamamlanmamış Task'lara ne olur?
Otomatik tempoda Sharkly, Sprint'i zamanında tamamlar ve tamamlanmamış işi bir sonrakine taşır. Manuel modda tamamlama akışı, tamamlanmamış Task'ların nereye gitmesi gerektiğini sorar: Sprint'siz, başka bir aktif veya yaklaşan Sprint'e ya da yeni oluşturulmuş bir Sprint'e.
Agent'lar Sprint Task'ları üzerinde otomatik çalışabilir mi?
Bir Task'ın yürütme atananı olarak ayarlanmış bir Agent veya Crew işi çalıştırabilir ama tek başına Sprint üyeliği hiçbir şeyi başlatmaz. Backlog bir park durumudur; bu yüzden bir Backlog Task'ına Agent atamak yürütmeyi başlatmaz; çalıştırmayı başlatabilecek olan, Task'ı hazır bir duruma taşımaktır. Bu ayrım, önce tam bir Sprint planlamanıza ve yürütmeyi inceleyicilerinizin sindirebileceği hızda serbest bırakmanıza olanak tanır.
Sharkly Sprint kapasitesini nasıl hesaplar?
Kapasite, yeterli geçmiş varsa son tamamlanan Sprint hızını kullanır; aksi halde Space büyüklüğüne dayalı bir tahmine geri döner. Dokümantasyon, bunun bir garanti değil planlama girdisi olarak ele alınmasını öneriyor; bu, hızın içindeki inceleme darboğazını değil tüm sistemi ölçtüğü karma ekipler için iki kat önemlidir.
Zaten bitmiş bir Sprint'e Task ekleyebilir miyim?
Önceki bir Sprint'e yalnızca tamamlanmış Task'lar eklenebilir. Bu, pencere içinde bitirilmiş ama hiç kaydedilmemiş işi hesaba katmak gibi geçmişe dönük düzeltmeleri destekler ve tamamlanmamış işi hiçbir zaman kapanmış bir döneme koymaz.
