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?
“Bunu kim takip ediyor?”, “Bu alanın bağlamını kim biliyor?” ve “Karar için kime gitmeliyiz?” sorularını yanıtlamaya yardımcı olur. İyi tanımlandığında review, devir ve escalation yolunu görünür kılar; ekip işbirliğini ortadan kaldırmaz.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-002/SCN-003'te ödeme modülündeki bir dosyayı değiştiren pull request açtığını düşün. CODEOWNERS nedeniyle ilgili ekipten review istenir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Bunu “artık değişikliği onlar yapacak” diye yorumlamazsın; kendi değişikliğinin açıklaması ve düzeltmelerinden sorumlu kalırken alan bağlamı için owner ile çalışırsın. Owner müsait değilse tanımlı yedek veya escalation yolunu sorarsın.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Bu değişikliğin uygulaması bende; ödeme alanı için review owner'ı Payments ekibi. Karar bugün çıkmazsa yedek reviewer'ı netleştirip ticket'ı güncelleyeceğim.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Ticket assignee'si, değişiklik yazarı, reviewer, Code Owner ve servis/on-call sorumlusu rollerinin farklı olabileceğini fark edebilmelisin.
- Açıkla: Ownership'in takip, bağlam, karar ve escalation sağladığını; tek başına çalışma veya suç sahipliği olmadığını anlatabilmelisin.
- Uygula: Beklenen owner belirsizse doğru kişiyi veya ekibi ve yedeği sorabilmeli; kendi sorumluluğunu, ihtiyaç duyduğun kararı ve devir durumunu görünür kılabilmelisin.
- Şimdilik bilmesi gerekmeyen: Organizasyon çapında Ownership modeli tasarlamak, CODEOWNERS sözdizimi, yetki matrisi ve on-call kapasite planlamasını şimdilik öğrenmen gerekmez.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Bir işin durumunu kimin takip edeceği, bir kod alanında kimden review isteneceği veya bir sorun büyüdüğünde kimin koordinasyon kuracağı belirsiz kaldığında karar ve bilgi boşlukları oluşabilir. Ekipler Ownership'i bu temas ve takip sorumluluğunu görünür kılmak için farklı biçimlerde tanımlar.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler kod review taleplerini alanı tanıyan kişilere yönlendirmek, operasyonel görevleri nöbet rolüyle dağıtmak veya bir işin takibini görünür kılmak için farklı Ownership mekanizmaları kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
GitHub ve GitLab Code Owners ile Google SRE'nin on-call yaklaşımı somut fakat kendi bağlamlarına özgü örneklerdir; evrensel bir organizasyon modeli oluşturmazlar.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Tek bir owner hızlı temas noktası sağlayabilir fakat yedek ve bilgi paylaşımı yoksa darboğaz yaratabilir. Ekip ownership'i bilgi yayılımını destekleyebilir fakat takip sorumlusu açık değilse “başkası yapar” boşluğu oluşabilir. Uygun model risk, ekip boyutu, karar yetkisi ve çalışma saatleri gibi bağlama bağlıdır.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Owner bütün işi tek başına yapar.” Yanlış; owner koordinasyon kurabilir, delege edebilir ve yardım isteyebilir.
- “Code Owner dosyanın erişim yetkisini otomatik kazanır.” Yanlış; GitHub'da gerekli izin önceden bulunmalıdır.
- “Assignee ile owner her zaman aynı kişidir.” Yanlış; iş üzerinde çalışan kişi ile alan review sorumlusu farklı olabilir.
- “Ownership hata olduğunda suçlanacak kişiyi bulmaktır.” Bu briefin kapsamına ve kaynakların sorumluluk/işbirliği kullanımına aykırıdır.
- “Bir owner varsa ekip geri kalanı o alanı anlamak zorunda değildir.” Desteklenmeyen ve darboğaz riski taşıyan genelleme.
Gerilim ve çözüm1. bölüm