Event Storming Atölyesi: Olay Keşfinden Sınırlı Bağlama

Event storming nedir, neden işe yarar?

Yazılım projelerinde en pahalı hatalar kod hatası değil, yanlış anlaşılmış iş kurallarıdır. İş uzmanı bir süreci başka, geliştirici başka anlar; ikisinin kullandığı sözcükler aynı olsa da anlamları farklıdır. Event storming, bu farkı erken ve ucuz yoldan görünür kılmak için geliştirilmiş bir atölye biçimidir. Fikir, farklı geçmişlerden gelen insanların bir iş alanını birlikte keşfetmesine dayanır.

Yöntem, uzun bir duvar boyunca renkli yapışkan notlarla çalışmak üzerine kurulur. Katılımcılar iş alanında gerçekleşen olayları yazar ve bunları zaman sırasına dizer. Birisi bir olay yazar, başkası ona itiraz eder, üçüncüsü eksik bir adımı ekler. Atölyenin değeri üretilen duvardan çok bu konuşmalardır: gizli varsayımlar, eksik adımlar ve farklı kullanılan terimler yüzeye çıkar.

Atölyenin farklı amaçlara göre üç düzeyi vardır. Genel resim düzeyi, bir iş kolunun sağlığını ya da yeni bir iş modelinin uygulanabilirliğini keşfeder. Süreç modelleme düzeyi, mevcut bir sürecin darboğazlarını bulur. Yazılım tasarımı düzeyi ise bir sınırlı bağlam içinde olay güdümlü, bakımı kolay yazılım tasarlamak için ortak bir dil ve model çıkarır. Bir ekibin atölyeyi hazırlayıp yürütmesi en çok son iki düzeyde karşımıza çıkar.

Atölyeyi hazırlamak

İyi hazırlık atölyenin yarısıdır. Önce amaç belirlenir: yeni bir ürünün alanını mı keşfediyoruz, mevcut bir süreçte darboğaz mı arıyoruz, yoksa bir modül için yazılım tasarımı mı yapıyoruz? Amaç, kapsamı ve ayrıntı düzeyini belirler. Kapsamı çok geniş tutmak sonuçsuz bir duvar, çok dar tutmak ise bağlamdan kopuk bir model üretir.

Katılımcı seçimi en kritik karardır. Alanı bilen iş uzmanları ve onların kararlarını uygulayan geliştiriciler aynı odada bulunmalıdır. Konunun parçalarını bilen farklı birimler temsil edilmelidir; yalnızca bir birimin gözünden yapılan atölye, birimler arası boşlukları kaçırır. Çok büyük gruplarda konuşma tek bir kişiye kayabilir, bu yüzden katılımcı sayısı kolaylaştırıcının idare edebileceği düzeyde tutulur.

Fiziksel hazırlık basittir ama ihmal edilmez. Uzun ve boş bir duvar ya da çevrimiçi ortamda geniş bir tahta, çok sayıda yapışkan not ve kalem, ayakta çalışmaya elverişli bir alan gerekir. Sandalyeler ve masalar kasıtlı olarak azaltılır; ayakta çalışan insanlar duvarın önünde hareket eder, konuşur ve itiraz eder.

Kolaylaştırıcı, atölyenin sürecini yürüten kişidir; içeriğin sahibi değildir. Görevi herkesin sesini duyurmak, tartışmayı yönlendirmek ve çelişkileri hotspot olarak işaretleyip akışı sürdürmektir. Atölye öncesinde katılımcılara kısa bir amaç ve yöntem açıklaması gönderilir.

Olay keşfi ve zaman çizgisi

Atölye, herkesin sessizce ve aynı anda iş alanında olan olayları yazmasıyla başlar. Olay, geçmiş zamanlı bir fiille ifade edilir: "sipariş verildi", "ödeme alındı", "teslimat planlandı". Geçmiş zaman, olayın gerçekleşmiş bir olgu olduğunu vurgular ve komut ile karışmasını önler. Bu aşamada sıralama, mükemmellik ya da tekrar kaygısı yoktur; amaç hızla çok olay çıkarmaktır.

Sonra olaylar soldan sağa zaman sırasına dizilir. Tekrar eden notlar birleştirilir, aynı olayın farklı adlandırmaları tartışılır. Bu aşamada ilk büyük değer ortaya çıkar: aynı olaya farklı isim veren iki kişi aslında farklı şeyler anlatıyor olabilir, ya da aynı ismi kullanan iki kişi başka başka şeyler kastediyor olabilir. Bu tür dil ayrılıkları kaydedilir.

Çelişkiler, cevaplanmamış sorular ve tartışmalı noktalar hotspot ile işaretlenir. Hotspot, tartışmayı bastırmak değil ertelemek içindir; atölye akışı bir sorunda tıkanırsa tüm grup durmaz, nota kaydedip ilerler. Daha sonra hotspot'lar ayrı ayrı ele alınır ve yanıtlayabilecek kişiler çağrılır.

Zaman çizgisi oturduğunda öne çıkan olaylar, yani akışın dönüm noktaları belirlenir. Bunlar, paydaşların en çok ilgilendiği ve iş alanındaki aşamaları ayıran olaylardır. Pivotal olaylar, ileride sınırlı bağlamları ayırırken kullanışlı ipuçlarıdır.

Komut, aktör ve politika ile zenginleştirme

Zaman çizgisi bir kez kurulduktan sonra, her olayın nedeni sorulur. Hangi eylem bu olayı doğurdu? Bu eylem komuttur: bir karar, bir niyet ya da bir eylem. Komut, olayın solunda yer alır; "siparişi onayla" komutu "sipariş onaylandı" olayını üretir.

Komutu kim başlattı? Bir kişi, bir ekip ya da bir departman olabilir; bunlar aktör olarak eklenir. Bazen komutu bir kişi değil, başka bir olay tetikler. Bu durumda araya bir politika girer: "ödeme alındığında siparişi hazırlığa al" gibi, şu olursa şunu yap biçiminde bir kural. Politika elle ya da otomatik uygulanabilir ve iş alanındaki gizli kuralların çoğu burada ortaya çıkar.

Eylemi yapan kişinin karar vermek için ihtiyaç duyduğu bilgi sorgu modeli olarak not edilir. Kullanılan harici yazılım ya da araçlar sistem olarak eklenir; bir tablo hesabından bir mikro hizmete kadar her şey sistem sayılır. Komutun çalışması için sağlanması gereken iş kuralı kısıt olarak yazılır. Bu kavram, eski anlatımlarda aggregate olarak anılan yapının yerini alan terimdir.

Bu aşamada duvardaki yoğunluk artar ve her şey görünür hale gelir. Beklenmedik sonuçlar çıkabilir: iki aktör aynı komutu farklı şekilde veriyor, bir politika kimsenin sahiplenmediği bir kuralı uyguluyor, bir sistem hiçbir olayı üretmiyor. Bu bulgular, hem iş süreci hem yazılım için doğrudan iyileştirme fırsatlarıdır.

Sınırlı bağlamları çıkarmak

Duvardaki zenginleştirilmiş model, bir sonraki adımda sınırlara bölünür. İlke, aynı kelimenin farklı anlam taşıdığı yerlerde sınır olabileceğidir. Örneğin "müşteri" kelimesi satış biriminde potansiyel alıcıyı, faturalama biriminde ise ödeme yapan tüzel kişiyi ifade edebilir. İki anlam ayrı modellere ihtiyaç duyar; ortada bir sınır vardır.

Sınır adaylarını bulmak için birkaç ipucu kullanılır. Ortak dilin değiştiği noktalar, farklı ekiplerin sahip olduğu bölümler, olay kümeleri arasında zayıf bağlantılar ve pivotal olaylar sınırı işaret eder. Birbirine çok bağlı olay ve komut kümeleri aynı bağlamda toplanır. Bu bölünme kesinleşmiş bir mimari değil, ilk taslaktır; ekip tartışarak, gerekirse duvarda yeniden gruplayarak ilerler.

Sonraki adım, bağlamlar arasındaki ilişkilerin çıkarılmasıdır: hangi bağlam hangisine olay gönderiyor, hangisi başkasının modelini kullanıyor? Bu bağlam haritası, ekip sınırlarını ve hizmetler arası entegrasyonu planlamak için kullanılır.

Atölye bittiğinde duvar fotoğraflanır ya da dijital olarak kaydedilir, hotspot listesi çıkarılır ve sahipleri atanır. Duvar bir belge değil, ortak anlayışın bir ürünüdür; asıl çıktı katılımcıların zihnindeki hizalanmadır.

Sık hatalar ve atölye sonrası

Yaygın hatalar şunlardır: yeterli iş uzmanı olmadan yalnızca geliştiricilerle çalışmak, çözüm odaklı olup olay yerine komutla başlamak, çelişkileri tartışarak akışı kilitlemek, kolaylaştırıcıyı içerik sahibi saymak ve atölyeyi tek seferlik bir etkinlik gibi görüp çıktıyı sahiplenmemek. Bir diğer hata, tüm iş alanını tek duvara sığdırmaya çalışmaktır; geniş alanlar parçalara bölünüp ayrı oturumlarda ele alınmalıdır.

Atölye sonrası iş, duvarın koda ve ekiplere çevrilmesidir. Hotspot'lar sahiplerine verilir, sınırlı bağlam adayları teknik ekiplerle gözden geçirilir ve ortak dil terimleri bir sözlükte toplanır. Ardından önceliklendirilen bağlam için daha ayrıntılı tasarım oturumları yapılır.

Gelişmiş uygulamada, atölye yenilenen bir pratik haline gelir. İş alanı değişince duvar güncellenir, yeni ekipler katıldığında alan olaylarının üzerinden geçilir. Yöntemi bir kez çalıştırmak faydalıdır; düzenli kullanmak ise ekibin alanı anlama biçimini kalıcı olarak değiştirir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Event Storming ve Alan Modelleme Atölyesi programı; yöntem, hazırlık ve olay keşfi, modelin zenginleştirilmesi ile sınırlı bağlamlar ve ortak dil başlıklarını uygulamalı olarak işler. Domain-Driven Design İleri Seviye programı ise stratejik DDD ve ortak dil, atölye yürütme, sınırlı bağlamların belirlenmesi, bağlam haritası ve entegrasyon kalıpları ile taktiksel desenleri birlikte ele alır. Yazılım mimarları, ürün sahipleri ve iş analistleri için uygundur.