iş kaydı yok
DevAtlas
Kavram yükleniyor.CON-001Ekip ve iş planlama
Ticket
Ticket (İş Kaydı)
Kısa tanım
Ticket, ekiplerin bir işi, sorunu veya isteği araç içinde kaydedip izlerken kullandığı bağlamsal bir üst terimdir. Bir ekipte task, başka bir ekipte issue, bug veya user story gibi farklı kayıt türlerini kapsayabilir; tek ve evrensel bir ticket şeması yoktur.
Stajİlk işGünlük ekipPlanlamaİşbirliği
Temsili kavram şemasıCON-001
Artefact şeması
İş artefact'ı
Bir iş, konuşulabilir hâle gelir.
01 · Neden?İhtiyaç
Yapılacak işin arkasındaki ihtiyaç görünür olur.
- Başlangıç beklentisi
- UygulaDevAtlas önerisi; evrensel sektör standardı değildir.
- Tahmini okuma
- 6 dakika
Görsel anlatım · İş kaydı
Ticket iş içinde nasıl yaşar?
Bir kullanıcı problemi, ekip içinde konuşulabilir ve doğrulanabilir bir iş kaydına nasıl dönüşür?
DEVATLAS · TICKET
1İhtiyaç
Ödeme sayfasında bazı kullanıcılar iki kez ücretlendiriliyor.
DESTEK KANALI · 3 KULLANICI RAPORU
problem ≠ ticket
Bir problem görünür oldu. Henüz bir iş kaydı yok.
Sahneleri kendi hızında incele.
Sahne 01 / 05: İhtiyaç
DEVATLAS · TICKET
2Ortak kayıt
kayıt açıldı — geliştirme sözü verilmedi
İki kez ücretlendirme
- Ödeme sayfası · destek kanalından geldi
- 3 kullanıcı raporu
- Beklenen sonuç: henüz tanımsız
Backlog
- bekleyen işler
bu kartın kendisi değil
aynı kaydı konuşuyor
Problem, bağlam ve ilk bilgiler tek bir kayıtta toplandı. Artık ekip aynı şeyi konuşuyor.
Sahneleri kendi hızında incele.
Sahne 02 / 05: Ortak kayıt
DEVATLAS · TICKET
3Netleştirme
İki kez ücretlendirme
- Ödeme sayfası · destek kanalından geldi
- 3 kullanıcı raporu
- Kapsam: yalnızca kart ile ödeme
- Beklenen davranış ne?
- Hangi durumda tamam sayılır?
Acceptance Criteria
- tek ücretlendirme
- açık hata mesajı
Refinement'ta konuşuldu
netleşme konuşmayla olur, alan doldurmakla değil
Eksik bilgi, kapsam ve kabul sınırı görünür hâle geldi. Ticket değişti — bu normaldir.
Sahneleri kendi hızında incele.
Sahne 03 / 05: Netleştirme
DEVATLAS · TICKET
4İş akışı
İki kez ücretlendirme
- Kabul ölçütleri tanımlı
- Değişiklik doğrulamada
Backlog
Ownership
atama ≠ tüm sorumluluk
- Geliştirme
- Review
- Doğrulama
kayıt hareket eder — bilgi kartta kalır
Ticket geliştirme, review ve doğrulama sürecine bağlandı. Akış, ekibe göre değişebilir.
Sahneleri kendi hızında incele.
Sahne 04 / 05: İş akışı
DEVATLAS · TICKET
5Geri dönüş
İki kez ücretlendirme
- Kabul ölçütleri tanımlı
- Yeni bulgu: mobil tarayıcıda tekrar ediyor
- Geliştirme
- Review
- Doğrulama
yeniden ele alındı
Ticket; Backlog, Refinement, Acceptance Criteria ve Ownership ile birlikte çalışır — hiçbiriyle aynı şey değildir.
Review veya doğrulama sonucunda ticket yeniden ele alınabilir. Geri dönmek başarısızlık değil, sürecin parçasıdır.
Sahneleri kendi hızında incele.
Sahne 05 / 05: Geri dönüş
Editoryal beta4 kaynak · Son güncelleme 18 Ağustos 2026
İnceleme ayrıntılarıBu sayfadaKısa tanım01 / 12Bölümler
Kişisel mercekBu kavram sana nerede dokunur?İlk okumayı bitirince kendi bağlamına göre aç.
Seçimine göre içerik
Mesleki merceğin
İçerik merceğin hazırlanıyor.
Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
İlk okuma
Ticket; işin neden yapıldığı, kim tarafından ele alındığı, hangi durumda olduğu ve başka hangi işlerle ilişkili olduğu bilgisinin kaybolmasını azaltır. Konuşmanın yerine geçmez; konuşmanın sonucunu görünür ve yeniden bulunabilir kılar.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
İlk okuma
SCN-001'de sana yalnızca “profil sayfasını düzelt” başlıklı bir ticket geldiğini düşün. Koda başlamadan önce beklenen kullanıcı sonucunu, mevcut davranışı, kapsam dışını, Acceptance Criteria'yı, ilgili bağlantıları ve karar verecek kişiyi sorarsın. Netleşen bilgileri ticket'a eklersin; belirsiz noktaları sessizce tahmin etmezsin.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
İlk okuma
Temsili ekip konuşması: “Bu ticket'ta beklenen sonucu ve kapsam dışını göremiyorum; başlamadan önce bunları netleştirebilir miyiz?”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
01TanıTemel02AçıklaTemel03UygulaHedef
- Tanı: Ticket anahtarını, başlığını, durumunu, sorumlusunu ve ilişkili kayıtları ayırt edebilmelisin.
- Açıkla: Kaydın neden ortak referans olduğunu ve neden tek başına yeterli olmadığını anlatabilmelisin.
- Uygula: Belirsiz bir ticket'ta eksik amacı, bağlamı, kabul koşullarını ve bağımlılıkları sorabilmeli; ilerleme değiştiğinde kaydı güncelleyebilmelisin.
- Şimdilik bilmesi gerekmeyen: Araç yöneticiliği, kurumsal workflow tasarımı, raporlama otomasyonu ve portföy metriklerini şimdilik öğrenmen gerekmez.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
İlk okuma
Bir iş yalnızca sözlü konuşmada veya mesaj akışında kaldığında amacı, son durumu ve alınan kararlar kolayca dağılabilir. Ekipçe erişilebilen bir kayıt, işle ilgili konuşmaları ve güncellemeleri yeniden bulunabilir bir referansta toplamaya yardımcı olur.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
İlk okuma
Ekipler planlama, tartışma, önceliklendirme ve ilerleme takibini aynı referans üzerinden yürütmek için ticket kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Ancak kaydı kimin açtığı, kimin ele aldığı ve hangi aşamalardan geçirdiği ekipten ekibe değişir. Google'ın SRE kitabındaki operasyon örneğinde bile ticket'ları ele alma biçimi farklı ekiplerde farklılaşır; bu örnek evrensel bir süreç tanımlamaz.
Karar alanı · Bölüm 07
Trade-off ve bağlam
İlk okuma
Çok az bilgi tahmin ve tekrar konuşma maliyetini artırabilir; gereğinden fazla şablon ve ayrıntı da kaydı bakım yüküne dönüştürebilir. Uygun ayrıntı düzeyi işin riski, yakınlığı ve ekip anlaşmasına bağlıdır. Ticket'ın güncel görünmesi, gerçek durumun güncel olduğunun garantisi değildir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Her ticket bir user story'dir.” Yanlış; araçlar aynı kayıt sistemi içinde farklı iş türleri taşıyabilir.
- “Ticket açıldıysa iş çalışmaya hazırdır.” Yanlış; amaç, kapsam veya kabul koşulları hâlâ belirsiz olabilir.
- “Assignee bütün sonuçtan tek başına sorumludur.” Atama, koordinasyon ve daha geniş Ownership aynı şey değildir.
- “Uzun ticket iyi ticket'tır.” Uzunluk kalite ölçütü değildir; gerekli ayrıntı işin bağlamına göre değişir.
Gerilim ve çözüm1. bölüm
DEVATLAS / DECISION LENS
Karar merceği
Kararı şu sırayla incele: problem, kısıt, seçenek ve kanıt.
PilotTemsili veri
01Problemin çerçevesi
İş isteği yalnızca kısa bir başlıkla geldiğinde ekip aynı sonucu kastetmeyebilir.
Karar sorusu
Bu ticket'ı uygulanabilir hâle getirmek için önce hangi bilgiyi netleştirmeliyim?
02Kısıtlar
- Kullanıcı etkisi ve kapsam henüz net değildir.
- Küçük bir değişiklik için sınırlı geliştirme zamanı vardır.
04Kanıt
- Üç örnek beklenen davranış için kabul kriterlerini karşılaştır.
- Test veya yeniden üretim çıktısında mevcut ve beklenen davranışı ayır.
05Sınırlılık
Ticket tek başına priority, ownership, security veya production kararını belirlemez.
İleri mühendislik bağlamıAgent sınırı, temsili artefact ve Technology contextDetayları açDetayları kapat
06Agent sınırı
Agent’ın yapabileceği işler
- Belirsiz başlıktan açıklığa kavuşturulacak noktaları ve soru taslağını çıkarabilir.
- Kabul kriteri ve örnek davranış taslağı önerebilir.
İnsan kararında kalan işler
- İnsan, kullanıcı etkisini, kapsamı ve teslim önceliğini belirler.
- Security, privacy ve production riskinin kabul edilip edilmeyeceğine insan karar verir.
Verification adımları
- Kabul kriterlerini örnek davranışlarla karşılaştır.
- İlgili test veya yeniden üretim çıktısını ticket kapsamıyla kontrol et.
07Temsili agent artefact’ı
Temsili ticket karar özeti
Mock / representativeEksik bağlamı, seçenekleri ve doğrulama sinyallerini ekip içinde karşılaştırılabilir kılmak.
Evidence signals
- Kabul kriterleri
- Örnek davranış
- Test çıktısı
Limitations
- Gerçek bir iş kaydı değildir ve insanın kapsam kararının yerine geçmez.
- Tek başına security, privacy veya production uygunluğunu kanıtlamaz.
Bu artefact temsili bir çıktı örneğidir; production onayı veya otomatik karar değildir.
08Technology context
Technology
Ticket ve acceptance criteria
Problem
Belirsiz bir iş isteğinin farklı yorumlanması.
Decision
İşe başlamadan önce ticket bağlamını ve kabul kriterlerini netleştirmek.
Trade-off
Başlangıç iletişimi için zaman ayırmak, yanlış uygulama ve yeniden iş riskini azaltır.
Scenario IDs
SCN-001
Verification evidence
- Kabul kriterleri ile örnek davranışın test çıktısını karşılaştır.
İş içinde görWorkflow ve gerçek araç örnekleriKavramı anladıktan sonra işte nasıl göründüğünü incele.
Etkileşimli iş bağlamı
Bu kavram işin neresinde?
Bir ticket'ın fikirden production'a uzanan olası yolunu incele. Bir aşama seçtiğinde ekipte ne olduğunu, kimlerin katıldığını ve hangi kavramların devreye girdiğini görürsün.
Temsili akış — aşamalar şirkete, ekibe ve işin riskine göre birleşebilir, atlanabilir veya geri dönebilir.
KeşifPlanlamaGeliştirmeDoğrulama ve yayınCanlı
Keşif · Aşama 01
İhtiyaç görünür olur
1 / 8Burada ne olur?
Ekip çözümden önce hangi kullanıcı veya sistem probleminin ele alınacağını anlamaya çalışır. Bu aşamada geliştirme sözü verilmiş olmayabilir.
Kimler katılır?
- Ürün
- Tasarım
- İlgili teknik ekip
Ekipte nasıl duyarsın?
Temsili ekip konuşması: “Önce çözdüğümüz problemi netleştirelim.”
Junior için dikkat noktası
İlk duyulan çözüm önerisini problem tanımı sanmak.
Bu aşamadaki kavramlar
- TicketBu sayfa
- Ownership
Aşama 1: İhtiyaç görünür olur
Araçta karşılığı
İş kaydında hangi bilgi görünür olur?
Ticket, ekibin konuşacağı işi görünür kılar. Araçta başlık, bağlam, kabul sinyalleri ve hâlâ eksik olan bilgi aynı kayıtta toplanabilir.
Bağlam: Sorun, çözüm önerisinden önce görünür olur. Bu, ekibin aynı problemi konuşmasına yardım eder.
Hazırlık sinyali:Kabul ölçütleri ve eksik bilgiler, ticket'ın uygulamaya hazır olup olmadığını sorgulatır.
Bu kesit yalnız GitHub Issues'da ticket benzeri bir iş kaydının nerede göründüğünü gösterir. Jira, Linear ve ekip içi araçlarda alanlar, durum adları ve sahiplik kuralları değişebilir; Ticket'ın kanonik anlatımı aşağıda kalır.
Keşfe devam et
İlgili kavramlar
Bağlantılar benzerlik listesi değildir; her biri bu kavramla neden birlikte düşünülmesi gerektiğini açıklar.
Şu an baktığın kavramTicketCON-001 · 4 editoryal bağlantı
Bağlantı 01 / 04
Birlikte kullanılırAcceptance Criteria
Bu bağlantı neden var?
Acceptance Criteria, ticket'ın beklenen sonucunu doğrulanabilir hâle getirebilir.
Neden şimdi?
Ticket'ın beklenen sonucunu nasıl doğrulanabilir hâle getireceğini görmek için Acceptance Criteria doğal sonraki adımdır.
İş bağlamında gör
Bu kavramın geçtiği senaryolar
Kendi cümlenle düşün
Anlama kontrolü
Bu sorular puanlanmaz ve cevap metnin kaydedilmez. Amaç tanımı ezberlemek değil, kavramı iş bağlamında açıklayabilmektir.
Başlığı anlaşılır fakat beklenen sonucu belirsiz bir ticket aldığında, kod yazmadan önce hangi üç bilgiyi netleştirirsin?
Bir ticket'ın assignee alanının dolu olması neden işin bütün bağlamının ve ownership'inin net olduğu anlamına gelmez?
Anlama durumun yükleniyor…
“Anladım” bir öz değerlendirmedir; sınav, yetkinlik, işe hazırlık, sertifika, puan veya rozet anlamına gelmez.
Kanıt yüzeyi
Kaynaklar
Kaynak türü ve desteklediği bölümler görünür tutulur. Tek bir şirket pratiği evrensel sektör standardı olarak sunulmaz.
- TKT-01What is a work item?
- Tür
- Resmî araç dokümantasyonu
- Desteklediği bölümler
- Kısa tanım · Hangi problemi çözer? · Trade-off ve bağlam · Yaygın yanlış anlamalar · Karar merceği: problem, seçenekler ve trade-off
- Erişim
- 19 Temmuz 2026
- TKT-02About issues
- Tür
- Resmî araç dokümantasyonu
- Desteklediği bölümler
- Kısa tanım · Hangi problemi çözer? · Yaygın yanlış anlamalar · Karar merceği: problem, seçenekler ve kanıt
- Erişim
- 19 Temmuz 2026
- TKT-03The Scrum Guide — 2020
- Tür
- Birincil metodoloji rehberi
- Desteklediği bölümler
- Gerçek iş senaryosu · Trade-off ve bağlam · Karar merceği: kısıtlar ve seçenekler
- Erişim
- 19 Temmuz 2026
- Tür
- Açık şirket pratiği
- Desteklediği bölümler
- Şirketler neden kullanır? · Trade-off ve bağlam · Karar merceği: sınırlar ve doğrulama
- Erişim
- 19 Temmuz 2026
Şeffaflık
İnceleme bilgisi
Kaynak temelli editoryal beta — uzman incelemesi bulunmuyor.
- İçerik durumu
- Taslak
- Kaynak durumu
- Kaynaklar tamamlandı
- İnceleme durumu
- Editoryal beta
- Son güncelleme
- 18 Ağustos 2026