Jira Cloud'un Modeli: Space, Work Item, Work Type, Hiyerarşi ve Team-managed mi Company-managed mi?

Sürüm notu: Bu yazı Jira Cloud'un 2026-11 itibarıyla güncel hâlini (space ve work item terminolojisi) esas alır; menü adları sık değiştiği için anlatım ekran yerine kavram ve sorgu üzerinden yürür. Bu yazıda resmî belgelerden yararlanılmıştır (Atlassian Support ve Atlassian Developer, 15 Kasım 2026'da kontrol edildi).

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore (bir online kitapçı) ekibi backlog'unu Scrum serisinin 3. yazısında GitHub Projects'te tutuyordu. Kurumsal Sipariş işi büyüyünce tabloya yeni insanlar girdi: kurumsal satıştan Hakan, müşteri hizmetlerinden Gül ve okul tarafında satın almayı yürüten Nevin Hanım'ın talepleri. Ekip Jira Cloud'a geçmeye karar veriyor. Emre ile Ayşe hızlı başlamak için iki ayrı team-managed space açıyor: biri API işleri için, biri Angular arayüzü için. İkisinde de kendi "Story point estimate" alanlarını ve kendi "Improvement" work type'larını tanımlıyorlar.

Üç ay sonra Product Owner Selin iki ekibin işlerini tek board'da ve tek velocity grafiğinde görmek istiyor. Tahmin et: Bu iki space'in item'larını tek board'a koymak için ne gerekir? İki space'teki "Improvement" aynı work type mı sayılır? Ve ekip "biz bunu company-managed'a çevirelim" dediğinde Jira'da tek tıkla dönüşüm var mı? Cevaplar yazının ortasında; ipucu: üçünün de cevabı space'i açtığın ilk gün verdiğin karara bağlı.

Project Artık Space, Issue Artık Work Item

Jira'ya yıllar sonra dönen biri ilk olarak isimlerin değiştiğini görür. Atlassian 2025'te iki büyük terminoloji değişikliği yaptı. İlki "issue" yerine "work item" ve topluca "work" demek: önce Free ve Standard planlarda açıldı, Premium ve Enterprise sitelerde 14 Nisan 2025'ten itibaren yayıldı. İkincisi "project" yerine "space": Atlassian Community'deki "Jira Spaces have landed" duyurusuna göre önce Free ve Standard planlara geldi, Premium ve Enterprise siteler için 20 Ekim 2025'te başladı. Duyuru bunun yalnız bir isim değişikliği olduğunu, container'ın davranışının aynı kaldığını açıkça söylüyor.

Geliştirici için önemli olan, değişikliğin nerede durduğu. İki duyuru da mevcut API'lerin değişmediğini söylüyor: REST (HTTP üzerinden kaynak odaklı API tarzı) API v3'te endpoint'ler hâlâ /rest/api/3/issue ve alan adları hâlâ project. JQL (Jira Query Language; Jira'nın arama sorgu dili) tarafında eski kelimeler geriye dönük uyumluluk için çalışmaya devam ediyor; JQL fields sayfası da geçiş sürerken yeni terimle yazılan bazı ifadelerin henüz çalışmayabileceğini, böyle bir durumda eski terimi denemeyi öneriyor. Smart commits belgesi bile komutlardaki "issue" kelimesinin work item anlamına geldiğini ayrıca not ediyor. Yani eski bir eklenti dokümanında, Stack Overflow cevabında ya da şirket wiki'sinde "issue" ve "project" gördüğünde aynı şeyden bahsedildiğini bil:

Bu seride Jira'nın bugünkü dilini kullanıyoruz: space, work item, work type. Kodda ve API'de eski adları göreceksin; bu bir tutarsızlık değil, geçiş döneminin kendisi.

Work Item, Work Type ve Hiyerarşi

Jira'nın yapı taşı work item. Her work item'ın bir key'i var: space key'i, tire ve sıra numarası. Bookstore'un space key'i BOOK, dolayısıyla item'lar BOOK-142, BOOK-153 gibi görünüyor. Space key en az iki karakter olmalı ve büyük harfle başlamalı; ileride göreceğimiz smart commits ise yalnızca varsayılan biçimi, yani iki ya da daha fazla büyük harf, tire ve sayıyı tanıyor. Key'i kısa ve harf ağırlıklı seçmek bu yüzden sadece estetik değil.

Work type, item'ın türü. Software space'ler varsayılan olarak bir parent type (Epic), üç standart type (Story, Task, Bug) ve bir child type (Subtask) ile geliyor. Bunlar üç hiyerarşi seviyesine oturuyor: seviye 1 büyük iş (epic), seviye 0 günlük iş (story, task, bug), seviye -1 subtask. Premium ve Enterprise planlarda epic'in üstüne yeni seviyeler eklenebiliyor ve bu seviyeler plans özelliğinde birden fazla space'i aynı girişimin altında toplamak için kullanılıyor. Hiyerarşiyi değiştirmek ise ciddi bir iş: belge, yapıyı değiştirmenin mevcut parent-child ilişkilerini koparacağını ve geri alınamadığını söylüyor.

Görseldeki yapı, Requirements Analysis serisinde çıkardığımız Kurumsal Sipariş'in Jira'daki karşılığı. BOOK-120 epic'i release 1'i temsil ediyor. Altında "en az 20 adet siparişte %10 kurumsal indirim" story'si (BOOK-142), onaycıya giden e-posta story'si (BOOK-147), login sonrası indirimin sepetten düşmesi bug'ı (BOOK-153) ve veritabanı index'i için bir task (BOOK-155) var. Kısmi sevkiyat release 2'de olduğu için bu epic'in altında değil; ayrı bir epic'te bekliyor.

İlişkinin adı her seviyede aynı: Parent. Eskiden story'yi epic'e bağlamak için "Epic Link", subtask'ı story'ye bağlamak için ayrı bir mekanizma vardı; Şubat 2024'te Epic Link emekliye ayrıldı ve yeni filter'larda Parent kullanılıyor. Bir pratik sınır daha: belge bir item'ın en fazla 500 child item gösterebildiğini, bunu aşan bir parent'ın bölünmesi gerektiğini söylüyor. 500 subtask'lı bir story zaten story değildir.

Team-managed ve Company-managed: Ayarların Sahibi Kim?

Atlassian'ın kendi özeti tek cümle: iki tür arasındaki asıl fark, nasıl yönetildikleri. Team-managed space'i ekipten herhangi biri kurar ve yönetir; ayarlar o space'e özeldir, başka space'lerle paylaşılmaz. Company-managed space'te ise ekranları ve scheme'leri (workflow, permission, field ayarlarının space'lere bağlanan ortak tanımları) Jira admin'leri yapılandırır. Bir admin scheme'i değiştirdiğinde o scheme'i kullanan bütün company-managed space'ler birlikte değişir. Bu bir dezavantaj gibi okunabilir, ama standartlaştırmanın tek yolu da bu.

Work type'lar da iki türde farklı davranır. Team-managed space'te work type item'ın asıl container'ıdır: kendi alanlarını taşır ve o alanlar space dışına çıkmaz. Company-managed space'te work type daha çok bir etikettir; admin, alanları work item screen scheme gibi eşlemelerle bağlar ve aynı alanı birçok space paylaşır. Baştaki sorunun ikinci cevabı buradan çıkıyor: iki team-managed space'teki "Improvement" aynı adı taşıyan iki ayrı tanımdır.

Board tarafı da önemli. Saved filter'dan board oluşturma belgesi, team-managed projelerde ek board için zorunlu yolun bu olduğunu söylüyor. Bu yolla kurulan board company-managed bir board'dur ve birden fazla space'in item'larını gösterebilir. Yani Selin'in istediği tek board kurulabilir, ama iki space'teki birbirinden bağımsız alanlar ve work type'lar o board'da ortak bir dil konuşmaz. Velocity, burndown, cumulative flow ve control chart belgelerinin hepsinin başında da "bu sayfa company-managed space'ler içindir" notu var.

Dönüşüm Yok, Taşıma Var

Baştaki üçüncü sorunun cevabı net: yok. Atlassian'ın taşıma belgesi team-managed bir space'i company-managed'a doğrudan çeviren yerleşik bir özellik olmadığını yazıyor. Yapılacak iş, hedef türde yeni bir space açmak (company-managed hedefi bir Jira admin'i açar) ve work item'ları bulk change ile oraya taşımak. Taşımada kaybedilenler belgede tek tek sayılıyor:

• Company-managed'dan team-managed'a giderken sprint'ler taşınmaz, component ve version verisi kaybolur ve geri gelmez.
• Story point'ler her iki yönde kaybolur, çünkü iki tür farklı alan kullanır: company-managed'da "Story points", team-managed'da "Story point estimate".
• Velocity ve burnup geçmişi taşınmaz; raporlar sıfırdan başlar.
• Team-managed'dan company-managed'a giderken özel status'leri, custom field'ları ve work type'ları admin'in yeniden kurması gerekir; kurulmazsa o alanlardaki veri kaybolur.
• Work item key'leri yeni space'e göre değişir; eski key'ler yönlendirilir.

Belge gerçek veriyi taşımadan önce bir sandbox'ta deneme taşıması yapmayı öneriyor. Kendi sözümüzle: space türü, sonradan ucuza değiştirilebilecek bir ayar değil; bir mimari karar gibi düşünülmeli.

Bookstore Ekibi Hangisini Seçti?

Bookstore ekibi tek bir company-managed space açtı: BOOK. Gerekçeleri şunlar. Selin tek bir Product Backlog yönetiyor; Scrum serisinin 3. yazısında konuştuğumuz gibi backlog ürün başına birdir, ekip başına değil. Kurumsal Sipariş API'ye, Angular arayüzüne ve back office ekranlarına aynı anda dokunuyor; işi teknolojiye göre iki space'e bölmek bir story'yi iki space'e dağıtmak demek. Hakan ve Gül'ün raporları (kurumsal siparişlerde açık bug'lar, müşteri şikâyetinden gelen işler) tutarlı alanlara ihtiyaç duyuyor. Ve şirkette ileride ikinci bir ekip kurulursa aynı workflow'u paylaşabilmeleri gerekiyor.

Bunun bir bedeli var: workflow'a yeni bir status eklemek için Jira admin'e gitmek gerekiyor. Ekip bunu bilinçli olarak kabul etti; zaten workflow'un sık değişmesini istemiyorlar. Team-managed'ın doğru seçim olduğu durumlar da gerçek: tek bir ekip, admin'e bağımlı kalmadan kendi akışını deniyorsa, raporlama ihtiyacı o ekiple sınırlıysa ve başka space'lerle ortak alan gerekmiyorsa team-managed hızlı ve yeterli.

Data Center'ın Sonu: Cloud Tek Yol

Bu seri yalnız Jira Cloud'u anlatıyor; bunun gerekçesi Atlassian'ın Data Center takvimi. Atlassian'ın lisans sayfasına göre 30 Mart 2026'dan itibaren yeni müşteriler Data Center aboneliği alamıyor, 30 Mart 2028'den sonra mevcut müşteriler de yeni abonelik ya da genişleme alamayacak ve 28 Mart 2029'da Data Center ürünleri salt okunur hâle gelecek. Bugün Jira'ya yeni başlayan bir ekip için kendi sunucusunda Jira kurmak artık bir seçenek değil. Data Center kurulumu ve yönetimi bu serinin kapsamı dışında.

Jira Ne Zaman Gereksiz Ağır?

Jira'yı anlatan bir serinin dürüst olması gereken yer burası. Tek bir ekip, kodu GitHub'da, paydaşları da sprint review'a gelen birkaç kişiyse GitHub Projects çoğu zaman yeter; Scrum serisinin 3. yazısında backlog'u, sprint'i ve board'u orada yönettik ve issue ile PR (pull request; değişikliğin ana branch'e alınması için açılan istek) aynı yerde durduğu için ek bir entegrasyona ihtiyaç kalmadı. Ekip Azure DevOps kullanıyorsa Azure Boards aynı rolü pipeline ve repo ile aynı çatı altında oynar.

Jira'nın ağırlığı birden fazla ekip, geliştirici olmayan paydaşlar, ekipler arası raporlama, workflow standardı ve otomasyon ihtiyacı geldiğinde karşılığını veriyor. Bookstore'da bu eşiği geçiren şey Kurumsal Sipariş oldu: satış, müşteri hizmetleri ve kurumsal müşteri işin içine girdi. Bu eşik yoksa Jira'ya geçmek, ekibe yönetmesi gereken yeni bir sistem eklemekten öteye geçmez.

Üretimde Dikkat

Bir space'in türünü merak ediyorsan menüye bak: space adının yanındaki More actions menüsünün en altında team-managed ya da company-managed yazıyor. Board'lar ve backlog aynı anda en fazla 5.000 work item gösterebiliyor; company-managed board'larda bunun çözümü board filter'ını JQL ile daraltmak, team-managed'da ise bitmiş işleri board'dan temizlemek ya da backlog'a almak. Company-managed bir scheme'i değiştirmeden önce o scheme'i hangi space'lerin kullandığına bak; değişiklik hepsine aynı anda yansıyor. Ve belgelerin kendisi de geçişte: aynı sayfada hem "space" hem URL'de "project" görmen normal.

Sık Düşülen Tuzaklar

En sık görülen tuzak, her ekibin kendi alanlarını ve work type'larını üretmesi. "Müşteri", "Customer", "Client" adında üç ayrı alan; "Improvement", "Enhancement", "Tech Task" adında üç ayrı type. Altı ay sonra kimse "kurumsal müşterilerden gelen bütün açık işler" sorusunu tek bir sorguyla soramıyor. Kural basit: yeni bir alan ya da type eklemeden önce, onu kullanacak bir rapor ya da sorgu yaz. Yazamıyorsan alan muhtemelen gereksiz.

İkinci tuzak, "şimdilik team-managed açalım, sonra çeviririz" demek. Yukarıda gördüğümüz gibi çevirme yok; taşıma var ve story point, sprint ve rapor geçmişi yolda kalıyor. Üçüncüsü, eski "Epic Link" filter'larına güvenip yeni filter'ları da aynı biçimde yazmak; eski filter'lar çalışmaya devam ediyor ama yeniler Parent ile yazılmalı. Dördüncüsü, story point'in iki farklı alanda tutulduğunu bilmeden iki türdeki space'lerin tahminlerini aynı raporda toplamaya çalışmak.

Küçük Bir Deneme

★☆☆ Kendi ekibinin bugünkü işlerini kâğıt üzerinde Jira hiyerarşisine yerleştir: bir epic, üç-dört standart item ve gerekiyorsa subtask. Hangi item'ı subtask yapmak istedin ve gerçekten ayrı bir item olmalı mıydı?

★★☆ Yukarıdaki team-managed ve company-managed tablosunu kendi şirketin için doldur: kaç ekip var, ortak bir workflow gerekiyor mu, raporu kim okuyor, Jira admin'e erişimin ne kadar hızlı? Sonuçta hangi türü seçerdin ve neyi kaybetmeyi kabul ederdin?

★★★ Mevcut bir Jira sitesinde çalışıyorsan, space'lerdeki custom field'ları listele ve aynı anlama gelen ama farklı adla açılmış alanları bul. Her biri için hangi sorgunun bu alan yüzünden yazılamadığını not et.

Model yerine oturdu; sıradaki adım item'ların nasıl aktığı. Bir sonraki yazıda Bookstore ekibinin workflow'unu Kanban serisindeki Definition of Workflow'dan türetiyor, status, transition ve board kolonlarını eşliyor ve raporları bozan resolution alanının neden bu kadar önemli olduğunu görüyoruz.