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?
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
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?
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?
- 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ı?
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?
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
Ç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
