Skip to main content

> ters_conway_manevrası_(inverse_conway_maneuver)_ve_takım_topolojileri

Ters Conway Manevrası (Inverse Conway Maneuver) ve Takım Topolojileri

'Ters Conway Manevrası' (Inverse Conway Maneuver), istenen mikroservis sınırlarına (Bounded Contexts) göre takım yapılarını yeniden şekillendirerek ekipler arası senkronizasyon kilitlerini nasıl yok eder?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Conway Kanunu şunu söyler: 'Yazılım sistemleri, onları üreten organizasyonların iletişim yapısını birebir kopyalar.' Eğer organizasyonel yapıyı değiştirmeden monolitik bir sistemi mikroservislere bölmeye çalışırsanız (ör. Yatay Frontend Ekibi, Backend Ekibi, DBA Ekibi), ortaya her özelliğin çıkması için ortak toplantılar ve senkronize canlıya çıkış trenleri gerektiren bir 'Dağıtık Monolit' çıkar. Ters Conway Manevrası bu denklemi tersine çevirir: Mühendislik liderliği, ekiplerin sınırlarını hedeflenen mikroservis sınırlarına (Bounded Contexts) göre bilerek baştan kurar (ör. Ödeme Akış Ekibi, Stok Ekibi, Kimlik Platform Ekibi). Her ekip kendi alanını uçtan uca (UI, API, veritabanı, CI/CD) sahiplenir; ekipler arası el değiştirme biter ve tam otonom yayınlama hızı yakalanır.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Takım Topolojileri (Team Topologies) metodolojisi Ters Conway Manevrasını 4 ana takım türüyle uygular: (1) Akış Odaklı Ekipler (Stream-Aligned): Tek bir iş alanına (Ödeme, Arama) odaklanmış çok fonksiyonlu otonom ürün ekipleri. (2) Platform Ekipleri: Akış ekiplerinin kimseden izin almadan canlıya çıkabilmesi için self-servis iç geliştirici platformları (Kubernetes, CI/CD, İzleme) sunan ekipler. (3) Yetkinleştirici Ekipler (Enabling): Yeni teknolojileri (Güvenlik, AI) öğretmek için ekiplere geçici dahil olan uzmanlar. (4) Karmaşık Alt Sistem Ekipleri: Özel matematiksel rota veya video sıkıştırma motoru gibi derin teknoloji geliştiren ekipler. Ekipler arası iş bağımlılıklarının yok edilmesi akış hızını maksimize eder.

2. Doğru Kullanım Senaryosu

30-50 mühendisi aşan büyüyen şirketler, monolitten mikroservise geçiş yapan organizasyonlar ve ekipler arası bağımlılıklar yüzünden teslimat hızı kilitlenen kurumlar.

3. Prodüksiyon Arıza Modları

50 adet mikroservis yazıp hala merkezi bir 'DBA Ekibi' ve 'Manuel QA Ekibi' tutulması sonucu basit bir sütun ekleme işinin 2 hafta Jira kuyruğunda beklemesi; iki farklı direktörlük arasındaki siyasi çekişmelerin servisler arasında döngüsel ağ bağımlılıkları üretmesi.

4. Teşhis ve Telemetri Sinyalleri

Tek bir özelliğin canlıya çıkabilmesi için 6 farklı ekibin reposuna PR açılması ve teslimat süresinin 4 haftayı aşması; sprint retrospektiflerinin 'B ekibini beklerken bloke olduk' şikayetleriyle dolması.

5. Önleme ve Mimari Bariyerler

Organizasyon şemasını çizmeden önce Domain-Driven Design (DDD) ile iş sınırlarını (Bounded Contexts) belirleyin; her git reposuna ve veritabanı şemasına tek bir ekibin sahipliğini atayın; ekipler arası ilişkileri net API sözleşmeleriyle tanımlayın.

6. Mimari Ödünleşimler (Trade-offs)

Ekipleri iş akışlarına göre yeniden yapılandırmak organizasyonel değişim sancısı ve mühendislerin daha geniş yetkinlik kazanmasını gerektirir; ancak dağıtık monolit felaketinin kanıtlanmış tek yapısal ilacıdır.

Vaka İncelemesi (TinyCTO Örneği)

Bir dijital bankacılık platformunda 40 mühendis Arayüz, API ve Veritabanı ekipleri olarak yatay bölünmüştü. Basit bir 'PDF İndir' butonu eklemek 3 farklı Jira bileti, 3 sprint ve 6 haftalık koordinasyon gerektiriyordu. Yönetim Ters Conway Manevrası uygulayarak mühendisleri 4 dikey ürün ekibine (Hesaplar, Transferler, Kartlar, Krediler) ve 1 Platform ekibine böldü. Her ekip kendi arayüzünü, API'sini ve veritabanını uçtan uca sahiplendi. Canlıya özellik çıkış süresi 6 haftadan 3 güne indi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Conway Kanunu (Conway's Law) nedir?

Yazılım mimarilerinin, onları geliştiren organizasyonların iletişim ve hiyerarşi yapısını kaçınılmaz olarak kopyalaması ilkesidir.
Q2

Ters Conway Manevrası (Inverse Conway Maneuver) nedir?

İstenen yazılım mimarisine ve iş sınırlarına ulaşmak için insan ekiplerini bilerek o mimariye uygun şekilde yeniden yapılandırmaktır.

Ters Conway Manevrası (Inverse Conway Maneuver) ve Takım Topolojileri — Sıkça Sorulan Sorular

Yatay fonksiyonel ekipler (Frontend, Backend, DBA) neden dağıtık monolit üretir?

Çünkü her kullanıcı özelliği bu 3 katmanın tümüne temas eder; bu da sürekli ekipler arası el değiştirme, toplantılar ve birbirine bağımlı canlıya çıkışlar doğurur.

Team Topologies yaklaşımında 'Akış Odaklı Ekip' (Stream-Aligned Team) nedir?

Kendi başına bağımsız değer üretebilen, tek bir sürekli iş akışına (ör. Ödeme, Kullanıcı Karşılama) odaklanmış çok fonksiyonlu ürün ekibidir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Conway's Law dictates that software architecture mirrors organizational communication.
  • ▸Inverse Conway Maneuver reorganizes teams to match target microservice bounded contexts.
  • ▸Stream-aligned squads own their domain end-to-end (UI, API, database, CI/CD).
  • ▸Platform teams provide self-service tooling so stream teams deploy without dependencies.

Yaygın Yanılgılar

  • ✗Yanılgı: Microservices automatically make development faster (Gerçek: Without team reorganization, microservices create a nightmare distributed monolith).
  • ✗Yanılgı: Every team needs its own dedicated infrastructure engineers (Gerçek: A centralized platform team provides self-service infrastructure for all squads).

Karar Kılavuzu & Önceliklendirme

Organize engineering squads around Domain-Driven Design (DDD) bounded contexts. Establish an internal developer platform to decouple infrastructure from product development.

Doğrulanmış Kaynaklar & Referanslar