Backlog'unuz Jira'da yaşıyor. Kimse onu yerinden kıpırdatmıyor. Epic'ler orada duruyor, sprint raporları yönetime gidiyor ve başka üç ekip bu iş öğesi kimliklerine bağımlı. Dolayısıyla biri bir AI kodlama agent'ının JIRA-4821'i alıp almaması gerektiğini sorduğunda, soru "Jira'nın yerini almalı mıyız" değil. Soru daha dar ve daha pratik: agent gerçekte nerede çalışacak, ürettiğini kim inceleyecek ve bunların herhangi biri ticket'a geri dönecek mi?
Gerçek karşılaştırma bu. Jira'nın artık agent'ları var ve çalışıyorlar. Sharkly da agent'ları çalıştırıyor; hem de sizin bağladığınız bilgisayarlarda, sonucu da Jira'ya geri senkronize ediyor. Bu rehber, Sharkly eklemenin gereksiz olacağı durumlar dahil, ikisi arasındaki çizgiyi dürüstçe çiziyor.
Özet
Jira, üzerine agent yürütme yeteneği eklenmiş bir kayıt sistemidir. Sharkly ise sizin kayıt sisteminize bağlanan bir yürütme katmanıdır. Atlassian'ın Rovo Dev'i planlama, kodlama ve incelemeyi Atlassian ortamları içinde yürütür; iş öğelerini de atanan kişi açılır menüsünden agent'lara atayabilirsiniz. Sharkly, ekibinizin zaten ödeme yaptığı herhangi bir Runtime'ı bağladığınız Computer'larda çalıştırır, yürütme trace'ini paylaşılan bir Task üzerinde tutar ve Jira Cloud, Server veya Data Center ile çift yönlü senkronize olur. Agent işleriniz Atlassian'ın desteklediği ortamlara sığıyorsa Jira tek başına yeterli. Agent'larınızın kendi makinelerinizde, kendi runtime'larınız ve kendi inceleme sürecinizle çalışması gerekiyorsa Sharkly bu katmanı Jira'yı devre dışı bırakmadan ekler.
Jira'nın iyi yaptığı işler, açıkça
Jira'ya en iyi halini teslim edin, çünkü dürüst olan hali zaten güçlü.
Jira, bir şirketin hangi işlerin var olduğu konusunda anlaştığı yerdir. Bu uzlaşmanın gerçek değeri var: ortak kimlikler, izin modelleri, denetim geçmişi ve finans ile yönetimin hâlihazırda okuduğu raporlar. Bir ekipten bunu bırakmasını isteyen her araç, pahalı bir şey istiyor demektir.
Atlassian da agent'lar konusunda hareketsiz kalmadı. Rovo Dev, Atlassian tarafından "planlamayı, kodlamayı ve incelemeleri üstlenerek ve tekrarlayan işleri ölçekli biçimde otomatikleştirerek yazılım geliştirme yaşam döngüsünü hızlandıran, bağlam farkındalığına sahip bir AI agent'ı" olarak tanımlanıyor. Jira'daki kabul kriterlerine göre kod değişikliklerini doğruluyor ve terminal CLI, Bitbucket Cloud, GitHub ile VS Code ortamlarında çalışıyor. Atlassian'a göre Rovo Dev Standard, tüm yeni ve mevcut müşteriler için genel kullanıma açık ve Standard, Premium ile Enterprise Cloud planlarında aylık krediler kullanıma sunuluyor.
Atama modeli gerçekten iyi. Bir iş öğesinde atanan kişi açılır menüsünü açıp tıpkı bir iş arkadaşını seçer gibi bir agent seçiyorsunuz ve bu listede GitHub Copilot kodlama agent'ı gibi üçüncü taraf agent'lar da yer alıyor. Atlassian'ın kendi mühendislik ekibi, Jira'da Rovo Dev kullanarak iki haftada 120 PR teslim ettiklerini anlatan bir yazı yayımladı. Bu bir demo rakamı değil. Bir ekibin gerçek iş üzerindeki verimini raporlaması.
Yani başlangıç noktası "Jira geride kaldı" değil. Başlangıç noktası şu: "Jira'nın bir yanıtı var ve bu yanıtın tam olarak neyi kapsadığını bilmelisiniz."
Jira'nın yanıtının bittiği yer
Sınır, yürütmenin nerede gerçekleştiği ve hangi araçlara erişebildiğiyle ilgili.
Jira'ya özgü agent yürütmesi, Atlassian'ın desteklediği ortamların içinde yaşar. Bu bilinçli bir tasarım tercihi ve pek çok ekip için de doğru olanı. Ayrıca runtime sorusunun sizin adınıza yanıtlandığı anlamına geliyor. Geliştiricileriniz belirli bir Skills kurulumuyla Claude Code üzerinde, bir ChatGPT aboneliği üzerinden Codex'te, Gemini CLI'da, OpenCode'da ya da özel bir protokol üzerine kendi geliştirdiğiniz bir şeyde standartlaştıysa, Jira'ya özgü yol bunları geliştiricilerinizin yerelde çalıştırdığı şekilde çalıştırmaz.
Çoğu karşılaştırmanın kabul etmek istemediğinden daha önemli ikinci bir sınır var: makine. Agent işi sadece bir model çağrısı değildir. Bir checkout, bir paket yöneticisi, ortam değişkenleri, yerel bir veritabanı, staging API'nize giden VPN yolu ve repo'nuzun dizüstü bilgisayarınızda derlenip genel bir container'da derlenmemesine neden olan yirmi küçük şey gerekir. Ekipler bununla ilk haftada değil, ikinci haftada karşılaşıyor.
Bir de inceleme sorunu var. Bir agent bir değişiklik ürettiğinde işe yarayan çıktı yalnızca pull request değildir. Asıl çıktı trace'tir: agent'a ne söylendi, neyi okudu, neyi denedi, nerede tıkandı ve bir insan bunun hakkında ne karar verdi. Bu kaydın, bir sonraki kişinin okuyabileceği bir yuvaya ihtiyacı var.
İki karar senaryosu
Sharkly'nin kendi dokümantasyonu iş bölümü konusunda lafını sakınmıyor; burada da aynı netlik geçerli.
Jira'yı tek başına kullanın, eğer agent işleriniz Atlassian'ın desteklediği ortamlara sığıyorsa, repo'larınız Bitbucket veya GitHub'daysa ve istediğiniz agent'lar Jira'nın hâlihazırda atayabildikleri ise. Tek bir üründe hem kayıt sisteminiz hem de yürütme yolunuz olur, tek faturayla. Başka bir katman eklemek size ihtiyacınız olmayan bir karmaşıklık kazandırır. Bu bir kaçamak değil, gerçek bir tavsiye.
Sharkly'yi ekleyin, eğer yürütmenin sizin kontrol ettiğiniz donanımda ve runtime'larda gerçekleşmesi gerekiyorsa. Sharkly'de bir Computer, Agent işleri için yürütme ana makinesi sağlar; bu yerel bir bilgisayar, uzak bir sunucu, bir container veya desteklenen bir bulut sunucusu olabilir. Küçük bir yerel servis o Computer'ı Sharkly'ye bağlar, mevcut Runtime'ları algılar, işi alır, görev dizinini hazırlar, seçilen Runtime'ı başlatır ve ilerlemeyi geri akıtır. İşte Jira'nın olmaya çalışmadığı parça bu.
Bir tanım yerinde olur, çünkü geri kalan her şey buna dayanıyor. Task, Sharkly'deki ana iş birimidir. Hedefi ve açıklamayı, sorumlu kişiyi, yürütmekle görevlendirilen Agent'ı veya Crew'yi, yorumları, yürütme durumunu, trace'i ve sonucu barındırır. Bir Jira issue'ı işin var olduğunu kaydederken, bir Sharkly Task'ı işin nasıl ve hangi agent tarafından hangi makinede yapıldığını kaydeder.
Seçim yapmak zorunda değilsiniz: senkronizasyon yolu
Çoğu "Sharkly vs Jira" kurgusunun yanlış anladığı kısım burası. İkisi birbirini dışlamıyor ve entegrasyon hayal ürünü değil, belgelenmiş durumda.
Sharkly'nin Jira entegrasyonu Jira Cloud ile Jira Server veya Data Center'ı destekliyor ve üç mod sunuyor:
- Import, mevcut Jira verilerini Sharkly'ye kopyalar. Geçmiş işler veya kontrollü bir geçiş için kullanın.
- Sync, bir Jira projesini bir Sharkly Space'ine bağlar ve son değişiklikleri bağlantılı tutar. Sync tek başına geçmiş verileri içeri aktarmaz.
- Import and then sync, seçilen geçmişi aktarır ve sihirbazda zaten girilmiş kimlik bilgileriyle sürekli senkronizasyonu etkinleştirebilir.
Bir sync bağlantısı, bir Jira projesini bir Sharkly Space'iyle eşleştirir. Bir Jira projesinin yalnızca bir aktif bağlantısı olabilir, ancak birden çok Jira projesi aynı Space'e bağlanabilir. Çift yönlü modda Jira issue'ları ve epic'leri, Sharkly Task'ları ve Project'leriyle her iki yönde senkronize olur; bağlı Space'te oluşturulan yeni Task'lar ve Project'ler Jira issue'ları ve epic'leri oluşturabilir. Jira'yı otorite olarak korumayı tercih ederseniz, Jira'dan Sharkly'ye modu yeni kayıtları geri göndermeden bağlantılı Sharkly kayıtlarını oluşturur ve günceller.
Başlamadan önce bilmeye değer iki operasyonel not var. Otomatik webhook kurulumu Jira yönetim izni gerektirir; webhook izninin eksik olması bağlantıyı engellemez ama Jira'daki değişikliklerin gelmesini durdurur. Bir bağlantıyı silmek, iki tarafta da hiçbir şeyi silmeden gelecekteki senkronizasyonu durdurur; bu da vazgeçmeye karar verirseniz süreci geri döndürülebilir kılar.
Ticket düzeyindeki iş akışı için, bir Jira ticket'ını bir AI agent'ına atama rehberimiz döngüyü baştan sona ele alıyor.
Örnek bir senaryo
Bir ödeme ekibi, şirket standardı olarak Jira kullanıyor. Destek ekibi JIRA-4821'i açıyor: bir webhook yeniden deneme fırtınası az sayıda müşteriden çift ücret alınmasına yol açıyor.
Teknik lider bunu Jira'da değerlendiriyor, önceliği belirliyor ve olay epic'ine bağlıyor. Bağlı Space çift yönlü senkronize olduğu için aynı iş, açıklaması ve kabul kriterleri bozulmadan Sharkly'de bir Task olarak görünüyor.
Yönlendirme tam da burada netleşiyor. Task, backend düzeltmeleri için yapılandırılmış bir Agent'a gidiyor: tanımlı bir rol, ödeme repo'su ve Runtime olarak Claude Code; üstelik staging kimlik bilgileri ile VPN yoluna zaten sahip bağlı bir Computer üzerinde çalışıyor. İkinci bir Agent, izole bir worktree'de test kapsamını yönetiyor; böylece ikisi asla aynı dosyalara dokunmuyor. İzole worktree'lerde paralel agent'lar çalıştırma rehberimiz, birden fazla agent devrede olduğunda bu izolasyonun neden önemli olduğunu ayrıntılı olarak anlatıyor.
Agent issue'yu okuyor, yeniden deneme fırtınasını yerel bir replay üzerinde yeniden üretiyor, bir idempotency key değişikliği öneriyor, test paketini çalıştırıyor ve raporluyor. Okuduğu, denediği ve başarısız olduğu her şey Task üzerinde, trace içinde, yorumların hemen yanında duruyor. Lider diff'i inceliyor, bir Task yorumunda bir takip sorusu soruyor (bu yeni bir çalıştırma başlatıyor) ve sonra kabul ediyor.
Sonuç, Jira'dan hiç ayrılmayan insanlar için JIRA-4821'e geri akıyor: ticket kapanıyor, sprint raporu doğru ve destek ekibi çözümü zaten kullandıkları araçta görüyor. Kimsenin yerinden kalkması gerekmedi.
Sharkly vs Jira: adil bir karşılaştırma
| Jira (Rovo Dev ve atanabilir agent'larla) | Sharkly | |
|---|---|---|
| Temel rol | Kurum genelindeki işler için kayıt sistemi | Kişiler ve Agent'lar için yürütme ve inceleme katmanı |
| Agent atama | Atanan kişi açılır menüsü, Rovo agent'ları ve desteklenen üçüncü taraf agent'ları | Bir Agent'a veya Crew'ye atanan Task |
| Agent'ların çalıştığı yer | CLI, Bitbucket Cloud, GitHub ve VS Code dahil Atlassian destekli ortamlar | Bağladığınız Computer'lar: yerel makine, uzak sunucu, container veya desteklenen bulut sunucusu |
| Runtime seçimi | Jira'nın desteklediği agent'lar | O Computer'da algılanan Runtime, yapılandırdığınız özel bir ACP Runtime dahil |
| Model faturalandırması | Atlassian planınız ve kredileriniz üzerinden | Araçlarınızda zaten yapılandırılmış abonelikler veya API anahtarları üzerinden |
| Yürütme kaydı | İş öğesi geçmişi ve bağlantılı PR'lar | Yürütme durumu, trace, sonuç ve yorumlar içeren Task |
| Platformlar arası host desteği | Atlassian tarafından yönetilir | CLI ve yerel servis için macOS, Linux ve Windows kurulum dosyaları |
| İlişki | Herkesin rapor verdiği kayıt | Jira'nın yerini almak yerine onunla çift yönlü senkronize olur |
Sık yapılan hatalar
Bunu bir geçiş süreci olarak görmek. En yaygın hata, agent yürütmesini Jira'dan ayrılmak için bir gerekçe olarak kurgulamak. Finans, destek ve diğer üç ekip o raporları okuyor. Senkronize edin, kapı dışarı etmeyin.
Webhook konuşmasını atlamak. Jira bağlantısının webhook'unu otomatik olarak kurması için yönetici izni gerekir. Bu izne sahip değilseniz, sonradan sessizlikle uğraşmak yerine tek seferlik yapılandırma paketini erken aşamada bir Jira yöneticisine ulaştırın.
Yanlışlıkla birden çok Jira projesini tek bir Space'e yönlendirmek. Bir Jira projesinin yalnızca bir aktif Space bağlantısı olabilir ve eşleştirme oluşturulduktan sonra değiştirilemez. Bağlantıları oluşturmadan önce eşlemeye karar verin, çünkü düzeltmek silip yeniden oluşturmak anlamına gelir.
Agent'a hazır olmayan işleri atamak. "Ödeme hatasını düzelt" diyen bir ticket, hangi platformda olursa olsun kötü bir çalıştırma üretir. Farkı yaratan kabul kriterleridir; bu da iyi ticket'ların her zaman ihtiyaç duyduğu disiplinin aynısı. AI agent proje yönetimi genel bakışımız, atanan kişi bir insan olmadığında nelerin değiştiğini ele alıyor.
Sonuç
Jira, "hangi işler var ve bunların sahibi kim" sorusunu yanıtlar. Rovo Dev ve atanabilir agent'larla birlikte artık Atlassian'ın desteklediği ortamlar içinde "işi kim yapıyor" sorusunun bir kısmını da yanıtlıyor. Bu, sizin stack'inizi kapsıyorsa işiniz bitmiştir ve karşılaştırma yazılarını okumayı bırakmalısınız.
Sharkly farklı bir soruyu yanıtlıyor: agent yürütmesi kendi makinelerinize, kendi runtime'larınıza ve kendi inceleme sürecinize ihtiyaç duyduğunda nerede gerçekleşir ve bu kayıt ekibin okunabilir kalmasını nasıl sağlar? Claude Code'un veya Codex'in yerine geçmiyor, Jira'nın yerine de geçmiyor. Ekibinizin zaten kullandığı araçların etrafına paylaşılan task, bağlı Computer, bağlam, kontrol ve inceleme katmanını ekliyor; sonra sonucu herkesin okuduğu ticket'a geri senkronize ediyor.
Hissettiğiniz boşluk buysa, Sharkly ile başlayın ve başka hiçbir şeye dokunmadan önce bir Jira projesini bir Space'e bağlayın.
SSS
Sharkly, Jira'nın yerini alır mı? Hayır. Import, tek yönlü sync veya çift yönlü sync ile Jira'ya bağlanır. Bir bağlantıyı silmek, Jira issue'larını, Jira epic'lerini, Sharkly Task'larını veya Sharkly Project'lerini silmeden gelecekteki senkronizasyonu durdurur.
Jira'yı doğruluk kaynağı olarak tutabilir miyim? Evet. Jira'dan Sharkly'ye yönü, Sharkly'den yeni Jira kayıtları oluşturmadan bağlantılı Sharkly kayıtlarını oluşturur veya günceller. Hâlihazırda bağlantılı kayıtlara yapılan desteklenen güncellemeler yine de geri yazılabilir.
Bu, kendi sunucunuzda barındırılan Jira ile çalışır mı? Jira Cloud ile Jira Server veya Data Center'ın ikisi de destekleniyor. Server ve Data Center kurulumları ayrıca Jira Cloud'da görünmeyen özel bir ağ proxy'si seçeneği sunar.
Model maliyetleri ne olacak? Model kullanımı, kodlama araçlarınızda yapılandırılmış abonelikler veya API anahtarları üzerinden devam eder. Model kotası, ekibinizin bağladığı AI kodlama araçlarına, planlara ve API hesaplarına bağlıdır.
Jira hangi agent'ları yerel olarak atayabilir? İş öğesinin atanan kişi açılır menüsünden seçilen Rovo agent'ları ve GitHub Copilot kodlama agent'ı gibi desteklenen üçüncü taraf agent'ları. Desteklenen liste değiştiği için Atlassian'ın güncel dokümantasyonuna bakın.
Başlamak için iki araca da ihtiyacım var mı? Hayır. Sharkly'yi önce kendi Space'leri üzerinde çalıştırıp Jira'yı sonra bağlayabilirsiniz. Zaten Jira'da yaşayan ekipler, bir ekip çalışan bir agent döngüsüne sahip olduğunda senkronizasyonu gerekçelendirmeyi genellikle daha kolay buluyor. İnsan-agent ekipleri için Jira alternatifleri karşılaştırmamız, Jira'nın hâlihazırda yerleşik olmadığı durumu ele alıyor.
